Projekte<\/h3>\n\n\n\n
Die FB Methodik knapp zusammengefasst<\/a>:<\/p>\n\n\n\n Umfangreiche \u00dcberpr\u00fcfungen<\/a> stellen sicher, dass zu jedem Status der WPs und WIs die passenden Dokumentationen vorhanden sind.<\/p>\n\n\n\n Ein umfangreiches Dashboard<\/a> Angebot begleitet die Steuerung des Ganzen. Was kann da schon schief gehen, m\u00f6chte ich augenzwinkernd und arbeitslos geworden hinzuf\u00fcgen.<\/p>\n\n\n\n W\u00e4hrenddessen reagiert das Wartungs-Team auf St\u00f6rungsmeldungen (Incidents) mit den notwendigen Fehlerkorrekturen und realisiert eventuell kleine \u00c4nderungsw\u00fcnsche aus dem Fachbereich, die mit jedem Minor Release oder Zyklus-Go-Live zum Beispiel alle zwei Wochen produktiv gesetzt werden.<\/p>\n\n\n\n Doch nun fragt man sich irgendwann: Ja, aber was passiert, wenn beide Teams, Projekt und Wartung, dasselbe Objekt gleichzeitig \u00e4ndern? Genau diese m\u00f6gliche Kollision ist der Knackpunkt einer dualen Landschaft, der sie in ihrer Kontrapunktik<\/a> kompliziert, aber spannend macht.<\/p>\n\n\n\n Zum Gl\u00fcck hat SAP hier vorgesorgt. Eine entscheidende Komponente zur Kollisionsentdeckung ist der Cross System Object Lock (CSOL)<\/a>.<\/p>\n\n\n\n In K\u00fcrze: CSOL ist in s\u00e4mtlichen(!) Editoren und Pflegetransaktionen mit Transportanschluss eingenistet: Bei jeder \u00c4nderung, 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\u00f6nen Blog von Dolores Correa<\/a>.<\/p>\n\n\n\n Und diese CSOL-Eintr\u00e4ge sind nicht nur f\u00fcr die Downgrade-Protection<\/a> wichtig, sondern sie steuern auch die spannendste Funktionalit\u00e4t einer solchen komplexen Landschaft: Den Retrofit<\/a>.<\/p>\n\n\n\n Die Aufgabenstellung: Eine Fehlerkorrektur wird in der Wartungslandschaft durchgef\u00fchrt und geht live mit dem n\u00e4chsten Minor Release. Falls dasselbe Objekt eine \u00c4nderung in der Projektlandschaft erf\u00e4hrt, die sp\u00e4ter mit dem n\u00e4chsten Major Release live gehen wird, so wird, wenn wir nichts tun, diese Projekt-\u00c4nderung die Korrektur aus der Wartung \u00fcberschreiben: Der bereits behobene Fehler taucht somit wieder auf.<\/p>\n\n\n\n Um diesen R\u00fcckschritt zu verhindern, muss die Fehlerkorrektur aus der Wartungslandschaft in die Projektlandschaft retrofittet<\/em> werden, es m\u00fcssen also beide \u00c4nderungen, die Korrektur der Wartung und die Neuerung im Projekt, f\u00fcr die Projektlandschaft zusammengemischt werden. F\u00fcr den Retrofit gibt es nur eine Richtung: Von der Wartung zum Projekt. Auch zum Retrofit gibt es einen sehr sch\u00f6nen Blog von Dolores<\/a>.<\/p>\n\n\n\n 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\u00fcssel 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.<\/p>\n\n\n\n Die Entwickler oder Customizer der Maintenance sind verantwortlich, dass der Korrektur-Transport in die Projektlandschaft retrofittet wird.<\/p>\n\n\n\n Der ideale Zeitpunkt f\u00fcr den Retrofit ist, wenn der Normal Change den Status \u201eTestedOK\u201c erh\u00e4lt, denn ab dann ist die Korrektur stabil weil getestet; es wird jetzt der \u201eechte\u201c Transport freigegeben und per Batch-Job in das Maintenance-QA-System importiert. Nat\u00fcrlich wird dabei \u00fcberpr\u00fcft, dass sich keine ungetestete \u00c4nderung nachtr\u00e4glich eingeschlichen hat.<\/p>\n\n\n\n Der Transport steht jetzt in der Import Queue des Produktivsystems, der Change selbst wartet ebenso auf den n\u00e4chsten Wartungs-Go-Live. Jetzt m\u00fcssen Wartung und Projekt miteinander reden<\/span>, wie beide kollidierenden \u00c4nderungen in der Projektlandschaft zusammengefasst werden k\u00f6nnen. Die Initiative hierzu muss vom Wartungs-Team ergriffen werden. Keine Produktivsetzung der Korrektur ohne vorherigen Retrofit in die Projektlandschaft!<\/p>\n\n\n\n Technisch werden die Team-Mitglieder vom ChaRM Retrofit Werkzeug unterst\u00fctzt, 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\u00e4chtige.<\/p>\n\n\n\n Zu retrofittende Transporte werden mit einem Ampel-Farbschema kategorisiert.<\/p>\n\n\n\n Dies sind Transporte oder Objekte, die keinerlei Kollision erfahren und auf keiner Ausnahmeliste sind.<\/p>\n\n\n\n Zu empfehlen ist die FB Standalone Extension Retrofit Automation<\/a>: Einfach einrichten und sich freuen. Ein Batch Report nimmt sich aller konfliktfreien Wartungs\u00e4nderungen an und verteilt sie in die Projektlandschaft. Am ger\u00e4uschlosesten ist die Variante per Transport of Copies (ToC). Kleiner Hinweis, wenn man das ToC-Szenario der Focused Build Standalone Extension \u201eRetrofit Automation\u201c verwendet: Org-Transporte, die mit dem Report RHMOVE30 erzeugt wurden, sperren sich gegen Kopien von ToCs und m\u00fcssen auf die Ausnahmeliste gesetzt werden.<\/p>\n\n\n\n Falls eine \u00c4nderung in der Wartungslandschaft mit einer in der Projektlandschaft kollidiert, wird das Objekt als \u201egelb\u201c markiert. Das heisst, man muss die \u00c4nderungen abmischen. Dieses Zusammenf\u00fchren wird hier aber von den Retrofit Werkzeugen<\/a> (SCWB, BC-Set) unterst\u00fctzt.<\/p>\n\n\n\n Hier besteht die Kunst, den passenden Zieltransport in der Projektlandschaft auszuw\u00e4hlen.<\/p>\n\n\n\n Ist der Projekttransport, der die Kollision enth\u00e4lt, noch \u00e4nderbar, ist er ganz klar die richtige Auswahl<\/p>\n\n\n\n Ansonsten muss man einen neuen Transport in der Projektlandschaft anlegen und daf\u00fcr sorgen, dass dieser mit dem bereits freigegebenen Projekttransport gemeinsam live geht.<\/p>\n\n\n\n Entweder man nimmt das FB Work Item wieder in Entwicklung, oder, falls dies nicht mehr m\u00f6glich ist, man legt eine FB Defect Correction<\/a> zum selben Release an. FB und das darunterliegende TMS<\/a> werden daf\u00fcr sorgen, dass alles korrekt und in der richtigen Reihenfolge live gehen wird.<\/p>\n\n\n\n In all diesen F\u00e4llen ben\u00f6tigt \u00fcbrigens der retrofittenden User eine \u00e4nderbare Transport-Aufgabe, sonst erscheint der Zieltransport in der Transport-Auswahl des Retrofit-Werkzeugs nicht.<\/p>\n\n\n\n Ist ein Eintrag als \u201erot\u201c markiert, dann kann man ihn nur noch \u201emanuell\u201c retrofitten. Dies bedeutet, dass man in der Projektlandschaft die \u00c4nderung der Wartung mit der passenden Pflege-Transaktion wiederholt<\/span>.<\/p>\n\n\n\n Hier sind zwei F\u00e4lle zu unterscheiden.<\/p>\n\n\n\n Der Eintrag der Wartungslandschaft kollidiert mit einer \u00c4nderung in der Projektlandschaft, ist aber nicht \u201egelb\u201c sondern \u201erot\u201c, weil keines der zwei Tools das Abmischen unterst\u00fctzt, er also nur manuell eingepflegt werden kann: So gelten hier die gleichen Regeln f\u00fcr die Auswahl des passenden Zieltransports wie f\u00fcr die \u201egelben\u201c Eintr\u00e4ge, n\u00e4mlich auf das gemeinsame Go-Live zu achten.<\/p>\n\n\n\n Ist der Eintrag hingegen \u201erot\u201c 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\u00e4nderung, dann muss man f\u00fcr diese manuelle Pflege in der Projektlandschaft ein normales Work Item verwenden. Damit gehen \u201erote\u201c \u00c4nderungen ein zweites Mal live, aber so ist es nun mal. Am besten man akzeptiert es, vermeidet manuelles Eingreifen und denkt nicht weiter dar\u00fcber nach, denn: Es funktioniert<\/a>.<\/p>\n\n\n\n Die Erfahrung zeigt, dass die Retrofit-Warteschlange schneller w\u00e4chst, als es einem lieb ist, wenn man diese goldene Regel missachtet. Da das Retrofit-Werkzeug die Abh\u00e4ngigkeit der Transporte voneinander errechnet, kann sehr schnell ein alter, nicht retrofitteter Transport den Retrofit von einem ganzen Batzen neuerer Transporte blockieren.<\/p>\n\n\n\n Es sei empfohlen, ein Retrofit Team (oder wenigstens einen Retrofit-Master) zu etablieren, das folgende Merkmale hat: Verantwortung, Initiative, Expertenwissen, Governance, regelm\u00e4ssiges Monitoring der Retrofit-Queue, Koordination zwischen Maintenance und Projekt.<\/p>\n\n\n\n Denn bei Cutover (Go-Live) des Projektes muss die Retrofit-Queue leer sein. \u00dcbrigens, die Cutover-Checks von Focused Build \u00fcberpr\u00fcfen genau dies.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Regel f\u00fcr die fachspezifischen Teams: Einen von meinen und einen von deinen.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Nach so viel Theorie wollen wir jetzt beobachten, wie die Duale Landschaft in der Praxis gelebt wird.<\/p>\n","protected":false},"author":16,"featured_media":33635,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[344],"tags":[336],"class_list":["post-33616","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alm-kaffeekraenzchen-das-alm-magazin","tag-kaffeekraenzchen"],"acf":[],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/www.blue.works\/wp-content\/uploads\/2023\/09\/pexels-colleen-johansen-6528430-1-scaled.jpg","_links":{"self":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33616","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/comments?post=33616"}],"version-history":[{"count":15,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33616\/revisions"}],"predecessor-version":[{"id":45650,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33616\/revisions\/45650"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media\/33635"}],"wp:attachment":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media?parent=33616"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/categories?post=33616"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/tags?post=33616"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
![\"\"](\"https:\/\/www.blue.works\/wp-content\/uploads\/2023\/09\/image-20.png\")
Wartung<\/h3>\n\n\n\n
Die Kunst der Fuge<\/h3>\n\n\n\n
Retrofit<\/h3>\n\n\n\n
Retrofit Grundlagen<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.blue.works\/wp-content\/uploads\/2023\/09\/image-21.png\")
Retrofit Praxis<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.blue.works\/wp-content\/uploads\/2023\/09\/image-22.png\")
![\"\"](\"https:\/\/www.blue.works\/wp-content\/uploads\/2023\/09\/image-23.png\")
\u201eGr\u00fcne\u201c Transporte<\/h4>\n\n\n\n
\u201eGelbe\u201c Transporte<\/h4>\n\n\n\n
\u201eRote\u201c Transporte<\/h4>\n\n\n\n
Retrofit Strategie<\/h3>\n\n\n\n