Beispielszenario: Verwalten von Releasedatensätzen
Gilt für: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager
Mit diesem Beispielszenario für System Center 2012 – Service Manager werden Sie beim Erreichen Ihres Ziels unterstützt, Releasedatensätze mithilfe mehrerer Szenarien durchgängig zu verwalten. Betrachten Sie dieses Beispielszenario als eine Fallstudie, die einen Kontext für einzelne Szenarien und Verfahren liefert.
Szenarien für die Verwaltung von Releasedatensätzen
| Szenario | Beschreibung |
|---|---|
| Gewusst wie: Erstellen eines Datensatzes Version | Hier wird beschrieben, wie ein Releasedatensatz erstellt wird. |
| Gewusst wie: erstellen eine Datensatzvorlage Version | Hier wird beschrieben, wie eine Releasedatensatzvorlage erstellt wird. |
| Kombinieren von Releasedatensätzen in übergeordneten/untergeordneten Gruppen | Hier wird beschrieben, wie Releasedatensätze in Parent-Child-Gruppen kombiniert werden. |
| Definieren von Konfigurationselementen für Versionspakete | Hier wird beschrieben, wie Konfigurationselemente für Releasepakete definiert werden. |
| Gewusst wie: Erstellen einer Vorlage für parallele und sequenzielle Aktivitäten | Hier wird beschrieben, wie Vorlagen für parallele und sequenzielle Aktivitäten erstellt werden, die in Releasedatensätzen verwendet werden. |
| Zum Auswählen der Änderungen zum Bereitstellen von | Hier wird beschrieben, wie bereitzustellende Änderungen überprüft und ausgewählt werden. |
| Planen der Veröffentlichung Aktivitäten | Hier wird beschrieben, wie Releaseaktivitäten geplant werden. |
| Wie Sie eine fehlerhafte Aktivität überspringen | Hier wird beschrieben, wie eine Aktivität, bei der ein Fehler aufgetreten ist, übersprungen wird. |
| Bestimmen des Status und Fortschritts für einen Change Request im Releasedatensatz | Hier wird beschrieben, wie der Status und Fortschritt für eine in einem Releasedatensatz enthaltenen Änderungsanforderung ermittelt wird. |
Szenario zum Verwalten von Releasedatensätzen
IT-Manager am Standort Brandenburg verwalten mehrere Projekte gleichzeitig. Normalerweise haben IT-Projektteams in der Organisation keinen Zugriff auf die kontrollierte Produktionsumgebung. Darüber hinaus ist der Zugriff auf die Präproduktionsumgebung eingeschränkt. Die IT-Organisation führt Projekte aus, entwickelt Finanzanwendungen und Verbesserungen für die Infrastruktur. Wenn es erforderlich ist, einen Teil der kontrollierten Produktionsumgebung zu ändern, reicht das IT-Projektteam Änderungsanforderungen zur Aktualisierung der Infrastruktur, einer Anwendung oder eines Produkts oder zum Implementieren neuer Prozesse ein.
Die Releaseverwaltung beginnt, sobald genehmigte Änderungen vorhanden sind. Laut den Richtlinien des Unternehmens müssen die Änderungen durch Releaseverwaltungsprozesse bereitgestellt werden. Der Releasemanager Garret erstellt einen übergeordneten Releasedatensatz, entwirft dann ein allgemeines Diagramm des Releases und verknüpft allgemeine Aktivitäten mit einer Änderungsanforderung. Die Releaseaktivität in einem Releasedatensatz wird mit einer vorhandenen Bereitstellungsaktivität in einer Änderungsanforderung verknüpft. Garret oder ein beauftragter Aktivitätsdesigner fügt dann dem Releasedatensatz nach Bedarf untergeordnete Releasedatensätze und neue Aktivitäten hinzu, mit denen die Schritte beschrieben werden, die zum Bereitstellen der Änderung erforderlich sind. Dieser Vorgang wird für jede Änderungsanforderung wiederholt, um so die gewünschte Detailebene zu ermöglichen. In den Releasedatensatz kann je nach Bedarf der Organisation eine beliebige Anzahl Änderungsanforderungen einbezogen werden. Wenn eine Änderungsanforderung implementiert werden kann, kennzeichnet der Änderungsimplementierer entsprechende Aktivitäten als abgeschlossen.
Am Standort Brandenburg werden Updates (auch als Releases bezeichnet) normalerweise einmal im Monat in der Produktionsumgebung bereitgestellt. Garret möchte mehrere Releases, die er im Juni-Release, im Juli-Release usw. definiert hat, in einem Paket zusammenfassen. Er definiert diese Releases als übergeordnete Releases und verknüpft alle netzwerk- und datenbankbezogenen Releases mit dem übergeordneten Juni-Release und ein anwendungsbezogenes Release mit dem übergeordneten Juli-Release. Zudem fügt der dem Juni-Release die neue Aktivität „Netzwerk mit Datenbankintegration testen“ hinzu, um sicherzustellen, dass beide untergeordneten Releases zusammen verwendet werden können.
Das nächste größere Release für den Standort Brandenburg ist eine Bereitstellung einer neuen Version der Webanwendung HRWeb. Die Entwickler von HRWeb haben dem Releaseverwaltungsteam einen neuen Build der HRWeb-Anwendung gegeben. Das Releaseverwaltungsteam am Standort Brandenburg wertet den Build in der Testumgebung aus, findet kritische Probleme im Build und bittet die Entwickler, das Problem zu beheben und einen neuen Build bereitzustellen. Das Entwicklungsteam stellt einen neuen Build bereit, und das Releaseverwaltungsteam testet ihn in der Testumgebung erfolgreich. Der Build wird an die Präproduktionsumgebung weitergegeben. Dort wird er zwei Wochen getestet und in der Präproduktionsumgebung verwendet. Wenn die Tests erfolgreich abgeschlossen werden, wird der Build in der Produktionsumgebung bereitgestellt. Während dieses Vorgangs erstellt Garret ein neues Buildkonfigurationselement, verknüpft es mit dem Konfigurationselement der HRWeb-Software und anschließend mit dem Releasepaket des Releasedatensatzes. Nachdem der letzte Build in der Produktionsumgebung bereitgestellt wurde, aktualisiert Garret die Versionsinformationen im Konfigurationselement der HRWeb-Software und schließt den Releasedatensatz.
Am Standort Brandenburg konfiguriert Garret administrative Einstellungen für Releases und erstellt einen übergeordneten Releasedatensatz. Er erstellt auch Vorlagen für parallele und sequenzielle Aktivitäten. Anschließend erstellt Rainer anhand der von Garret erstellten Vorlagen Releasedatensätze. Rainer gibt an, welche Änderungen bereitgestellt werden und aktualisiert Releaseaktivitäten, indem er diese für jedes Release nach Bedarf hinzufügt, löscht oder ändert. Garnett konfiguriert Benachrichtigungen für Releasedatensätze, um Benutzer zu benachrichtigen. Garret und Rainer können den Status und den Fortschritt von Änderungsanforderungen für ein Release bei Bedarf jederzeit prüfen.