Bereitstellen eines bestimmten Builds

von Jason Lee

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

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

Bisher konzentrierten sich die Themen in diesem Tutorialsatz auf das Erstellen, Verpacken und Bereitstellen von Webanwendungen und Datenbanken im Rahmen eines einstufigen oder automatisierten Prozesses. In einigen gängigen Szenarien sollten Sie jedoch die von Ihnen bereitgestellten Ressourcen aus einer Liste von Builds in einem Ablageordner auswählen. Anders ausgedrückt: Der neueste Build ist möglicherweise nicht der Build, den Sie bereitstellen möchten.

Betrachten Sie das Szenario continuous Integration (CI), das im vorherigen Thema Erstellen einer Builddefinition, die die Bereitstellung unterstützt, beschrieben wurde. Sie haben eine Builddefinition in Team Foundation Server (TFS) 2010 erstellt. Jedes Mal, wenn ein Entwickler Code in TFS überprüft, erstellt Team Build Ihren Code, erstellt Webpakete und Datenbankskripts im Rahmen 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 vorheriger Builds bei.

=======

Angenommen, Sie haben Überprüfungs- und Validierungstests für einen dieser Builds in Ihrer Testumgebung durchgeführt und sind bereit, Ihre Anwendung in einer Stagingumgebung bereitzustellen. In der Zwischenzeit haben Entwickler möglicherweise neuen Code eingecheckt. 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 Testservern überprüft und überprüft haben.

Um dies zu erreichen, 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 mit dem Namen OutputRoot. Wie der Name schon sagt, ist dies der Stammordner, der alles enthält, was der Buildprozess generiert. In der Datei Publish.proj sehen Sie, dass die OutputRoot-Eigenschaft auf den Stammspeicherort für alle Bereitstellungsressourcen verweist.

Hinweis

OutputRoot ist ein häufig verwendeter Eigenschaftenname. Visual C#- und Visual Basic-Projektdateien deklarieren auch diese Eigenschaft, um den Stammspeicherort für alle Buildausgaben zu speichern.

<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 an einem anderen Speicherort bereitstellen soll ( z. B. die Ausgaben eines vorherigen TFS-Builds), müssen Sie einfach die OutputRoot-Eigenschaft überschreiben. Sie sollten den Eigenschaftswert auf den entsprechenden 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 Buildziel überspringen. Es hat keinen Sinn, Ihre Lösung zu erstellen, wenn Sie nicht planen, die Buildausgaben zu verwenden. Hierzu können 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 eine TFS-Builddefinition integrieren. Dadurch können Benutzer mit der Berechtigung Warteschlangenbuilds die Bereitstellung von jeder Visual Studio-Installation über eine 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, die es Benutzern ermöglicht, Bereitstellungen in einer Stagingumgebung mit einem einzigen Befehl auszulösen.

In diesem Fall möchten Sie nicht, dass die Builddefinition tatsächlich etwas erstellt, sie soll lediglich die Bereitstellungslogik in Ihrer benutzerdefinierten Projektdatei ausführen. Die Datei Publish.proj enthält bedingte Logik, die das Buildziel überspringt, wenn die Datei in Team Build ausgeführt wird. Dazu wird die integrierte BuildingInTeamBuild-Eigenschaft ausgewertet, die automatisch auf TRUE festgelegt wird, wenn Sie Ihre Projektdatei in Team Build ausführen. Daher können Sie den Buildprozess ü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 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. DeployToStaging) und eine optionale Beschreibung.

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

   

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. Wählen Sie in der Dropdownliste Elemente vom Typdie 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 Ihrer umgebungsspezifischen Projektdatei an, und fügen Sie einen Platzhalter für den Speicherort Ihres 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. Klicken Sie auf Speichern.

Wenn Sie einen Build auslösen, müssen Sie die OutputRoot-Eigenschaft so aktualisieren, dass sie auf den Build verweist, den Sie bereitstellen möchten.

So stellen Sie einen bestimmten Build aus einer Builddefinition bereit

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

   

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

3. Ersetzen Sie in der Zeile MSBuild Arguments den Wert der OutputRoot-Eigenschaft durch den Speicherort Ihres Buildordners. Zum Beispiel:

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

   

   Hinweis

   Achten Sie darauf, am Ende des Pfads zu Ihrem Buildordner einen nachgestellten Schrägstrich einzufü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.

Zusammenfassung

In diesem Thema wurde 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 die OutputRoot-Eigenschaft überschrieben wird und wie die Bereitstellungslogik in eine TFS-Builddefinition integriert wird.

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