ALM Kaffeekränzchen V – Dual Landscape Teil 3
Zwei Landschaften für ein Produktivsystem
Wie von der FB Methodik empfohlen, entfalten sich die Projekt-gesteuerten Änderungen entlang einer 4-systemigen Projektlandschaft, die ein zusätzliches Pre-Production System enthält.
Es gibt verschiedene Szenarien für den Cutover (Go-Live) eines Releases aus der Projektlandschaft in das gemeinsame Produktivsystem, man siehe die Auflistung in der FB Configuration Guide, Kapitel „Cutover Checks and Post Cutover Activities: Configuration – Overview“.
Wir entscheiden uns für das in der FB Configuration Guide so benannte „Szenario 1“, weil es mit unserem Vorschlag der Koexistenz von Major und Minor Releases besser zusammenpasst.
Projekte
Eines der grossen Vorteile der schlüsselfertigen Lösung Focused Build ist die fest vorgegebene Strukturierung der Projekte mit ihren Phasen und den vorgegebenen Quality Gates. FB folgt dem agilen Projekt-Paradigma und organisiert die Arbeit in der entscheidenden Realisierungsphase in Waves und Sprints. Wer Wasserfall-Projekte bevorzugt, legt einfach pro Projekt nur eine Wave und einen Sprint an.
Pre-Production System
Das Pre-Production System ist kein zweites QA System. Sein Vorteil liegt auf der Hand: Die dort stattfindenden Integrations- und Regressionstests werden nicht durch ständige neue Importe invalidiert. Denn jede Änderung erzwingt die Wiederholung der Tests: Durch die Änderung könnte sich ja ein neuer Seiteneffekt eingeschlichen haben.
In der Testphase auf dem Pre-Production System sind nur noch Korrekturen der beim Testen entdeckten Fehler erlaubt. Hierzu bietet Focused Build die spezialisierte „Defect Correction“ Vorgangsart an.
Die Entwicklung kann während des Freeze des Pre-Production System weitergehen, doch sie erfolgt für das nächste Release oder den nächsten Phasenzyklus.
Im Pre-Production System wird umfangreich und intensiv all das und nur das getestet, was im nächsten Go-Live tatsächlich produktiv gehen wird.
Wartung
Da die FB Methodik einen Projektplan mit vielen Q-Gates erwartet, empfehle ich für Transporte innerhalb der Wartungslandschaft die Verwendung der klassischen ChaRM Change Documents. Solange tatsächlich nur Korrekturen und kleinere Anpassungen an bestehenden Prozessen hier erfolgen, sollten in der Wartungs-Landschaft drei Systeme reichen.
Bei aktivem FB wird stand heute (FB SP10) bei Minor Release Zyklen die Verwendung von Request for Changes oder IT Requirements leider nicht im Standard unterstützt. Wer in der Wartungslandschaft den RfC für einen Genehmigungsworkflow benötigt, muss statt Minor Release Zyklen „normale“ Phasen-Zyklen anlegen1.
Aus dem Labor
Es sei hier auf einem Solution Manager Sandbox-System die Dual System Landschaft mit Major und Minor Releases skizziert.
Der Kürze halber setze ich voraus, dass die SAP Dokumentation der verwendeten Werkzeuge und das FB spezifische IMG bekannt sind.
Die zwei Systemlandschaften
Wartungslandschaft
Projektlandschaft
Change Control Landscape
Wir gönnen unserer Demo eine eigene Change Control Landscape (CCL), denn das Releasemanagement basiert auf diese. Eine CCL kann nur ein Release haben.
Da wir die Projekt-Landschaft mit FB bedienen möchten, müssen wir die neue CCL im Customizing konfigurieren (s.u.), und beim Start der CRM WebUI müssen wir die Business Rolle „/SALM/RLSMNG – Release Manager“ auswählen.
Major Releases
Wir gehen in die Release-Planung und planen ein ganzes Jahr im Voraus. Es ist bequemer, zuerst nur die Major Releases anzulegen, und die Minor zu den Major danach.
Da die Minor Releases nur nach dem Go-Live des vorherigen Major Releases möglich sind (es gibt kein Release 0), setzen wir in unserer Demo den initialen Release einfach auf den nächstbesten Termin. Wenn man bereits standard ChaRM einsetzt, kann man auf diese kleine Starthilfe verzichten, indem man bis zum Go-Live des Releases 1.0 die Maintenance-Landschaft mit ChaRM bedient wie bisher (klingt ChaRMant, nicht wahr?).
Üblicherweise werden die grossen Projekt-Go-Live am Wochenende durchgeführt.
Wir fügen jetzt ein Relase Zyklus hinzu.
Beim allerersten Mal wird der Aufgabenplan für die Projektlandschaft angelegt. Alle weiteren Zyklen werden sich diesen Aufgabenplan teilen.
Minor Releases
Jetzt markieren wir das Release 1.0 und fügen 14-tägige Minor Releases für die Maintenance-Landschaft hinzu. Wir wählen Donnerstag für den Go-Live Tag. So hat man bei eventuellen Go-Live Problemen noch den Freitag für notwendige Korrekturen zur Verfügung.
Abbildung 14 Ein Paket von Minor Releases
Wir passen die Termine manuell an. Release 1.6 muss leider in einem zweiten Schritt hinzugefügt werden, da die Anwendung einfach zu intelligent ist bei der Berechnung der Termine und sich weigert, in einem Quartal 6 Minor Releases auf einen Schlag anzulegen.
Und dies ist der Aufgabenplan für die Maintenance-Landscape:
Customizing Phasenmodel
Um bei aktivem FB auch für die Minor Releases der Wartungslandschaft Request for Change anlegen zu können, muss man folgende Einträge über den View-Cluster /TMWFLOW/VC_PHMD hinzufügen:
Möchten sie den nächsten Teil nicht verpassen? dann können sie diesen hier nachlesen.
- Hintergrund:
Bei aktivem FB wird die Release-Vorgangsart S1MR verwendet. S1MR hat das Phasen-Model „S1RL“, und diesem fehlen in der Tabelle /TMWFLOW/TPPHMAC Einträge für den klassischen RfC. Möchte man trotzdem RfCs für ein Minor Release anlegen, muss man die Einträge „RFC_CREATE“ oder „ITR_CREATE“ von „RELE“ passend für „S1RL“ kopieren. Siehe das Beispiel aus Kapitel „Customizing Phasenmodel“ Übrigens, mit FB SP11 wird Focused Build auch den „Request To Fulfill“ Prozess in der Maintenance Landschaft unterstützen. ↩︎
