Erstellen einer Builddefinition mit Unterstützung für Bereitstellungen

von Jason Lee

Wenn Sie eine Art von Build in Team Foundation Server (TFS) 2010 ausführen möchten, müssen Sie eine Builddefinition innerhalb Ihres Teamprojekts erstellen. In diesem Thema wird beschrieben, wie Sie eine neue Builddefinition in TFS erstellen und die Webbereitstellung im Rahmen des Buildprozesses in Team Build steuern.

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

Die Bereitstellungsmethode, die im Mittelpunkt dieser Tutorials steht, basiert auf dem Ansatz der geteilten Projektdatei, der unter Grundlegendes zur Projektdatei beschrieben wird, bei 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 Buildzeit wird die umgebungsspezifische Projektdatei in die umgebungsunabhängige Projektdatei zusammengeführt, um einen vollständigen Satz von Buildanweisungen zu bilden.

Aufgabenübersicht

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

• Die Elemente, die Sie erstellen möchten, z. B. Visual Studio-Projektmappendateien oder benutzerdefinierte Microsoft-Build-Engine (MSBuild)-Projektdateien.
• Die Kriterien, die bestimmen, wann ein Build durchgeführt werden soll, z. B. manuelle Trigger, Continuous Integration (CI) oder gated Check-Ins.
• Der Speicherort, an den Team Build-Ausgaben senden soll, einschließlich Bereitstellungsartefakten wie Webpaketen und Datenbankskripts.
• Die Zeitspanne, die jeder Build beibehalten werden soll.
• Verschiedene andere Parameter des Buildprozesses.

Hinweis

Weitere Informationen zu Builddefinitionen finden Sie unter Definieren Ihres Buildprozesses.

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

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

• Zunächst sollte Team Build die Lösung erstellen. In diesem Prozess ruft Team Build die Web Publishing Pipeline (WPP) auf, um Webbereitstellungspakete für jedes Webanwendungsprojekt in der Projektmappe zu generieren. Team Build führt auch alle Komponententests aus, die der Lösung zugeordnet sind.
• Wenn der Lösungsbuild fehlschlägt, sollte Team Build keine weiteren Maßnahmen ergreifen. Komponententestfehler sollten als Buildfehler behandelt werden.
• Wenn der Projektmappenbuild erfolgreich ist, sollte Team Build die benutzerdefinierte Projektdatei ausführen, die die Bereitstellung der Projektmappe steuert. Im Rahmen dieses Prozesses ruft Team Build das IIS-Webbereitstellungstool (Web Deploy) auf, um die gepackten Webanwendungen auf den Zielwebservern zu installieren, und es ruft das Hilfsprogramm VSDBCMD.exe auf, um Datenbankerstellungsskripts auf den Zieldatenbankservern auszuführen.

Dies veranschaulicht den Prozess:

Die Contact Manager-Beispiellösung enthält die 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 Verpackungsprozess auslässt, wenn er in Team Build ausgeführt wird, sodass nur die Bereitstellungsaufgaben ausgeführt werden können. Dies liegt daran, dass Sie bei der Automatisierung der Bereitstellung auf diese Weise in der Regel sicherstellen möchten, dass die Lösung erfolgreich erstellt wird und alle Komponententests besteht, bevor der Bereitstellungsprozess beginnt.

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

Hinweis

Dieses Verfahren, in dem ein einzelner automatisierter Prozess eine Lösung erstellt, testet und bereitstellt, eignet sich wahrscheinlich am besten für die Bereitstellung in Testumgebungen. Für Staging- und Produktionsumgebungen ist es wahrscheinlicher, Dass Sie Inhalte aus einem vorherigen Build bereitstellen möchten, die Sie bereits in einer Testumgebung überprüft und überprüft haben. Dieser Ansatz wird im nächsten Thema , Bereitstellen eines bestimmten Builds, beschrieben.

Wer führt dieses Verfahren aus?

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

Erstellen einer Builddefinition für CI und Bereitstellung

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

So erstellen Sie eine Builddefinition für CI und Bereitstellung

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

   

2. Geben Sie der Builddefinition auf der Registerkarte Allgemein 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 beispielsweise die Lösung erstellen und jedes Mal, wenn ein Entwickler neuen Code eincheckt, in der Testumgebung bereitstellen möchten, wählen Sie Continuous Integration aus.

4. Geben Sie auf der Registerkarte Buildstandard im Feld Buildausgabe in den folgenden Ordner kopieren den UNC-Pfad (Universal Naming Convention) Ihres Ablageordners ein (z. B. \TFSBUILD\Drops).

   

   Hinweis

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

5. Lassen Sie auf der Registerkarte Prozess in der Dropdownliste BuildprozessdateidefaultTemplate.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 Zu erstellende Elemente , und klicken Sie dann auf die Schaltfläche mit den Auslassungspunkten .

   

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

8. Navigieren Sie zum Speicherort Ihrer Projektmappendatei, 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 vom Typdie 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. Im Dialogfeld Zu erstellende Elemente sollten nun zwei Elemente angezeigt werden. Klicken Sie 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 alle MSBuild-Befehlszeilenargumente hinzu, die für die Erstellung eines ihrer Elemente erforderlich sind. Im Contact Manager-Lösungsszenario sind die folgenden 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, nach dem Erstellen jedes Webanwendungsprojekts Webbereitstellungspakete zu erstellen, wie unter Erstellen und Verpacken von Webanwendungsprojekten beschrieben.
    2. Das Argument TargetEnvPropsFile ist erforderlich, wenn Sie die Datei Publish.proj erstellen. Diese Eigenschaft gibt den Speicherort der umgebungsspezifischen Konfigurationsdatei an, wie unter Grundlegendes zum Buildprozess beschrieben.

16. Konfigurieren Sie auf der Registerkarte Aufbewahrungsrichtlinie , wie viele Builds jedes Typs sie bei Bedarf beibehalten möchten.

17. Klicken Sie auf Speichern.

Hinzufügen eines Builds zur Warteschlange

An diesem Punkt haben Sie mindestens eine neue Builddefinition erstellt. Der von Ihnen definierte Buildprozess wird nun gemäß 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 eine Warteschlange stellen.

So stellen Sie einen Build manuell in die Warteschlange

1. Klicken Sie im Fenster Team Explorer mit der rechten Maustaste auf die Builddefinition, und klicken Sie dann auf Warteschlangenneuer Build.

   

2. Überprüfen Sie im Dialogfeld Warteschlangenbuild die Buildeigenschaften, und klicken Sie dann auf Warteschlange.

   

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 Fenster Team Explorer auf die Builddefinition. Dadurch wird eine Registerkarte Build Explorer geöffnet.

Hier können Sie Fehler bei Builds beheben. Wenn Sie auf einen einzelnen Build doppelklicken, können Sie Zusammenfassungsinformationen anzeigen und zu detaillierten Protokolldateien klicken.

Sie können diese Informationen verwenden, um fehlerhafte Builds zu beheben und probleme zu beheben, bevor Sie einen anderen Buildversuch durchführen.

Hinweis

Builds, die Bereitstellungslogik ausführen, schlagen wahrscheinlich fehl, bis Sie dem Buildserver alle berechtigungen erteilt haben, die in der Zielumgebung erforderlich sind. Weitere Informationen finden Sie unter Konfigurieren von Berechtigungen für die Team Build-Bereitstellung.

Überwachen des Buildprozesses

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

Zusammenfassung

In diesem Thema wurde beschrieben, wie Sie eine Builddefinition in TFS erstellen. Die Builddefinition ist für CI konfiguriert, sodass der Buildprozess immer dann 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 im Rahmen eines Buildprozesses erfolgreich ist, müssen Sie dem Builddienstkonto auf den Zielwebservern und dem Zieldatenbankserver entsprechende Berechtigungen erteilen. Das letzte Thema in diesem Tutorial , Konfigurieren von Berechtigungen für die Team Build-Bereitstellung, beschreibt, wie Sie die Berechtigungen identifizieren und konfigurieren, die für die automatisierte Bereitstellung von einem Team Build-Server erforderlich sind.

Weitere Informationen

Weitere Informationen zum Erstellen von Builddefinitionen finden Sie unter Erstellen einer grundlegenden Builddefinition und Definieren Ihres Buildprozesses. Weitere Anleitungen zu Warteschlangenbuilds finden Sie unter Warteschlangen für einen Build.

ZurückWeiter