Enterprise Web Deployment: Szenarioübersicht

von Jason Lee

Diese Reihe von Lernprogrammen verwendet eine Beispiellösung mit einer realistischen Komplexitätsstufe zusammen mit einem fiktiven Unternehmensbereitstellungsszenario, um eine Referenzimplementierung bereitzustellen und die Aufgaben und exemplarischen Vorgehensweisen einem gemeinsamen Kontext zu verleihen. In diesem Thema wird das Lernprogrammszenario beschrieben und die Beispiellösung vorgestellt.

Szenariobeschreibung

Fabrikam, Inc., ein fiktives Unternehmen, erstellt eine Lösung, mit der Remote-Vertriebsteams Kontaktinformationen über eine Weboberfläche speichern und abrufen können.

Die Application Lifecycle Management (ALM)-Prozesse bei Fabrikam, Inc. erfordern die Bereitstellung der Lösung in drei Serverumgebungen in verschiedenen Phasen des Softwareentwicklungsprozesses:

• Eine Entwicklertest- oder Sandkastenumgebung.
• Eine intranetbasierte Stagingumgebung.
• Eine in das Internet gerichtete Produktionsumgebung.

Jede dieser Umgebungen weist unterschiedliche Konfigurations- und Sicherheitsanforderungen auf, und jede stellt einzigartige Bereitstellungsprobleme dar.

Die Serverinfrastruktur von Fabrikam, Inc.

Dies ist die hochrangige Entwicklungs- und Bereitstellungsinfrastruktur bei Fabrikam, Inc.

Die Entwicklerarbeitsstationen, die Quellcodeverwaltungsinfrastruktur, die Entwicklertestumgebung und die Stagingumgebung befinden sich alle im Intranetnetzwerk innerhalb der Fabrikam.net Domäne. Die Produktionsumgebung befindet sich in einem Umkreisnetzwerk (auch als DMZ, demilitarisierte Zone und abgeschirmtes Subnetz bezeichnet), das von einem Intranetnetzwerk durch eine Firewall isoliert ist. Dies ist ein gängiges Bereitstellungsszenario: In der Regel isolieren Sie Ihre internetbasierten Webserver über die Verwendung von Firewalls oder Gatewayservern von Ihrer internen Serverinfrastruktur.

In diesem Beispiel:

• Ein Team Foundation Server (TFS) 2010-Server mit einem separaten Buildserver bietet Funktionen für die Quellcodeverwaltung und kontinuierliche Integration.
• Die Entwicklertestumgebung umfasst einen Internetinformationsdienste (IIS) 7.5-Webserver und einen SQL Server 2008 R2-Datenbankserver.
• Die Produktionsumgebung enthält mehrere IIS 7.5-Webserver, die von einem WFF-Controllerserver (Web Farm Framework) synchronisiert werden, zusammen mit einem SQL Server 2008 R2-Datenbankserver. In der Praxis kann der Datenbankserver Clustering oder Spiegelung verwenden, um Skalierbarkeit und Verfügbarkeit zu verbessern.
• Die Stagingumgebung soll die Konfiguration der Produktionsumgebung so genau wie möglich replizieren.
• Die Firewall- und Netzwerkisolationsrichtlinien erlauben keine direkte, automatisierte Bereitstellung vom Intranet bis zum Umkreisnetzwerk.

Die Konfiguration jeder dieser Umgebungen wird im zweiten Lernprogramm, Konfigurieren von Serverumgebungen für die Webbereitstellung, ausführlicher beschrieben.

Teamrollen für ALM

Diese Benutzer sind an der Erstellung, Verwaltung, Erstellung und Veröffentlichung der Contact Manager-Lösung beteiligt:

• Matt Hink ist ein Webanwendungsentwickler bei Fabrikam, Inc. Er ist Teil des Teams, das die Contact Manager-Lösung mithilfe von Visual Studio 2010 entwickelt hat. Matt verfügt über vollständige Administratorrechte auf den Servern in der Entwicklertestumgebung, mit der er die Umgebung so konfigurieren kann, dass er seine Anforderungen erfüllt. Außerdem hat er Benutzerzugriff auf die Visual Studio 2010 TFS-Instanz, in der er den Quellcode für die Contact Manager-Lösung speichert.

• Rob Walters ist Serveradministrator des Entwicklungsteams Fabrikam, Inc. Rob hat administrativen Zugriff auf den TFS-Server, damit er alle Aspekte von TFS und Team Build konfigurieren kann. Rob verfügt außerdem über administrativen Zugriff auf die Test- und Staging-Webserver und fungiert als Datenbankadministrator (DBA) für die Datenbankserver in den Test- und Stagingumgebungen. Rob hat Team Build auf dem TFS-Server für die Ausführung dieser Aufgaben konfiguriert:

  • Erstellen und Ausführen von Komponententests für die Anwendung, wenn ein Benutzer eine Datei in TFS eincheckt. Dies wird ALS CI bezeichnet.
  • Stellen Sie die Contact Manager-Anwendung automatisch in der Testumgebung bereit, sobald die Anwendung Komponententests bestanden hat. Dazu gehört die Veröffentlichung der Datenbank auf den Testservern bei der erstbereitstellung sowie alle Aktualisierungen der Datenbank nach der erstbereitstellung.
  • Stellen Sie die Contact-Manager-Anwendung in einem einstufigen Prozess in der Staging-Umgebung bereit.
  • Erstellen Sie ein Webpaket, mit dem ein Webserveradministrator und ein DBA die Anwendung in der Produktionsumgebung veröffentlichen können.

• Lisa Andrews ist ein Serveradministrator, der für die Bereitstellung von Anwendungen auf den Produktionsservern Fabrikam, Inc. zuständig ist. Sie hat Lesezugriff auf die Freigabe, in der der TFS-Team Build das Webbereitstellungspaket speichert, nachdem es die Contact Manager-Anwendung erstellt hat. Außerdem hat sie administrativen Zugriff auf die Produktionswebserver, damit sie die Anwendung in der Produktion bereitstellen kann. Darüber hinaus fungiert sie als DBA, die Datenbanken und Datenbankaktualisierungen auf dem Datenbankserver in der Produktionsumgebung bereitstellt.

Die Contact Manager-Lösung

Die Contact Manager-Lösung ist so konzipiert, dass registrierte, angemeldete Benutzer Kontaktinformationen über eine Weboberfläche hinzufügen und bearbeiten können. Die Contact Manager-Lösung besteht aus vier einzelnen Projekten:

• ContactManager.Mvc. Dies ist ein ASP.NET MVC3-Webanwendungsprojekt, das den Einstiegspunkt für die Lösung darstellt. Es bietet einige grundlegende Webanwendungsfunktionen, z. B. die Möglichkeit, Kontaktdetails zu erstellen und anzuzeigen. Die Anwendung basiert auf einem Windows Communication Foundation (WCF)-Dienst zum Verwalten von Kontakten und einer ASP.NET Anwendungsdienstdatenbank zum Verwalten von Authentifizierung und Autorisierung.
• ContactManager.Database. Dies ist ein Visual Studio 2010-Datenbankprojekt. Das Projekt definiert das Schema für eine Datenbank, in der Kontaktdetails gespeichert werden.
• ContactManager.Service. Dies ist ein WCF-Webdienstprojekt. Der WCF macht einen Endpunkt verfügbar, der Es Anrufern ermöglicht, Erstellungs-, Abruf-, Aktualisierungs- und Löschvorgänge (CRUD) in der Contact Manager-Datenbank auszuführen. Der Dienst basiert auf der Contact Manager-Datenbank und der ContactManager.Common.dll Assembly.
• ContactManager.Common. Dies ist ein Klassenbibliotheksprojekt. Der WCF-Dienst basiert auf Typen, die in dieser Assembly definiert sind.

Eine vollständige Überprüfung der Lösung und der zugehörigen Bereitstellungsanforderungen finden Sie im ersten Lernprogramm dieser Reihe, Webbereitstellung im Unternehmen.

Bereitstellungsaufgaben

Es gibt mehrere unterschiedliche Aufgaben, die bei der Bereitstellung von Anwendungen in verschiedenen Umgebungen in einer großen Organisation erforderlich sind. Dies sind die wichtigsten Aufgaben, die in den Lernprogrammen behandelt werden:

Im Folgenden finden Sie eine Liste der einzelnen Schritte im Bereitstellungsprozess aus der Perspektive der weiter oben in diesem Dokument beschriebenen Benutzer:

1. Alle Mitglieder des Teams überprüfen die Contact Manager-Lösung in Visual Studio 2010, um die wichtigsten Bereitstellungsanforderungen und Probleme zu ermitteln.
2. Matt Hink kann die Contact Manager-Lösung direkt von der Entwicklerarbeitsstation in der Entwicklertestumgebung bereitstellen, um einen anfänglichen Test der Bereitstellungslogik durchzuführen.
3. Matt Hink fügt die Anwendung zur Quellcodeverwaltung in TFS hinzu.
4. Rob Walters erstellt verschiedene Builddefinitionen für die Contact Manager-Lösung in Team Build. Eine Builddefinition verwendet CI, um die Lösung in der Entwicklertestumgebung bereitzustellen, wenn ein Benutzer neuen Code eincheckt. Mit einer anderen Build-Definition können Benutzer Bereitstellungen in der Staging-Umgebung bei Bedarf auslösen.
5. Jedes Mal, wenn ein Benutzer neuen Code eincheckt, erstellt TeamBuild automatisch die Lösungskomponenten, führt Komponententests aus und stellt die Lösung in der Entwicklertestumgebung bereit, wenn der Build erfolgreich war und die Komponententests bestehen.
6. Wenn ein Benutzer eine Bereitstellung in der Stagingumgebung auslöst, wird die Lösung in einem einzelstufigen Prozess verpackt und bereitgestellt. Dieser Prozess generiert auch ein Paket für die manuelle Bereitstellung in der Produktionsumgebung.
7. Lisa Andrews stellt die Anwendung in der Produktionsumgebung bereit, indem das in Schritt 6 erstellte Webpaket manuell importiert wird.

Wichtige Bereitstellungsprobleme

Die Contact Manager-Lösung und das Szenario Fabrikam, Inc. heben verschiedene häufige Probleme und Herausforderungen hervor, die beim Bereitstellen komplexer Lösungen im Unternehmensmaßstab auftreten können. Beispiel:

• Sie müssen Projekte in mehreren Umgebungen bereitstellen können, z. B. Entwickler- oder Testumgebungen, Stagingplattformen und Produktionsserver. Die Lösung muss mit unterschiedlichen Konfigurationseinstellungen für jede Umgebung bereitgestellt werden.
• Sie müssen mehrere abhängige Projekte im Rahmen eines einzelstufigen oder automatisierten Build- und Bereitstellungsprozesses gleichzeitig bereitstellen.
• Sie müssen in der Lage sein, die Bereitstellung aus einem automatisierten Prozess zu steuern. Sie möchten z. B. einen CI-Prozess verwenden, um Webanwendungen in einer Stagingumgebung bereitzustellen, wenn neuer Code eingecheckt wird.
• Sie müssen den Bereitstellungsprozess steuern und Bereitstellungsvariablen von außerhalb von Visual Studio festlegen können, da Entwickler wahrscheinlich nicht über die richtigen Konfigurationseinstellungen oder die erforderlichen Anmeldeinformationen für jede Zielumgebung verfügen.
• Sie müssen schemabasierte Datenbankprojekte bereitstellen und vorhandene Daten für nachfolgende Bereitstellungen beibehalten.
• Sie müssen Mitgliedschaftsdatenbanken auf Ad-hoc-Basis bereitstellen, ohne Benutzerkontodaten bereitzustellen. Möglicherweise müssen Sie auch das Schema der bereitgestellten Mitgliedschaftsdatenbanken aktualisieren, ohne vorhandene Benutzerkontodaten zu verlieren.
• Sie müssen bestimmte Dateien oder Ordner ausschließen, wenn Sie Inhalte in verschiedenen Zielumgebungen bereitstellen.

Darüber hinaus löst die Verwaltung der Bereitstellung bei häufigen und inkrementellen Updates einige zusätzliche Herausforderungen aus. Beispiel:

• Sie führen Komponententests jedes Mal aus, wenn ein Entwickler neuen Code eincheckt. Sie möchten die Lösung nur bereitstellen, wenn der Code die Komponententests bestanden hat.
• Wenn Sie eine Webanwendung in einer Staging- oder Produktionsumgebung bereitstellen, möchten Sie Benutzer für die Dauer des Bereitstellungsprozesses an eine app_offline.htm Datei umleiten.
• Sie möchten Bereitstellungsaktivitäten protokollieren. Der Bereitstellungsprozess sollte E-Mail-Benachrichtigungen über erfolgreiche oder fehlgeschlagene Bereitstellungen an bestimmte Empfänger senden.
• Wenn eine automatisierte Bereitstellung fehlschlägt, sollte der Bereitstellungsprozess stattdessen die aktuelle Bereitstellung wiederholen oder das vorherige Webpaket bereitstellen.