ALM Kaffeekränzchen V – Dual Landscape Teil 4

Praxis

Nach so viel Theorie wollen wir jetzt beobachten, wie die Duale Landschaft in der Praxis gelebt wird.

Zunächst arbeiten beide Teams (Projekt und Maintenance) getrennt, jedes mit seiner Taktung. Beide Teams können, wenn notwendig, dank der Vorabimport Funktionalität des Work Items (S1MJ) und des Normal Changes (SMMJ) eine Änderung vor dem geplanten Go-Live produktiv setzen. Meistens entsteht dieser Wunsch in der Wartungs-Schiene. Aber das sollten Ausnahmen bleiben.

Bei solchen Ausnahmen sollte man auf jeden Fall die Urgent Corrections (S1HF/SMHF) meiden, denn diese sind sehr gefährlich, da sie den originalen Transport bereits beim Status-Wechsel auf „ToBeTested“ freigeben, daher muss diese Zeitbombe so schnell wie möglich produktiv gesetzt werden (siehe meinen Blog, Kapitel „Hotfix“).

Projekte

Focused Build: Neben dem in Teil 1  erwähnten sehr nützlichen openSAP Kurs sei hier auf das SAP eigene ALM Media Center verwiesen.

Die FB Methodik knapp zusammengefasst:

• Die Projekt-Teams arbeiten getaktet durch Waves und Sprints; Werkzeuge der Entwicklung sind Requirements, die vom Business zu den jeweiligen Prozessen und/oder Prozessschritten in der Solution Documentation angelegt werden, die dann vom Software Architekten in Work Packages (WP) pro Wave in die Entwicklung übernommen werden und in Work Items (WI) pro Sprint heruntergebrochen werden.
• Getestet wird mit leicht zu generierenden Testplänen und Testpaketen.

Umfangreiche Überprüfungen stellen sicher, dass zu jedem Status der WPs und WIs die passenden Dokumentationen vorhanden sind.

Ein umfangreiches Dashboard Angebot begleitet die Steuerung des Ganzen. Was kann da schon schief gehen, möchte ich augenzwinkernd und arbeitslos geworden hinzufügen.

Wartung

Währenddessen reagiert das Wartungs-Team auf Störungsmeldungen (Incidents) mit den notwendigen Fehlerkorrekturen und realisiert eventuell kleine Änderungswünsche aus dem Fachbereich, die mit jedem Minor Release oder Zyklus-Go-Live zum Beispiel alle zwei Wochen produktiv gesetzt werden.

Die Kunst der Fuge

Doch nun fragt man sich irgendwann: Ja, aber was passiert, wenn beide Teams, Projekt und Wartung, dasselbe Objekt gleichzeitig ändern? Genau diese mögliche Kollision ist der Knackpunkt einer dualen Landschaft, der sie in ihrer Kontrapunktik kompliziert, aber spannend macht.

Zum Glück hat SAP hier vorgesorgt. Eine entscheidende Komponente zur Kollisionsentdeckung ist der Cross System Object Lock (CSOL).

In Kürze: CSOL ist in sämtlichen(!) Editoren und Pflegetransaktionen mit Transportanschluss eingenistet: Bei jeder Änderung, die in einen Transport aufgezeichnet wird, wird ein Sperr-Eintrag im Solution Manager abgelegt, der erst mit dem finalen Release- oder Zyklus-Go-Live wieder entfernt wird. Ich verweise auf den schönen Blog von Dolores Correa.

Und diese CSOL-Einträge sind nicht nur für die Downgrade-Protection  wichtig, sondern sie steuern auch die spannendste Funktionalität einer solchen komplexen Landschaft: Den Retrofit.

Retrofit

Retrofit Grundlagen

Die Aufgabenstellung: Eine Fehlerkorrektur wird in der Wartungslandschaft durchgeführt und geht live mit dem nächsten Minor Release. Falls dasselbe Objekt eine Änderung in der Projektlandschaft erfährt, die später mit dem nächsten Major Release live gehen wird, so wird, wenn wir nichts tun, diese Projekt-Änderung die Korrektur aus der Wartung überschreiben: Der bereits behobene Fehler taucht somit wieder auf.

Um diesen Rückschritt zu verhindern, muss die Fehlerkorrektur aus der Wartungslandschaft in die Projektlandschaft retrofittet werden, es müssen also beide Änderungen, die Korrektur der Wartung und die Neuerung im Projekt, für die Projektlandschaft zusammengemischt werden. Für den Retrofit gibt es nur eine Richtung: Von der Wartung zum Projekt. Auch zum Retrofit gibt es einen sehr schönen Blog von Dolores.

Retrofit Praxis

Kaum wird eine Korrektur an einem Objekt im Maintenance Entwicklungssystem gespeichert, das ebenso in der Projektlandschaft auf dessen Weg zum Produktivsystem ist, poppt ein Dialog hoch, der den Schlüssel des Objekts und den kollidierenden Transport und dessen Change Document Nummer (Work Item) anzeigt. Der oder die Entwicklerin ist ab jetzt vorgewarnt. Noch kann sie die Warnung einfach wegklicken.

Die Entwickler oder Customizer der Maintenance sind verantwortlich, dass der Korrektur-Transport in die Projektlandschaft retrofittet wird.

Der ideale Zeitpunkt für den Retrofit ist, wenn der Normal Change den Status „TestedOK“ erhält, denn ab dann ist die Korrektur stabil weil getestet; es wird jetzt der „echte“ Transport freigegeben und per Batch-Job in das Maintenance-QA-System importiert. Natürlich wird dabei überprüft, dass sich keine ungetestete Änderung nachträglich eingeschlichen hat.

Der Transport steht jetzt in der Import Queue des Produktivsystems, der Change selbst wartet ebenso auf den nächsten Wartungs-Go-Live. Jetzt müssen Wartung und Projekt miteinander reden, wie beide kollidierenden Änderungen in der Projektlandschaft zusammengefasst werden können. Die Initiative hierzu muss vom Wartungs-Team ergriffen werden. Keine Produktivsetzung der Korrektur ohne vorherigen Retrofit in die Projektlandschaft!

Technisch werden die Team-Mitglieder vom ChaRM Retrofit Werkzeug unterstützt, der die einzelnen zu retrofittenden Wartungs-Transporte kategorisiert und das Abmischen der zwei Landschaften stark erleichtert. Leider ist das Retrofit-Werkzeug immer noch eine SAP Gui Anwendung (beim Start aus der CRM WebUI flackert es etwas), aber eine sehr mächtige.

Zu retrofittende Transporte werden mit einem Ampel-Farbschema kategorisiert.

„Grüne“ Transporte

Dies sind Transporte oder Objekte, die keinerlei Kollision erfahren und auf keiner Ausnahmeliste sind.

Zu empfehlen ist die FB Standalone Extension Retrofit Automation: Einfach einrichten und sich freuen. Ein Batch Report nimmt sich aller konfliktfreien Wartungsänderungen an und verteilt sie in die Projektlandschaft. Am geräuschlosesten ist die Variante per Transport of Copies (ToC). Kleiner Hinweis, wenn man das ToC-Szenario der Focused Build Standalone Extension „Retrofit Automation“ verwendet: Org-Transporte, die mit dem Report RHMOVE30 erzeugt wurden, sperren sich gegen Kopien von ToCs und müssen auf die Ausnahmeliste gesetzt werden.

„Gelbe“ Transporte

Falls eine Änderung in der Wartungslandschaft mit einer in der Projektlandschaft kollidiert, wird das Objekt als „gelb“ markiert. Das heisst, man muss die Änderungen abmischen. Dieses Zusammenführen wird hier aber von den Retrofit Werkzeugen  (SCWB, BC-Set) unterstützt.

Hier besteht die Kunst, den passenden Zieltransport in der Projektlandschaft auszuwählen.

Ist der Projekttransport, der die Kollision enthält, noch änderbar, ist er ganz klar die richtige Auswahl

Ansonsten muss man einen neuen Transport in der Projektlandschaft anlegen und dafür sorgen, dass dieser mit dem bereits freigegebenen Projekttransport gemeinsam live geht.

Entweder man nimmt das FB Work Item wieder in Entwicklung, oder, falls dies nicht mehr möglich ist, man legt eine FB Defect Correction zum selben Release an. FB und das darunterliegende TMS werden dafür sorgen, dass alles korrekt und in der richtigen Reihenfolge live gehen wird.

In all diesen Fällen benötigt übrigens der retrofittenden User eine änderbare Transport-Aufgabe, sonst erscheint der Zieltransport in der Transport-Auswahl des Retrofit-Werkzeugs nicht.

„Rote“ Transporte

Ist ein Eintrag als „rot“ markiert, dann kann man ihn nur noch „manuell“ retrofitten. Dies bedeutet, dass man in der Projektlandschaft die Änderung der Wartung mit der passenden Pflege-Transaktion wiederholt.

Hier sind zwei Fälle zu unterscheiden.

Der Eintrag der Wartungslandschaft kollidiert mit einer Änderung in der Projektlandschaft, ist aber nicht „gelb“ sondern „rot“, weil keines der zwei Tools das Abmischen unterstützt, er also nur manuell eingepflegt werden kann: So gelten hier die gleichen Regeln für die Auswahl des passenden Zieltransports wie für die „gelben“ Einträge, nämlich auf das gemeinsame Go-Live zu achten.

Ist der Eintrag hingegen „rot“ weil er auf der Ausnahmeliste steht (implizit wie z.B. SAP Hinweise, Modifikationen, usw. oder per Customizing in der Ausnahmeliste), aber es existiert keine Kollision mit einer Projektänderung, dann muss man für diese manuelle Pflege in der Projektlandschaft ein normales Work Item verwenden. Damit gehen „rote“ Änderungen ein zweites Mal live, aber so ist es nun mal. Am besten man akzeptiert es, vermeidet manuelles Eingreifen und denkt nicht weiter darüber nach, denn: Es funktioniert.

Retrofit Strategie

Die Erfahrung zeigt, dass die Retrofit-Warteschlange schneller wächst, als es einem lieb ist, wenn man diese goldene Regel missachtet. Da das Retrofit-Werkzeug die Abhängigkeit der Transporte voneinander errechnet, kann sehr schnell ein alter, nicht retrofitteter Transport den Retrofit von einem ganzen Batzen neuerer Transporte blockieren.

Es sei empfohlen, ein Retrofit Team (oder wenigstens einen Retrofit-Master) zu etablieren, das folgende Merkmale hat: Verantwortung, Initiative, Expertenwissen, Governance, regelmässiges Monitoring der Retrofit-Queue, Koordination zwischen Maintenance und Projekt.

Denn bei Cutover (Go-Live) des Projektes muss die Retrofit-Queue leer sein. Übrigens, die Cutover-Checks von Focused Build überprüfen genau dies.

Kommunikation ist Trumpf! Praktischerweise etabliert das Retrofit-Team oder der Retrofit-Master, in Absprache mit der Projektleitung, fachspezifische Retrofit-Jour Fixes, bei denen Maintenance und Projekt die Kollisionen besprechen und in einem Projekt-Transport zusammenfassen.

Regel für die fachspezifischen Teams: Einen von meinen und einen von deinen.