Anwendungslebenszyklus-Verwaltung: Von der Entwicklung zur Produktion

von Jason Lee

In diesem Thema wird veranschaulicht, wie ein fiktives Unternehmen die Bereitstellung einer ASP.NET Webanwendung über Test-, Staging- und Produktionsumgebungen im Rahmen eines kontinuierlichen Entwicklungsprozesses verwaltet. Im gesamten Thema werden Links zu weiteren Informationen und exemplarischen Vorgehensweisen zur Ausführung bestimmter Aufgaben bereitgestellt.

Das Thema soll eine allgemeine Übersicht für eine Reihe von Tutorials zur Webbereitstellung im Unternehmen bieten. Machen Sie sich keine Sorgen, wenn Sie mit einigen der hier beschriebenen Konzepte nicht vertraut sind – die folgenden Tutorials enthalten detaillierte Informationen zu all diesen Aufgaben und Techniken.

Hinweis

Der Einfachheit halber wird in diesem Thema das Aktualisieren von Datenbanken im Rahmen des Bereitstellungsprozesses nicht erläutert. Das Durchführen inkrementeller Updates für Datenbankfeatures ist jedoch eine Anforderung vieler Unternehmensbereitstellungsszenarien. Anleitungen dazu finden Sie weiter unten in dieser Tutorialreihe. Weitere Informationen finden Sie unter Bereitstellen von Datenbankprojekten.

Überblick

Der hier veranschaulichte Bereitstellungsprozess basiert auf dem Bereitstellungsszenario fabrikam, Inc., das unter Enterprise Web Deployment: Scenario Overview beschrieben wird. Sie sollten die Szenarioübersicht lesen, bevor Sie sich mit diesem Thema befassen. Im Wesentlichen wird untersucht, wie ein organization die Bereitstellung einer relativ komplexen Webanwendung, der Contact Manager-Lösung, durch verschiedene Phasen in einer typischen Unternehmensumgebung verwaltet.

Auf hoher Ebene durchläuft die Contact Manager-Lösung im Rahmen des Entwicklungs- und Bereitstellungsprozesses die folgenden Phasen:

1. Ein Entwickler überprüft Code in Team Foundation Server (TFS) 2010.
2. TFS erstellt den Code und führt alle Komponententests aus, die dem Teamprojekt zugeordnet sind.
3. TFS stellt die Lösung in der Testumgebung bereit.
4. Das Entwicklerteam überprüft und überprüft die Lösung in der Testumgebung.
5. Der Stagingumgebungsadministrator führt eine Was-wäre-wenn-Bereitstellung für die Stagingumgebung durch, um festzustellen, ob die Bereitstellung Probleme verursacht.
6. Der Stagingumgebungsadministrator führt eine Livebereitstellung in der Stagingumgebung durch.
7. Die Lösung wird in der Stagingumgebung einem Benutzerakzeptanztest unterzogen.
8. Die Webbereitstellungspakete werden manuell in die Produktionsumgebung importiert.

Diese Phasen sind Teil eines kontinuierlichen Entwicklungszyklus.

In der Praxis ist der Prozess etwas komplizierter, wie Sie sehen werden, wenn wir uns die einzelnen Phasen genauer ansehen. Fabrikam, Inc. verwendet einen anderen Ansatz für die Bereitstellung für jede Zielumgebung.

Im weiteren Verlauf dieses Themas werden die folgenden wichtigen Phasen dieses Bereitstellungslebenszyklus untersucht:

• Voraussetzungen: So müssen Sie Ihre Serverinfrastruktur konfigurieren, bevor Sie Ihre Bereitstellungslogik einrichten.
• Erste Entwicklung und Bereitstellung: Was Sie tun müssen, bevor Sie Ihre Lösung zum ersten Mal bereitstellen.
• Bereitstellung zum Testen: So werden Inhalte automatisch in einer Testumgebung verpackt und bereitgestellt, wenn ein Entwickler neuen Code eincheckt.
• Bereitstellung für Staging: Hier erfahren Sie, wie Sie bestimmte Builds in einer Stagingumgebung bereitstellen und "Was wäre wenn"-Bereitstellungen ausführen, um sicherzustellen, dass eine Bereitstellung keine Probleme verursacht.
• Bereitstellung in der Produktion: Importieren von Webpaketen in eine Produktionsumgebung, wenn die Netzwerkinfrastruktur die Remotebereitstellung verhindert.

Voraussetzungen

Die erste Aufgabe in jedem Bereitstellungsszenario besteht darin, sicherzustellen, dass Ihre Serverinfrastruktur die Anforderungen Ihrer Bereitstellungstools und -techniken erfüllt. In diesem Fall hat Fabrikam, Inc. seine Serverinfrastruktur wie folgt konfiguriert:

• TFS ist so konfiguriert, dass sie eine Teamprojektsammlung, Buildcontroller und Build-Agents enthält. Weitere Informationen finden Sie unter Konfigurieren von Team Foundation Server für die automatisierte Webbereitstellung .
• Die Testumgebung ist so konfiguriert, dass Remotebereitstellungen mithilfe des Web Deployment Agent-Diensts (der "Remote-Agent") akzeptiert werden, wie unter Szenario: Konfigurieren einer Testumgebung für die Webbereitstellung und Konfigurieren eines Webservers für die Webbereitstellung (Remote-Agent) beschrieben.
• Die Stagingumgebung ist so konfiguriert, dass Remotebereitstellungen mithilfe des Endpunkts Web Deploy Handler akzeptiert werden, wie unter Szenario: Konfigurieren einer Stagingumgebung für die Webbereitstellung und Konfigurieren eines Webservers für die Webbereitstellungsveröffentlichung (WebBereitstellungshandler) beschrieben.
• Die Produktionsumgebung ist so konfiguriert, dass ein Administrator Webbereitstellungspakete manuell in Internetinformationsdienste (IIS) importieren kann, wie unter Szenario: Konfigurieren einer Produktionsumgebung für die Webbereitstellung und Konfigurieren eines Webservers für die Webbereitstellung (Offlinebereitstellung) beschrieben.

Anfängliche Entwicklung und Bereitstellung

Bevor das Entwicklungsteam von Fabrikam, Inc. die Contact Manager-Lösung zum ersten Mal bereitstellen kann, müssen die folgenden Aufgaben ausgeführt werden:

• Erstellen Sie ein neues Teamprojekt in TFS.
• Erstellen Sie die Microsoft-Build-Engine -Projektdateien (MSBuild), die die Bereitstellungslogik enthalten.
• Erstellen Sie die TFS-Builddefinitionen, die die Bereitstellungsprozesse auslösen.

Erstellen eines neuen Teamprojekts

• Der TFS-Administrator Rob Walters erstellt ein neues Teamprojekt für die Anwendung, wie unter Erstellen eines Teamprojekts in TFS beschrieben. Als Nächstes erstellt der leitende Entwickler, Matt Hink, eine Skelettlösung. Er überprüft seine Dateien in das neue Teamprojekt in TFS, wie unter Hinzufügen von Inhalten zur Quellcodeverwaltung beschrieben.

Erstellen der Bereitstellungslogik

Matt Hink erstellt verschiedene benutzerdefinierte MSBuild-Projektdateien mit dem Ansatz der geteilten Projektdatei, der unter Grundlegendes zur Projektdatei beschrieben wird. Matt erstellt Folgendes:

• Eine Projektdatei mit dem Namen Publish.proj , die den Bereitstellungsprozess ausführt. Diese Datei enthält MSBuild-Ziele, die die Projekte in der Projektmappe erstellen, Webpakete erstellen und die Pakete in einer Zielserverumgebung bereitstellen.
• Umgebungsspezifische Projektdateien mit den Namen Env-Dev.proj und Env-Stage.proj. Diese enthalten Einstellungen, die für die Testumgebung bzw. die Stagingumgebung spezifisch sind, z. B. Verbindungszeichenfolgen, Dienstendpunkte und die Details des Remotediensts, der das Webpaket empfängt. Eine Anleitung zum Auswählen der richtigen Einstellungen für bestimmte Zielumgebungen finden Sie unter Konfigurieren von Bereitstellungseigenschaften für eine Zielumgebung.

Zum Ausführen der Bereitstellung führt ein Benutzer die Datei Publish.proj mithilfe von MSBuild oder Team Build aus und gibt den Speicherort der relevanten umgebungsspezifischen Projektdatei (Env-Dev.proj oder Env-Stage.proj) als Befehlszeilenargument an. Die Datei Publish.proj importiert dann die umgebungsspezifische Projektdatei, um einen vollständigen Satz von Veröffentlichungsanweisungen für jede Zielumgebung zu erstellen.

Hinweis

Die Funktionsweise dieser benutzerdefinierten Projektdateien ist unabhängig vom Mechanismus, den Sie zum Aufrufen von MSBuild verwenden. Beispielsweise können Sie die MSBuild-Befehlszeile direkt verwenden, wie unter Grundlegendes zur Projektdatei beschrieben. Sie können die Projektdateien aus einer Befehlsdatei ausführen, wie unter Erstellen und Ausführen einer Bereitstellungsbefehlsdatei beschrieben. Alternativ können Sie die Projektdateien aus einer Builddefinition in TFS ausführen, wie unter Erstellen einer Builddefinition, die die Bereitstellung unterstützt, beschrieben wird.
In jedem Fall ist das Endergebnis identisch: MSBuild führt die zusammengeführte Projektdatei aus und stellt Ihre Projektmappe in der Zielumgebung bereit. Dies bietet Ihnen eine große Flexibilität bei der Auslösung Ihres Veröffentlichungsprozesses.

Nachdem er die benutzerdefinierten Projektdateien erstellt hat, fügt Matt sie einem Projektmappenordner hinzu und überprüft sie in die Quellcodeverwaltung.

Builddefinitionen erstellen

Als letzte Vorbereitungsaufgabe arbeiten Matt und Rob zusammen, um drei Builddefinitionen für das neue Teamprojekt zu erstellen:

• DeployToTest. Dadurch wird die Contact Manager-Lösung erstellt und bei jedem Einchecken in der Testumgebung bereitgestellt.
• DeployToStaging. Dadurch werden Ressourcen aus einem angegebenen vorherigen Build in der Stagingumgebung bereitgestellt, wenn ein Entwickler den Build in die Warteschlange stellt.
• DeployToStaging-WhatIf. Dadurch wird eine Was-wäre-wenn-Bereitstellung für die Stagingumgebung ausgeführt, wenn ein Entwickler den Build in die Warteschlange stellt.

Die folgenden Abschnitte enthalten weitere Details zu jeder dieser Builddefinitionen.

Bereitstellung zum Testen

Das Entwicklungsteam von Fabrikam, Inc. unterhält Testumgebungen, um eine Vielzahl von Softwaretestaktivitäten durchzuführen, z. B. Überprüfung und Validierung, Benutzerfreundlichkeitstests, Kompatibilitätstests und Ad-hoc- oder explorative Tests.

Das Entwicklungsteam hat eine Builddefinition in TFS mit dem Namen DeployToTest erstellt. Diese Builddefinition verwendet einen Continuous Integration-Trigger, was bedeutet, dass der Buildprozess jedes Mal ausgeführt wird, wenn ein Mitglied des Fabrikam, Inc.-Entwicklungsteams einen Check-In durchführt. Wenn ein Build ausgelöst wird, lautet die Builddefinition:

• Erstellen Sie die ContactManager.sln-Lösung. Dadurch wird wiederum jedes Projekt innerhalb der Projektmappe erstellt.
• Führen Sie alle Komponententests in der Projektmappenordnerstruktur aus (wenn die Projektmappe erfolgreich erstellt wird).
• Führen Sie die benutzerdefinierten Projektdateien aus, die den Bereitstellungsprozess steuern (wenn die Projektmappe erfolgreich erstellt und Komponententests bestanden hat).

Das Endergebnis ist, dass die Webpakete und alle anderen Bereitstellungsressourcen in der Testumgebung bereitgestellt werden, wenn die Lösung erfolgreich erstellt und Komponententests besteht.

Wie funktioniert der Bereitstellungsprozess?

Die DeployToTest-Builddefinition stellt die folgenden Argumente für MSBuild bereit:

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

Die Eigenschaften DeployOnBuild=true und DeployTarget=package werden verwendet, wenn Team Build die Projekte innerhalb der Projektmappe erstellt. Wenn es sich bei dem Projekt um ein Webanwendungsprojekt handelt, weisen diese Eigenschaften MSBuild an, ein Webbereitstellungspaket für das Projekt zu erstellen. Die TargetEnvPropsFile-Eigenschaft teilt der Datei Publish.proj mit, wo die zu importierende umgebungsspezifische Projektdatei zu finden ist.

Hinweis

Eine ausführliche exemplarische Vorgehensweise zum Erstellen einer Builddefinition wie dieser finden Sie unter Erstellen einer Builddefinition, die die Bereitstellung unterstützt.

Die Datei Publish.proj enthält Ziele, die jedes Projekt in der Projektmappe erstellen. Es enthält jedoch auch bedingte Logik, die diese Buildziele überspringt, wenn Sie die Datei in Team Build ausführen. Dadurch können Sie die zusätzlichen Buildfunktionen nutzen, die Team Build bietet, z. B. die Möglichkeit, Komponententests auszuführen. Wenn der Lösungsbuild oder die Komponententests fehlschlagen, wird die Datei Publish.proj nicht ausgeführt, und die Anwendung wird nicht bereitgestellt.

Die bedingte Logik wird durch Auswerten der BuildingInTeamBuild-Eigenschaft erreicht. Dies ist eine MSBuild-Eigenschaft, die automatisch auf TRUE festgelegt wird, wenn Sie Team Build zum Erstellen Ihrer Projekte verwenden.

Bereitstellung in Staging

Wenn ein Build alle Anforderungen des Entwicklerteams in der Testumgebung erfüllt, möchte das Team möglicherweise denselben Build in einer Stagingumgebung bereitstellen. Stagingumgebungen werden in der Regel so konfiguriert, dass sie den Merkmalen der Produktions- oder Liveumgebung so gut wie möglich entsprechen, z. B. in Bezug auf Serverspezifikationen, Betriebssysteme und Software sowie Netzwerkkonfiguration. Stagingumgebungen werden häufig für Auslastungstests, Benutzerakzeptanztests und umfassendere interne Überprüfungen verwendet. Builds werden direkt vom Buildserver in der Stagingumgebung bereitgestellt.

Die Builddefinitionen, die zum Bereitstellen der Lösung in der Stagingumgebung verwendet werden, DeployToStaging-WhatIf und DeployToStaging, weisen diese Merkmale auf:

• Sie bauen eigentlich nichts. Wenn Rob die Lösung in der Stagingumgebung bereitstellt, möchte er einen bestimmten, vorhandenen Build bereitstellen, der bereits in der Testumgebung überprüft und überprüft wurde. Die Builddefinitionen müssen nur die benutzerdefinierten Projektdateien ausführen, die den Bereitstellungsprozess steuern.
• Wenn Rob einen Build auslöst, verwendet er die Buildparameter, um anzugeben, welcher Build die Ressourcen enthält, die er vom Buildserver bereitstellen möchte.
• Die Builddefinitionen werden nicht automatisch ausgelöst. Rob stellt einen Build manuell in die Warteschlange, wenn er die Lösung in der Stagingumgebung bereitstellen möchte.

Dies ist der allgemeine Prozess für eine Bereitstellung in der Stagingumgebung:

1. Der Stagingumgebungsadministrator Rob Walters stellt einen Build mithilfe der Builddefinition DeployToStaging-WhatIf in die Warteschlange. Rob verwendet die Builddefinitionsparameter, um anzugeben, welchen Build er bereitstellen möchte.
2. Die Builddefinition DeployToStaging-WhatIf führt die benutzerdefinierten Projektdateien im Was-wäre-wenn-Modus aus. Dadurch werden Protokolldateien generiert, als ob Rob eine Livebereitstellung durchführen würde, es werden jedoch keine Änderungen an der Zielumgebung vorgenommen.
3. Rob überprüft die Protokolldateien, um die Auswirkungen der Bereitstellung auf die Stagingumgebung zu ermitteln. Insbesondere möchte Rob überprüfen, was hinzugefügt wird, was aktualisiert wird und was gelöscht wird.
4. Wenn Rob überzeugt ist, dass bei der Bereitstellung keine unerwünschten Änderungen an vorhandenen Ressourcen oder Daten vorgenommen werden, wird ein Build mithilfe der Builddefinition DeployToStaging in die Warteschlange gestellt.
5. Die Builddefinition DeployToStaging führt die benutzerdefinierten Projektdateien aus. Diese veröffentlichen die Bereitstellungsressourcen auf dem primären Webserver in der Stagingumgebung.
6. Der WFF-Controller (Web Farm Framework) synchronisiert die Webserver in der Stagingumgebung. Dadurch wird die Anwendung auf allen Webservern in der Serverfarm verfügbar.

Wie funktioniert der Bereitstellungsprozess?

Die Builddefinition DeployToStaging stellt die folgenden Argumente für MSBuild bereit:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

Die TargetEnvPropsFile-Eigenschaft teilt der Datei Publish.proj mit, wo die zu importierende umgebungsspezifische Projektdatei zu finden ist. Die OutputRoot-Eigenschaft überschreibt den integrierten Wert und gibt den Speicherort des Buildordners an, der die ressourcen enthält, die Sie bereitstellen möchten. Wenn Rob den Build in die Warteschlange stellt, verwendet er die Registerkarte Parameter , um einen aktualisierten Wert für die OutputRoot-Eigenschaft bereitzustellen.

Hinweis

Weitere Informationen zum Erstellen einer Builddefinition wie dieser finden Sie unter Bereitstellen eines bestimmten Builds.

Die Builddefinition DeployToStaging-WhatIf enthält dieselbe Bereitstellungslogik wie die Builddefinition DeployToStaging . Es enthält jedoch das zusätzliche Argument WhatIf=true:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

In der Datei Publish.proj gibt die WhatIf-Eigenschaft an, dass alle Bereitstellungsressourcen im Was-wäre-wenn-Modus veröffentlicht werden sollen. Mit anderen Worten, Protokolldateien werden so generiert, als ob die Bereitstellung vorangegangen wäre, aber in der Zielumgebung wird nichts geändert. Auf diese Weise können Sie die Auswirkungen einer vorgeschlagenen Bereitstellung bewerten, insbesondere, was hinzugefügt wird, was aktualisiert wird und was gelöscht wird, bevor Sie tatsächlich Änderungen vornehmen.

Hinweis

Weitere Informationen zum Konfigurieren von Was-wäre-wenn-Bereitstellungen finden Sie unter Ausführen einer Was-wäre-wenn-Bereitstellung.

Nachdem Sie Ihre Anwendung auf dem primären Webserver in der Stagingumgebung bereitgestellt haben, synchronisiert der WFF die Anwendung automatisch auf allen Servern in der Serverfarm.

Hinweis

Weitere Informationen zum Konfigurieren des WFF zum Synchronisieren von Webservern finden Sie unter Erstellen einer Serverfarm mit dem Webfarm-Framework.

Bereitstellung in der Produktion

Wenn ein Build in der Stagingumgebung genehmigt wurde, kann das Fabrikam, Inc.-Team die Anwendung in der Produktionsumgebung veröffentlichen. In der Produktionsumgebung wird die Anwendung "live" und erreicht die Zielgruppe der Endbenutzer.

Die Produktionsumgebung befindet sich in einem Umkreisnetzwerk mit Internetzugriff. Dies ist vom internen Netzwerk isoliert, das den Buildserver enthält. Die Produktionsumgebungsadministratorin Lisa Andrews muss die Webbereitstellungspakete manuell vom Buildserver kopieren und in IIS auf dem primären Produktionswebserver importieren.

Dies ist der allgemeine Prozess für eine Bereitstellung in der Produktionsumgebung:

1. Das Entwicklerteam teilt Lisa mit, dass ein Build für die Bereitstellung in der Produktion bereit ist. Das Team informiert Lisa über den Speicherort der Webbereitstellungspakete im Drop-Ordner auf dem Buildserver.
2. Lisa sammelt die Webpakete vom Buildserver und kopiert sie auf den primären Webserver in der Produktionsumgebung.
3. Lisa verwendet IIS-Manager, um die Webpakete auf dem primären Webserver zu importieren und zu veröffentlichen.
4. Der WFF-Controller synchronisiert die Webserver in der Produktionsumgebung. Dadurch wird die Anwendung auf allen Webservern in der Serverfarm verfügbar.

Wie funktioniert der Bereitstellungsprozess?

Iis-Manager enthält einen Assistenten zum Importieren von Anwendungspaketen, der das Veröffentlichen von Webpaketen auf einer IIS-Website erleichtert. Eine exemplarische Vorgehensweise zum Ausführen dieses Verfahrens finden Sie unter Manuelles Installieren von Webpaketen.

Zusammenfassung

Dieses Thema enthält eine Abbildung des Bereitstellungslebenszyklus für eine typische Webanwendung auf Unternehmensebene.

Dieses Thema ist Teil einer Reihe von Tutorials, die Anleitungen zu verschiedenen Aspekten der Bereitstellung von Webanwendungen enthalten. In der Praxis gibt es in jeder Phase des Bereitstellungsprozesses viele zusätzliche Aufgaben und Überlegungen, und es ist nicht möglich, alle in einer einzigen exemplarischen Vorgehensweise abzudecken. Weitere Informationen finden Sie in den folgenden Tutorials:

• Webbereitstellung im Unternehmen. Dieses Tutorial bietet eine umfassende Einführung in Webbereitstellungstechniken mit MSBuild und dem IIS-Webbereitstellungstool (Web Deploy).
• Konfigurieren von Serverumgebungen für die Webbereitstellung. In diesem Tutorial erfahren Sie, wie Sie Windows Server-Umgebungen konfigurieren, um verschiedene Bereitstellungsszenarien zu unterstützen.
• Konfigurieren von Team Foundation Server für die automatisierte Webbereitstellung. Dieses Tutorial enthält Anleitungen zum Integrieren der Bereitstellungslogik in TFS-Buildprozesse.
• Erweiterte Enterprise-Webbereitstellung. In diesem Tutorial erfahren Sie, wie Sie einige der komplexeren Herausforderungen bei der Bereitstellung bewältigen können, mit denen Organisationen konfrontiert sind.

Zurück