Erstellen einer Build-Definition, die die Bereitstellung ermöglicht

von Jason Lee

Wenn Sie eine Art von Build in Team Foundation Server (TFS) 2010 durchführen möchten, müssen Sie eine Builddefinition in Ihrem Teamprojekt erstellen. In diesem Thema wird beschrieben, wie Sie eine neue Builddefinition in TFS erstellen und die Webbereitstellung als Teil des Buildprozesses in Team Build steuern.

Dieses Thema ist Teil einer Reihe von Lernprogrammen basierend auf den Anforderungen an die Unternehmensbereitstellung eines fiktiven Unternehmens namens Fabrikam, Inc. In dieser Lernprogrammreihe wird eine Beispiellösung – die Contact Manager-Lösung – verwendet, um eine Webanwendung mit einer realistischen Komplexitätsstufe darzustellen, einschließlich einer ASP.NET MVC 3-Anwendung, einem WCF-Dienst (Windows Communication Foundation) und einem Datenbankprojekt.

Die Bereitstellungsmethode im Mittelpunkt dieser Lernprogramme basiert auf dem geteilten Projektdateiansatz, der unter "Grundlegendes zur Projektdatei" beschrieben wird, in dem der Build- und Bereitstellungsprozess von zwei Projektdateien gesteuert wird– eine mit Buildanweisungen, die für jede Zielumgebung gelten, und eine mit umgebungsspezifischen Build- und Bereitstellungseinstellungen. Zur Build-Zeit wird die umgebungsspezifische Projektdatei in die umgebungsunabhängige Projektdatei zusammengeführt, um einen vollständigen Satz von Build-Anweisungen zu bilden.

Aufgabenübersicht

Eine Builddefinition ist der Mechanismus, der steuert, wie und wann Builds für Teamprojekte in TFS auftreten. Jede Builddefinition gibt Folgendes an:

• Die Elemente, die Sie erstellen möchten, z. B. Visual Studio-Projektdateien oder benutzerdefinierte Microsoft Build Engine (MSBuild)-Projektdateien.
• Die Kriterien, die bestimmen, wann ein Build stattfinden soll, wie z. B. manuelle Auslöser, kontinuierliche Integration (CI) oder gesteuerte Check-Ins.
• Der Speicherort, an den Team Build Build-Ausgaben senden soll, einschließlich Bereitstellungsartefakten wie Webpakete und Datenbankskripte.
• Die Zeitspanne, für die jeder Build aufbewahrt werden soll.
• Verschiedene andere Parameter des Buildprozesses.

In diesem Thema wird erläutert, wie Sie eine Builddefinition erstellen, die CI verwendet, sodass ein Build ausgelöst wird, wenn ein Entwickler neue Inhalte eincheckt. Wenn der Build erfolgreich ist, führt der Builddienst eine benutzerdefinierte Projektdatei aus, um die Lösung in einer Testumgebung bereitzustellen.

Wenn Sie einen Build auslösen, müssen diese Aktionen ausgeführt werden:

• Zuerst sollte TeamBuild die Lösung erstellen. Im Rahmen dieses Prozesses ruft Team Build die Web Publishing Pipeline (WPP) auf, um Webbereitstellungspakete für jedes der Webanwendungsprojekte in der Lösung zu generieren. TeamBuild führt auch alle Komponententests aus, die der Lösung zugeordnet sind.
• Wenn der Lösungsbuild fehlschlägt, sollte der Teambuild keine weiteren Maßnahmen ergreifen. Komponententestfehler sollten als Buildfehler behandelt werden.
• Wenn der Lösungsbuild erfolgreich ist, sollte TeamBuild die benutzerdefinierte Projektdatei ausführen, die die Bereitstellung der Lösung steuert. Im Rahmen dieses Prozesses ruft Team Build das Iis-Webbereitstellungstool (InternetInformationsdienste) (Web Deploy) auf, um die verpackten Webanwendungen auf den Zielwebservern zu installieren, und es wird das hilfsprogramm VSDBCMD.exe aufgerufen, um Datenbankerstellungsskripts auf den Zieldatenbankservern auszuführen.

Dies veranschaulicht den Prozess:

Die Contact Manager-Beispiellösung enthält eine benutzerdefinierte MSBuild-Projektdatei , Publish.proj, die Sie über MSBuild oder Team Build ausführen können. Wie unter "Grundlegendes zum Buildprozess" beschrieben, definiert diese Projektdatei die Logik, die Ihre Webpakete und Datenbanken in einer Zielumgebung bereitstellt. Die Datei enthält Logik, die den Erstellungs- und Paketprozess auslässt, wenn sie im TeamBuild ausgeführt wird, wobei nur die Bereitstellungsaufgaben ausgeführt werden müssen. Dies liegt daran, dass sie beim Automatisieren der Bereitstellung auf diese Weise in der Regel sicherstellen möchten, dass die Lösung erfolgreich erstellt und komponententests bestanden hat, bevor der Bereitstellungsprozess beginnt.

Im nächsten Abschnitt wird erläutert, wie Sie diesen Prozess implementieren, indem Sie eine neue Builddefinition erstellen.

Wer führt dieses Verfahren aus?

Normalerweise führt ein TFS-Administrator dieses Verfahren aus. In einigen Fällen kann ein Entwicklerteamleiter die Verantwortung für die Teamprojektsammlung in TFS übernehmen. Um eine neue Builddefinition zu erstellen, müssen Sie Mitglied der Gruppe Projektsammlungsbuildadministratoren für die Teamprojektsammlung sein, die Ihre Lösung enthält.

Erstellen einer Build-Definition für CI und Bereitstellung

Im nächsten Verfahren wird beschrieben, wie Sie eine Builddefinition erstellen, die von CI ausgelöst wird. Wenn der Build erfolgreich ist, wird die Lösung mithilfe der Logik in einer benutzerdefinierten MSBuild-Projektdatei bereitgestellt.

So erstellen Sie eine Build-Definition für CI und Deployment

1. Erweitern Sie in Visual Studio 2010 im Team-Explorer-Fenster ihren Teamprojektknoten, klicken Sie mit der rechten Maustaste auf "Builds", und klicken Sie dann auf "Neue Builddefinition".

   

2. Geben Sie auf der Registerkarte " Allgemein " der Builddefinition einen Namen (z. B. DeployToTest) und eine optionale Beschreibung.

3. Wählen Sie auf der Registerkarte "Trigger " die Kriterien aus, für die Sie einen neuen Build auslösen möchten. Wenn Sie z. B. die Lösung erstellen und bei jeder Überprüfung eines neuen Codes in der Testumgebung bereitstellen möchten, wählen Sie "Fortlaufende Integration" aus.

4. Geben Sie auf der Registerkarte Buildstandardeinstellungen in das Feld Build-Ausgabe in den folgenden Drop-Ordner kopieren den UNC-Pfad (Universal Naming Convention) Ihres Drop-Ordners ein (z. B. \TFSBUILD\Drops).

   

   Hinweis

   Dieser Ablageort speichert mehrere Builds, je nach der von Ihnen konfigurierten Aufbewahrungsrichtlinie. Wenn Sie Bereitstellungsartefakte aus einem bestimmten Build in einer Staging- oder Produktionsumgebung veröffentlichen möchten, können Sie sie hier finden.

5. Lassen Sie auf der Registerkarte "Prozess " in der Dropdownliste " Prozessdatei erstellen" "DefaultTemplate.xaml " ausgewählt. Dies ist eine der Standardmäßigen Buildprozessvorlagen, die allen neuen Teamprojekten hinzugefügt werden.

6. Klicken Sie in der Tabelle „Buildprozessparameter“ auf die Zeile „Elemente zum Erstellen“ und dann auf die Auslassungspunkte-Schaltfläche.

   

7. Klicken Sie im Dialogfeld "Zu erstellende Elemente " auf "Hinzufügen".

8. Navigieren Sie zum Speicherort der Lösungsdatei, und klicken Sie dann auf "OK".

   

9. Klicken Sie im Dialogfeld "Zu erstellende Elemente " auf "Hinzufügen".

10. Wählen Sie in der Dropdownliste "Elemente des Typs " die Option "MSBuild-Projektdateien" aus.

11. Navigieren Sie zum Speicherort der benutzerdefinierten Projektdatei, mit der Sie den Bereitstellungsprozess steuern, wählen Sie die Datei aus, und klicken Sie dann auf OK.

    

12. Das Dialogfeld "Zu erstellende Elemente " sollte nun zwei Elemente anzeigen. Klicke auf OK.

    

13. Erweitern Sie auf der Registerkarte "Prozess " in der Tabelle " Buildprozessparameter " den Abschnitt "Erweitert ".

14. Fügen Sie in der Zeile "MSBuild-Argumente " beliebige MSBuild-Befehlszeilenargumente hinzu, die von einem der zu erstellenden Elemente erforderlich sind. Im Szenario der Contact Manager-Lösung sind diese Argumente erforderlich:

    /p:DeployOnBuild=true;DeployTarget=Package;
       TargetEnvPropsFile=EnvConfig\Env-Dev.proj
    

    

15. In diesem Beispiel:

    1. Die Argumente DeployOnBuild=true und DeployTarget=package sind erforderlich, wenn Sie die Contact Manager-Lösung erstellen. Dadurch wird MSBuild angewiesen, Webbereitstellungspakete nach dem Erstellen jedes Webanwendungsprojekts zu erstellen, wie in Building and Packaging Web Application Projects beschrieben.
    2. Das Argument TargetEnvPropsFile ist erforderlich, wenn Sie die Publish.proj-Datei erstellen. Diese Eigenschaft gibt den Speicherort der umgebungsspezifischen Konfigurationsdatei an, wie unter "Grundlegendes zum Buildprozess" beschrieben.

16. Konfigurieren Sie auf der Registerkarte "Aufbewahrungsrichtlinie " die Anzahl der Builds jedes Typs, die Sie bei Bedarf beibehalten möchten.

17. Klicke auf Speichern.

Einen Build in die Warteschlange stellen

An diesem Punkt haben Sie mindestens eine neue Builddefinition erstellt. Der von Ihnen definierte Buildprozess wird nun entsprechend den Triggern ausgeführt, die Sie in der Builddefinition angegeben haben.

Wenn Sie Ihre Builddefinition für die Verwendung von CI konfiguriert haben, können Sie Ihre Builddefinition auf zwei Arten testen:

• Überprüfen Sie einige Inhalte im Teamprojekt, um einen automatischen Build auszulösen.
• Einen Build manuell in die Warteschlange stellen.

So stellen Sie einen Build manuell in die Warteschlange

1. Klicken Sie im Team Explorer-Fenster mit der rechten Maustaste auf die Builddefinition, und klicken Sie dann auf "Neue Buildwarteschlange".

   

2. Im Queue Build-Dialogfeld überprüfen Sie die Buildeigenschaften und klicken dann auf Queue.

   

Um den Fortschritt und das Ergebnis eines Builds zu überprüfen – unabhängig davon, ob er manuell oder automatisch ausgelöst wurde – doppelklicken Sie im Team Explorer-Fenster auf die Builddefinition. Dadurch wird eine Registerkarte "Build-Explorer " geöffnet.

Von hier aus können Sie Fehler beim Erstellen von Builds beheben. Wenn Sie auf einen einzelnen Build doppelklicken, können Sie Zusammenfassungsinformationen anzeigen und durchklicken, um detaillierte Protokolldateien anzuzeigen.

Sie können diese Informationen verwenden, um fehlerhafte Builds zu beheben und probleme zu beheben, bevor Sie einen anderen Build versuchen.

Den Build-Prozess überwachen

TFS bietet eine breite Palette von Funktionen, mit denen Sie den Buildprozess überwachen können. Beispielsweise kann TFS Ihnen eine E-Mail senden oder Benachrichtigungen im Infobereich der Taskleiste anzeigen, wenn ein Build abgeschlossen ist. Weitere Informationen finden Sie unter Ausführen und Überwachen von Builds.

Fazit

In diesem Thema wird beschrieben, wie Sie eine Builddefinition in TFS erstellen. Die Builddefinition ist für CI konfiguriert, sodass der Buildprozess immer ausgeführt wird, wenn ein Entwickler Inhalte an das Teamprojekt eincheckt. Die Builddefinition führt eine benutzerdefinierte MSBuild-Projektdatei aus, um Webpakete und Datenbankskripts in einer Zielserverumgebung bereitzustellen.

Damit eine automatisierte Bereitstellung als Teil eines Buildprozesses erfolgreich ausgeführt werden kann, müssen Sie dem Builddienstkonto auf den Zielwebservern und dem Zieldatenbankserver geeignete Berechtigungen erteilen. Das letzte Thema in diesem Lernprogramm, Konfigurieren von Berechtigungen für die Bereitstellung von Teambuilds, beschreibt, wie Sie die berechtigungen identifizieren und konfigurieren, die für die automatisierte Bereitstellung von einem Teambuildserver erforderlich sind.

Weiterführende Lektüre

Weitere Informationen zum Erstellen von Builddefinitionen finden Sie unter Create a Basic Build Definition and Define Your Build Process. Weitere Anleitungen zu Builds in der Warteschlange finden Sie unter "Erstellen in der Warteschlange".