ALM Kaffeekränzchen V – Dual Landscape Teil 2

Release Management

Der Grundgedanke des Release Managements ist, dass alle Projekte gemeinsame Test- und Go-Live Phasen sich teilen.

Anfangs muss sich der Change oder Release Manager gegen den Projekt-Egoismus stemmen („Unser Go-Live Termin ist heilig“): Keine leichte Aufgabe, da Projekte voller Budget und strategischer Bedeutung sind, und dadurch sehr mächtig.

Aber die Change oder Release Manager/in hat sehr gute Argumente auf seiner Seite.

Ist nämlich das Produktivsystem nicht noch strategischer als das allerwichtigste Projekt?

Ja, es ist sogar lebensnotwendig für das Unternehmen oder die Behörde. Wegen der Eigenart der ABAP Instanzen, laufende Programme mit einem Short Dump abzubrechen, wenn sich die ausführbare Einheit (Ladephase) zur Laufzeit geändert hat, bedeutet jeder Go-Live einen Stress des Produktivsystems. Oft wird dabei eine Downtime benötigt. Ein gemeinsames Go-Live der Projekte wird daher das Risiko von Abbrüchen und die Kosten der Downtime minimieren.

Gemeinsame Integrations- und Regressionstests erhöhen die Qualität des Releases, da dabei versteckte Seiteneffekte entdeckt werden können, denn im Produktivsystem treffen sowieso sämtliche Änderungen aufeinander. Auch minimiert man den Testaufwand: Die Regressionstests validieren die Kernprozesse gleichzeitig für alle parallelen Projekte: Eine enorme Ersparnis!

Der einzige Nachteil des Release Managements ist, dass die fest eingeplanten Go-Live Termine eine gewisse Flexibilität – Agilität ist das Modewort – beim Umfang der einzuführenden Funktionen voraussetzt: Ist die Entwicklung oder der Test einer Funktionalität nicht fertig, muss sie dem nächsten Release zugeordnet werden. Dies schmerzt anfangs. Dieses moderne agile Vorgehen benötigt daher eine Trainings- und Eingewöhnungsphase, auch wird es anfangs viele Diskussionen geben, doch mit der Zeit setzt sich die Taktung der Einführungen durch.

Gute Planung und gutes Monitoring der Projektfortschritte ist hier Trumpf!

Major und Minor Releases

Major Releases

Die Projekte bewegen sich im Rahmen der Major Releases, die i.d.R. drei bis sechs Monate benötigen. Wenn ein Projekt eine noch längere Laufzeit benötigt, dann wählt es einfach den Go-Live Termin eines passenden höheren Releases.

Solche Major Releases beinhalten grosse Änderungen auch an den Kernprozessen und benötigen daher vollständige Regressions- und Integrations-Tests.

Jährliche Upgrades

Eine empfehlenswerte Praxis ist es, vier grosse Releases pro Jahr zu planen und das zweite Quartal für Upgrades zu reservieren.

Hat sich dieses Vorgehen erstmals eingebürgert, verliert man keine Zeit mehr mit Diskussionen, wann die IT ein Fenster für einen Upgrade bekommt: In der Regel nie!

Nicht nur erhält man durch regelmässige Upgrades die neuesten Features und Fiori-Apps. Sondern man vermeidet auch den Aufwand für die Identifikation und Meldung bereits behobener Fehler.

Durch die jährliche Regelmässigkeit der Upgrades wird das Delta zwischen den SAP Releases kleiner, und die durchführenden Teams werden routinierter und effizienter: Die Upgrades gehen viel schneller und schmerzloser über die Bühne, denn je grösser das Delta, um so komplexer wird das Upgrade-Projekt.

Schliesslich wird ein jährlicher regelmässiger Upgrade die Kostenfalle vermeiden, das System für eine aggressive Neueinführung nur mit dem Einspielen vieler SAP Hinweise (Korrekturen) vorbereiten zu versuchen, um später, durch bittere Erfahrung klug geworden (da haben wir es wieder!), einsehen zu müssen, dass ein Upgrade sich doch nicht vermeiden lässt (habe ich z.B. bei einer Brasilien-Einführung so erlebt). Natürlich wird durch dieses naive Vorgehen das Projekt verzögert.

Minor Releases

Minor Releases haben eine kürzere Laufzeit. Sie bündeln Fehlerkorrekturen und kleinere Erweiterungen; sie gehen viel öfter Live und benötigen nur die Regressions-Tests der Kernprozesse und die Tests der jeweiligen Erweiterung.

In einer dualen Landschaft erfolgt die Wartung in einer eigenen Transportlandschaft, der Maintenance-Landschaft.

Wenn man in Systemen mit aktivem FB Minor Releases zusammen mit Major Releases planen möchte, muss man die Einschränkung in Betracht ziehen, dass man ohne zusätzliches Customizing keine Request-for-Changes (RfC) verwenden kann, was für alle Unternehmen akzeptabel ist, die sowieso den RfC-Workflow in ein externes Ticketing-System ausgelagert haben.

Standard ChaRM

Spart man sich hingegen die nicht unerheblichen Kosten für ein externes Ticketing-System und verwendet stattdessen den eingebauten Request for Change (RfC) Workflow, so verwende man für die Maintenance-Landschaft den klassischen ChaRM ohne Release-Management. Dann ist man mit der Planung der Go-Live Termine der Wartung flexibler.

FB Enhance Pace

Seit SAP Solution Manager SP16 (Focused Build SP11) kann man auch statt des klassischen ChaRMs den neuen Focused Build ENH Pace einsetzen. Dies bietet sich an, wenn man Focused Build bereits für den Requirement2Deploy Prozess einsetzt. Man muss dann nicht den standard ChaRM konfigurieren, sondern kann diese schlüsselfertige Lösung verwenden, auch bewegen sich die Team-Mitglieder in der gewohnten Fiori-Umgebung.

Nachteil ist, dass FB ENH Pace nur Continual Cycles unterstützt, also Zyklen, die nur die Phase „Active“ und Einzeländerungen kennen. Damit eignet er sich eher für einen reinen Detect2Correct Prozess, bei dem einzelne Fehlerkorrekturen ohne potenzielle Seiteneffekte durchgeführt werden. Denn im Falle eines Vorabimports wird der Transport endgültig in das Produktiv-System importiert, mögliche Inkonsistenzen können nicht wie bei den Phasen-Zyklien später durch den Zyklus-Import konsolidiert werden.

Gebündelte Produktiv-Importe

Ein regelmässiges Go-Live Ereignis in der Wartungslandschaft (z.B. jeden zweiten Donnerstag um 10:00 UTC) hat den grossen Vorteil, dass diese Termine im Laufe der Zeit allen Beteiligten, insbesondere den Anwendern der Fachabteilungen, bekannt werden, und alle sich automatisch danach richten.

Diese Regelmässigkeit erfolgt sozusagen freiwillig durch Verwendung der Phasen-Zyklen des Standard ChaRMs. Jedoch die strenge Planung der Go-Live Termine durch das Release-Management erzwingt diese Regelmässigkeit.

Sowohl Release- als auch Phasen-Zyklen unterstützen die Qualität der Tests, indem sie in der Phase Test das Testsystem gegen normale Änderungen sperren.