{"id":33466,"date":"2023-09-01T16:47:26","date_gmt":"2023-09-01T14:47:26","guid":{"rendered":"https:\/\/www.blue.works\/?p=33466"},"modified":"2026-02-17T13:06:20","modified_gmt":"2026-02-17T12:06:20","slug":"alm-kaffeekraenzchen-v-dual-landscape-teil-2","status":"publish","type":"post","link":"https:\/\/www.blue.works\/de\/alm-kaffeekraenzchen-v-dual-landscape-teil-2\/","title":{"rendered":"ALM Kaffeekr\u00e4nzchen V – Dual Landscape Teil 2"},"content":{"rendered":"\n

Release Management<\/h2>\n\n\n\n

Der Grundgedanke des Release Managements ist, dass alle Projekte gemeinsame Test- und Go-Live Phasen sich teilen.<\/p>\n\n\n\n

Anfangs muss sich der Change oder Release Manager gegen den Projekt-Egoismus stemmen (\u201eUnser Go-Live Termin ist heilig\u201c): Keine leichte Aufgabe, da Projekte voller Budget und strategischer Bedeutung sind, und dadurch sehr m\u00e4chtig.<\/p>\n\n\n\n

Aber die Change oder Release Manager\/in hat sehr gute Argumente auf seiner Seite.<\/p>\n\n\n\n

Ist n\u00e4mlich das Produktivsystem nicht noch strategischer als das allerwichtigste Projekt?<\/p>\n\n\n\n

Ja, es ist sogar lebensnotwendig f\u00fcr das Unternehmen oder die Beh\u00f6rde. Wegen der Eigenart der ABAP Instanzen, laufende Programme mit einem Short Dump abzubrechen, wenn sich die ausf\u00fchrbare Einheit (Ladephase) zur Laufzeit ge\u00e4ndert hat, bedeutet jeder Go-Live einen Stress des Produktivsystems. Oft wird dabei eine Downtime ben\u00f6tigt. Ein gemeinsames Go-Live der Projekte wird daher das Risiko von Abbr\u00fcchen und die Kosten der Downtime minimieren.<\/p>\n\n\n\n

Gemeinsame Integrations- und Regressionstests erh\u00f6hen die Qualit\u00e4t des Releases, da dabei versteckte Seiteneffekte entdeckt werden k\u00f6nnen, denn im Produktivsystem treffen sowieso s\u00e4mtliche \u00c4nderungen aufeinander. Auch minimiert man den Testaufwand: Die Regressionstests validieren die Kernprozesse gleichzeitig f\u00fcr alle parallelen Projekte: Eine enorme Ersparnis!<\/p>\n\n\n\n

\"\"
Abbildung 2 Releases synchronisieren Meilensteine<\/figcaption><\/figure>\n\n\n\n

Der einzige Nachteil des Release Managements ist, dass die fest eingeplanten Go-Live Termine eine gewisse Flexibilit\u00e4t – Agilit\u00e4t ist das Modewort – beim Umfang der einzuf\u00fchrenden Funktionen voraussetzt: Ist die Entwicklung oder der Test einer Funktionalit\u00e4t nicht fertig, muss sie dem n\u00e4chsten Release zugeordnet werden. Dies schmerzt anfangs. Dieses moderne agile Vorgehen ben\u00f6tigt daher eine Trainings- und Eingew\u00f6hnungsphase, auch wird es anfangs viele Diskussionen geben, doch mit der Zeit setzt sich die Taktung der Einf\u00fchrungen durch.<\/p>\n\n\n\n

Gute Planung und gutes Monitoring der Projektfortschritte ist hier Trumpf!<\/p>\n\n\n\n

Major und Minor Releases<\/h3>\n\n\n\n
\"\"
Abbildung 3 Verh\u00e4ltnis von Major und Minor Releases<\/figcaption><\/figure>\n\n\n\n

Major Releases<\/h3>\n\n\n\n

Die Projekte bewegen sich im Rahmen der Major Releases<\/em>, die i.d.R. drei bis sechs Monate ben\u00f6tigen. Wenn ein Projekt eine noch l\u00e4ngere Laufzeit ben\u00f6tigt, dann w\u00e4hlt es einfach den Go-Live Termin eines passenden h\u00f6heren Releases.<\/p>\n\n\n\n

Solche Major Releases<\/em> beinhalten grosse \u00c4nderungen auch an den Kernprozessen und ben\u00f6tigen daher vollst\u00e4ndige Regressions- und Integrations-Tests.<\/p>\n\n\n\n

J\u00e4hrliche Upgrades<\/h3>\n\n\n\n

Eine empfehlenswerte Praxis ist es, vier grosse Releases pro Jahr zu planen und das zweite Quartal f\u00fcr Upgrades zu reservieren.<\/p>\n\n\n\n

Hat sich dieses Vorgehen erstmals eingeb\u00fcrgert, verliert man keine Zeit mehr mit Diskussionen, wann die IT ein Fenster f\u00fcr einen Upgrade bekommt: In der Regel nie!<\/p>\n\n\n\n

Nicht nur erh\u00e4lt man durch regelm\u00e4ssige Upgrades die neuesten Features und Fiori-Apps. Sondern man vermeidet auch den Aufwand f\u00fcr die Identifikation und Meldung bereits behobener Fehler.<\/p>\n\n\n\n

Durch die j\u00e4hrliche Regelm\u00e4ssigkeit der Upgrades wird das Delta zwischen den SAP Releases kleiner, und die durchf\u00fchrenden Teams werden routinierter und effizienter: Die Upgrades gehen viel schneller und schmerzloser \u00fcber die B\u00fchne, denn je gr\u00f6sser das Delta, um so komplexer wird das Upgrade-Projekt.<\/p>\n\n\n\n

Schliesslich wird ein j\u00e4hrlicher regelm\u00e4ssiger Upgrade die Kostenfalle vermeiden, das System f\u00fcr eine aggressive Neueinf\u00fchrung nur mit dem Einspielen vieler SAP Hinweise (Korrekturen) vorbereiten zu versuchen, um sp\u00e4ter, durch bittere Erfahrung klug geworden (da haben wir es wieder!), einsehen zu m\u00fcssen, dass ein Upgrade sich doch nicht vermeiden l\u00e4sst (habe ich z.B. bei einer Brasilien-Einf\u00fchrung so erlebt). Nat\u00fcrlich wird durch dieses naive Vorgehen das Projekt verz\u00f6gert.<\/p>\n\n\n\n

Minor Releases<\/h3>\n\n\n\n

Minor Releases<\/em> haben eine k\u00fcrzere Laufzeit. Sie b\u00fcndeln Fehlerkorrekturen und kleinere Erweiterungen; sie gehen viel \u00f6fter Live und ben\u00f6tigen nur die Regressions-Tests der Kernprozesse und die Tests der jeweiligen Erweiterung.<\/p>\n\n\n\n

In einer dualen Landschaft erfolgt die Wartung in einer eigenen Transportlandschaft, der Maintenance-Landschaft.<\/p>\n\n\n\n

Wenn man in Systemen mit aktivem FB Minor Releases zusammen mit Major Releases planen m\u00f6chte, muss man die Einschr\u00e4nkung in Betracht ziehen, dass man ohne zus\u00e4tzliches Customizing keine Request-for-Changes (RfC) verwenden kann, was f\u00fcr alle Unternehmen akzeptabel ist, die sowieso den RfC-Workflow in ein externes Ticketing-System ausgelagert haben.<\/p>\n\n\n\n

Standard ChaRM<\/h4>\n\n\n\n

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

FB Enhance Pace<\/h4>\n\n\n\n

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\u00fcr den Requirement2Deploy Prozess einsetzt. Man muss dann nicht den standard ChaRM konfigurieren, sondern kann diese schl\u00fcsselfertige L\u00f6sung verwenden, auch bewegen sich die Team-Mitglieder in der gewohnten Fiori-Umgebung.<\/p>\n\n\n\n

Nachteil ist, dass FB ENH Pace nur Continual Cycles unterst\u00fctzt, also Zyklen, die nur die Phase \u201eActive\u201c und Einzel\u00e4nderungen kennen. Damit eignet er sich eher f\u00fcr einen reinen Detect2Correct Prozess, bei dem einzelne Fehlerkorrekturen ohne potenzielle Seiteneffekte durchgef\u00fchrt werden. Denn im Falle eines Vorabimports wird der Transport endg\u00fcltig in das Produktiv-System importiert, m\u00f6gliche Inkonsistenzen k\u00f6nnen nicht wie bei den Phasen-Zyklien sp\u00e4ter durch den Zyklus-Import konsolidiert werden.<\/p>\n\n\n\n

Geb\u00fcndelte Produktiv-Importe<\/h4>\n\n\n\n

Ein regelm\u00e4ssiges 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.<\/p>\n\n\n\n

Diese Regelm\u00e4ssigkeit 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\u00e4ssigkeit.<\/p>\n\n\n\n

Sowohl Release- als auch Phasen-Zyklen unterst\u00fctzen die Qualit\u00e4t der Tests, indem sie in der Phase Test das Testsystem gegen normale \u00c4nderungen sperren.<\/p>\n\n\n\n

M\u00f6chten sie den n\u00e4chsten Teil nicht verpassen? dann k\u00f6nnen sie diesen\u00a0hier<\/a>\u00a0<\/a>nachlesen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Der Grundgedanke des Release Managements ist, dass alle Projekte gemeinsame Test- und Go-Live Phasen sich teilen.<\/p>\n","protected":false},"author":16,"featured_media":33474,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[344],"tags":[336],"class_list":["post-33466","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\/train-7751168_1920.jpg","_links":{"self":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33466","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=33466"}],"version-history":[{"count":5,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33466\/revisions"}],"predecessor-version":[{"id":45176,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33466\/revisions\/45176"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media\/33474"}],"wp:attachment":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media?parent=33466"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/categories?post=33466"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/tags?post=33466"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}