Share via


Erweiterte webbasierte Unternehmensbereitstellung: Übersicht über das Szenario

von Jason Lee

In diesem Lernprogramm wird eine Beispiellösung mit einem realistischen Komplexitätsgrad zusammen mit einem fiktiven Unternehmensbereitstellungsszenario verwendet, um eine Referenzimplementierung bereitzustellen und den Aufgaben und exemplarischen Vorgehensweisen einen gemeinsamen Kontext zu geben. In diesem Thema wird das Tutorialszenario beschrieben und die Beispiellösung vorgestellt.

Beschreibung des Szenarios

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

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

  • Eine Entwicklertest- oder Sandboxumgebung.
  • Eine intranetbasierte Stagingumgebung.
  • Eine Produktionsumgebung mit Internetzugriff.

Jede dieser Umgebungen hat unterschiedliche Konfigurations- und Sicherheitsanforderungen, und jede stellt besondere Herausforderungen bei der Bereitstellung.

Die Fabrikam, Inc. Serverinfrastruktur

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

Die allgemeine Entwicklungs- und Bereitstellungsinfrastruktur bei Fabrikam, Inc.

Die Entwicklerarbeitsstationen, die Quellcodeverwaltungsinfrastruktur, die Entwicklertestumgebung und die Stagingumgebung befinden sich alle im Intranetnetzwerk innerhalb der domäne Fabrikam.net. Die Produktionsumgebung befindet sich in einem Umkreisnetzwerk (auch als DMZ, demilitarisierte Zone und überprüftes Subnetz bezeichnet), das durch eine Firewall vom Intranetnetzwerk isoliert wird. Dies ist ein häufiges Bereitstellungsszenario: In der Regel isolieren Sie Ihre Webserver mit Internetzugriff von Ihrer internen Serverinfrastruktur durch die Verwendung von Firewalls oder Gatewayservern.

In diesem Beispiel:

  • Ein Team Foundation Server (TFS) 2010-Server mit einem separaten Buildserver bietet Quellcodeverwaltungs- und CI-Funktionen (Continuous Integration).
  • Die Testumgebung für Entwickler umfasst einen Iis 7.5-Webserver (Internetinformationsdienste) und einen SQL Server 2008 R2-Datenbankserver.
  • Die Produktionsumgebung umfasst 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 die Skalierbarkeit und Verfügbarkeit zu verbessern.
  • Die Stagingumgebung ist so konzipiert, dass die Konfiguration der Produktionsumgebung so genau wie möglich repliziert wird.
  • Die Firewall- und Netzwerkisolationsrichtlinien lassen keine direkte, automatisierte Bereitstellung vom Intranet in das Umkreisnetzwerk zu.

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

Teamrollen für ALM

Diese Benutzer sind am Erstellen, Verwalten, Erstellen und Veröffentlichen der Contact Manager-Lösung beteiligt:

  • Matt Hink ist Entwickler von Webanwendungen 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, wodurch er die Umgebung entsprechend seinen Anforderungen konfigurieren kann. Außerdem hat er Benutzerzugriff auf die Visual Studio 2010 TFS-instance wo er den Quellcode für die Contact Manager-Projektmappe speichert.

  • Rob Walters ist Serveradministrator für das Entwicklungsteam von Fabrikam, Inc. Rob verfügt über Administratorzugriff auf den TFS-Server, sodass er alle Aspekte von TFS und TeamBuild konfigurieren kann. Rob verfügt außerdem über Administratorzugriff auf die Test- und Stagingwebserver und fungiert als Datenbankadministrator (DBA) für die Datenbankserver in den Test- und Stagingumgebungen. Rob hat Team Build auf dem TFS-Server konfiguriert, um diese Aufgaben auszuführen:

    • Erstellen und Ausführen von Komponententests für die Anwendung, wenn ein Benutzer eine Datei bei TFS eincheckt. Dies wird als CI bezeichnet.
    • Stellen Sie die Contact Manager-Anwendung automatisch in der Testumgebung bereit, sobald die Anwendung Komponententests bestanden hat. Dies umfasst die Veröffentlichung der Datenbank auf den Testservern bei der ersten Bereitstellung sowie alle Aktualisierungen der Datenbank nach der ersten Bereitstellung.
    • Stellen Sie die Contact Manager-Anwendung in einem einstufigen Prozess in der Stagingumgebung bereit.
    • Erstellen Sie ein Webpaket, das ein Webserveradministrator und ein DBA verwenden können, um die Anwendung in der Produktionsumgebung zu veröffentlichen.
  • Lisa Andrews ist eine Serveradministratorin, die für die Bereitstellung von Anwendungen auf den Produktionsservern von Fabrikam, Inc. verantwortlich ist. Sie hat Lesezugriff auf die Freigabe, in der tfS Team Build das Webbereitstellungspaket speichert, sobald die Contact Manager-Anwendung erstellt wurde. Außerdem hat sie Administratorzugriff auf die Produktionswebserver, damit sie die Anwendung in der Produktion bereitstellen kann. Darüber hinaus fungiert sie als DBA, der Datenbanken und Datenbankupdates auf dem Datenbankserver in der Produktionsumgebung bereitstellt.

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-Projektmappe besteht aus vier einzelnen Projekten:

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

  • ContactManager.Mvc. Dies ist ein ASP.NET MVC3-Webanwendungsprojekt, das den Einstiegspunkt für die Projektmappe darstellt. Es bietet einige grundlegende Webanwendungsfunktionen, z. B. die Möglichkeit, Dass Benutzer Kontaktdetails erstellen und anzeigen können. Die Anwendung basiert auf einem Windows Communication Foundation-Dienst (WCF) zum Verwalten von Kontakten und einer ASP.NET Anwendungsdienstdatenbank zum Verwalten der 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, mit dem Aufrufer CRUD-Vorgänge (Erstellen, Abrufen, Aktualisieren und Löschen) für die Contact Manager-Datenbank ausführen können. Der Dienst basiert auf der Contact Manager-Datenbank und der assembly ContactManager.Common.dll.
  • 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 ihrer Bereitstellungsanforderungen finden Sie im ersten Tutorial dieser Reihe , Webbereitstellung im Unternehmen.

Bereitstellungsaufgaben

Bei der Bereitstellung von Anwendungen in verschiedenen Umgebungen in einem großen organization gibt es mehrere unterschiedliche Aufgaben. Dies sind die wichtigsten Aufgaben, die in den Tutorials behandelt werden:

Bei der Bereitstellung von Anwendungen in verschiedenen Umgebungen in einem großen organization gibt es mehrere unterschiedliche Aufgaben.

Im Folgenden finden Sie eine Liste der einzelnen Schritte im Bereitstellungsprozess aus der Perspektive der benutzer, die weiter oben in diesem Dokument beschrieben wurden:

  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 ersten Test der Bereitstellungslogik durchzuführen.
  3. Matt Hink fügt die Anwendung der 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. Eine weitere Builddefinition ermöglicht es Benutzern, Bereitstellungen in der Stagingumgebung nach Bedarf auszulösen.
  5. Jedes Mal, wenn ein Benutzer neuen Code eincheckt, erstellt Team Build 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 erfolgreich waren.
  6. Wenn ein Benutzer eine Bereitstellung in der Stagingumgebung auslöst, wird die Lösung gepackt und in einem einstufigen Prozess 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 Probleme bei der Bereitstellung

Die Contact Manager-Lösung und das Fabrikam, Inc.-Szenario zeigen verschiedene häufige Probleme und Herausforderungen auf, die bei der Bereitstellung komplexer Lösungen auf Unternehmensebene auftreten können. Zum Beispiel:

  • Sie müssen In der Lage sein, Projekte in mehreren Umgebungen bereitzustellen, 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 gleichzeitig im Rahmen eines einstufigen oder automatisierten Build- und Bereitstellungsprozesses bereitstellen.
  • Sie müssen in der Lage sein, die Bereitstellung über einen automatisierten Prozess zu steuern. Sie möchten beispielsweise einen CI-Prozess verwenden, um Webanwendungen in einer Stagingumgebung bereitzustellen, wenn neuer Code eingecheckt wird.
  • Sie müssen in der Lage sein, den Bereitstellungsprozess zu steuern und Bereitstellungsvariablen außerhalb von Visual Studio festzulegen, 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 bei nachfolgenden Bereitstellungen beibehalten.
  • Sie müssen Mitgliedschaftsdatenbanken ad hoc 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 stellt die Verwaltung der Bereitstellung bei häufigen und inkrementellen Updates einige zusätzliche Herausforderungen. Zum 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 besteht.
  • 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 die aktuelle Bereitstellung wiederholen oder stattdessen das vorherige Webpaket bereitstellen.