Bereitstellen eines bestimmten Builds

von Jason Lee

In diesem Thema wird beschrieben, wie Sie Webpakete und Datenbankskripts aus einem bestimmten vorherigen Build auf einem neuen Ziel bereitstellen, z. B. eine Staging- oder Produktionsumgebung.

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

Bisher haben sich die Themen in diesem Lernprogramm darauf konzentriert, wie Webanwendungen und Datenbanken als Teil eines einzelstufigen oder automatisierten Prozesses erstellt, verpackt und bereitgestellt werden. In einigen gängigen Szenarien sollten Sie jedoch die Ressourcen auswählen, die Sie aus einer Liste der Builds in einem Drop-Ordner bereitstellen. Anders ausgedrückt: Der neueste Build ist möglicherweise nicht der Build, den Sie bereitstellen möchten.

Berücksichtigen Sie das im vorherigen Thema beschriebene Szenario für die fortlaufende Integration (CI) Erstellen einer Builddefinition, die die Bereitstellung unterstützt. Sie haben eine Builddefinition in Team Foundation Server (TFS) 2010 erstellt. Jedes Mal, wenn ein Entwickler Code in TFS eincheckt, erstellt TeamBuild Ihren Code, erstellt Webpakete und Datenbankskripts als Teil des Buildprozesses, führt alle Komponententests aus und stellt Ihre Ressourcen in einer Testumgebung bereit. Abhängig von der Aufbewahrungsrichtlinie, die Sie beim Erstellen der Builddefinition konfiguriert haben, behält TFS eine bestimmte Anzahl früherer Builds bei.

=======

Angenommen, Sie haben Verifikations- und Validierungstests für eines dieser Builds in Ihrer Testumgebung durchgeführt und sind bereit, Ihre Anwendung in einer Staging-Umgebung zu implementieren. In der Zwischenzeit haben Entwickler möglicherweise neuen Code eingefügt. Sie möchten die Lösung nicht neu erstellen und in der Stagingumgebung bereitstellen, und Sie möchten den neuesten Build nicht in der Stagingumgebung bereitstellen. Stattdessen möchten Sie den spezifischen Build bereitstellen, den Sie auf den Testumgebungen überprüft und validiert haben.

Dazu müssen Sie dem Microsoft Build Engine (MSBuild) mitteilen, wo die Webpakete und Datenbankskripts zu finden sind, die ein bestimmter Build generiert hat.

Überschreiben der OutputRoot-Eigenschaft

In der Beispiellösung deklariert die Datei Publish.proj eine Eigenschaft namens OutputRoot. Wie der Name schon sagt, ist dies der Stammordner, der alles enthält, was der Buildprozess generiert. In der Datei Publish.proj können Sie sehen, dass die OutputRoot-Eigenschaft auf den Stammspeicherort für alle Bereitstellungsressourcen verweist.

<PropertyGroup>
  <!--This is where the .deploymanifest file will be written to during a build-->    
  <_DbDeployManifestPath>
    $(OutputRoot)ContactManager.Database.deploymanifest
  </_DbDeployManifestPath>    
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Mvc Web project -->
  <_ContactManagerDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Mvc_Package\
  </_ContactManagerDest>
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Service Web project -->
   <_ContactManagerSvcDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Service_Package\
  </_ContactManagerSvcDest>
  
  <!-- ... -->
</PropertyGroup>

Wenn Ihre Projektdatei Webpakete und Datenbankskripts von einem anderen Speicherort, wie zum Beispiel den Ausgaben eines vorherigen TFS-Builds, bereitstellen soll, müssen Sie einfach die OutputRoot-Eigenschaft überschreiben. Sie sollten den Eigenschaftswert auf den relevanten Buildordner auf dem Team Build-Server festlegen. Wenn Sie MSBuild über die Befehlszeile ausführen, können Sie einen Wert für OutputRoot als Befehlszeilenargument angeben:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\

In der Praxis sollten Sie jedoch auch das Build-Ziel überspringen – es hat keinen Zweck, Ihre Lösung zu bauen, wenn Sie nicht beabsichtigen, die Build-Ausgabe zu verwenden. Sie können dies tun, indem Sie die Ziele angeben, die Sie über die Befehlszeile ausführen möchten:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
  /target:GatherPackagesForPublishing;PublishDBPackages;PublishWebPackages

In den meisten Fällen sollten Sie ihre Bereitstellungslogik jedoch in einer TFS-Builddefinition erstellen. Auf diese Weise können Benutzer mit der Berechtigung " Warteschlangenbuilds " die Bereitstellung von jeder Visual Studio-Installation mit einer Verbindung mit dem TFS-Server auslösen.

Erstellen einer Builddefinition zum Bereitstellen bestimmter Builds

Im nächsten Verfahren wird beschrieben, wie Sie eine Builddefinition erstellen, mit der Benutzer Bereitstellungen in einer Stagingumgebung mit einem einzigen Befehl auslösen können.

In diesem Fall möchten Sie nicht, dass die Builddefinition tatsächlich etwas erstellt, sondern nur die Bereitstellungslogik in Ihrer benutzerdefinierten Projektdatei ausführen soll. Die Datei Publish.proj enthält bedingte Logik, die das Buildziel überspringt, wenn die Datei im TeamBuild ausgeführt wird. Dazu wird die integrierte BuildingInTeamBuild-Eigenschaft ausgewertet, die automatisch auf "true " festgelegt wird, wenn Sie die Projektdatei in Team Build ausführen. Daher können Sie den Buildvorgang überspringen und einfach die Projektdatei ausführen, um einen vorhandenen Build bereitzustellen.

So erstellen Sie eine Builddefinition zum manuellen Auslösen der Bereitstellung

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. DeployToStaging) und eine optionale Beschreibung.

3. Wählen Sie auf der Registerkarte "Trigger " die Option "Manuell" aus– Check-Ins lösen keinen neuen Build 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).

   

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. Wählen Sie in der Dropdownliste "Elemente des Typs " die Option "MSBuild-Projektdateien" aus.

9. 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.

   

10. Klicken Sie im Dialogfeld "Zu erstellende Elemente " auf "OK".

11. Erweitern Sie in der Tabelle Buildprozessparameter den Abschnitt Erweitert.

12. Geben Sie in der Zeile "MSBuild-Argumente " den Speicherort der umgebungsspezifischen Projektdatei an, und fügen Sie einen Platzhalter für den Speicherort des Buildordners hinzu:

    /p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
    OutputRoot=PLACEHOLDER
    

    

    Hinweis

    Sie müssen den OutputRoot-Wert jedes Mal überschreiben, wenn Sie einen Build in die Warteschlange stellen. Dies wird im nächsten Verfahren behandelt.

13. Klicke auf Speichern.

Wenn Sie einen Build auslösen, müssen Sie die OutputRoot-Eigenschaft aktualisieren, um auf den Build zu verweisen, den Sie bereitstellen möchten.

So stellen Sie einen bestimmten Build aus einer Builddefinition bereit

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

   

2. Erweitern Sie im Dialogfeld "Warteschlangenbuild " auf der Registerkarte "Parameter " den Abschnitt "Erweitert ".

3. Ersetzen Sie in der Zeile "MSBuild-Argumente " den Wert der OutputRoot-Eigenschaft durch den Speicherort des Buildordners. Beispiel:

   /p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
      OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
   

   

   Hinweis

   Achten Sie darauf, am Ende des Pfads zu Ihrem Build-Ordner einen Schrägstrich hinzuzufügen.

4. Klicken Sie auf Warteschlange.

Wenn Sie den Build in die Warteschlange stellen, stellt die Projektdatei die Datenbankskripts und Webpakete aus dem Buildablageordner bereit, den Sie in der OutputRoot-Eigenschaft angegeben haben.

Fazit

In diesem Thema wird beschrieben, wie Bereitstellungsressourcen wie Webpakete und Datenbankskripts aus einem bestimmten vorherigen Build mithilfe des Bereitstellungsmodells für geteilte Projektdateien veröffentlicht werden. Es wurde erläutert, wie man die OutputRoot-Eigenschaft überschreibt und wie man die Bereitstellungslogik in eine TFS-Builddefinition integriert.

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".