Transport-Wirrwarr: So reduzieren Sie mit „Transporten von Kopien“ die Gesamtzahl Ihrer Transporte drastisch

In größeren Projekten mit unterschiedlichen Go-Live Terminen entstehen oft viele Transporte. Vor jedem Go-Live muss sichergestellt werden, dass diese Transporte in der „richtigen“ Reihenfolge transportiert werden. Fehlt darüber hinaus noch eine Testumgebung im Entwicklungssystem, so dass valide Entwicklertests erst im Qualitätssicherungssystem erfolgen können, erhöht sich die Anzahl der benötigten Transporte nochmals erheblich.

Dann heißt es: Die Reihenfolge der Transporte im Auge behalten und unbedingt „Überholer“ vermeiden. Denn wenn nicht in der richtigen Reihenfolge transportiert wird, besteht die Gefahr, dass Objekte mit bereits überarbeiteten Ständen transportiert werden, so dass Ihre Systeme letztlich unterschiedliche Stände aufweisen.  Je mehr Transporte beobachtet werden müssen, und je mehr unterschiedliche Projekte bzw. Projektteams diese Aufträge anlegen, desto komplizierter wird das Management der Transporte.

Hier kommen die sogenannten „Transporte von Kopien“ ins Spiel, die uns helfen, die Gesamtzahl der Transporte zu reduzieren.

Grundidee: Transporte von Kopien werden nicht durch die gesamte Systemlandschaft transportiert. Während Workbench- und Customizing-Aufträge in einer Dreisystemlandschaft einer konkreten Transportschiene folgen, wird ein Transport von Kopien nur in das Qualitätssicherungssystem transportiert.

Daher können Transporte von Kopien genutzt werden, um den (jeweils) aktuellen Entwicklungsstand in das Qualitätssicherungssystem zu transportieren. Dort kann dieser Stand ausführlich getestet werden. Anschließend werden Anpassungen, die aus den Tests hervorgehen, wieder dem „alten“ Workbench- / Customizingauftrag zugeordnet, welcher sich ja weiterhin im Status „änderbar“ befindet.

D.h. im Idealfall wird für das Projekt nur ein Customizing und ein Workbenchauftrag benötigt.

 

Weniger Transporte durch den Einsatz von Transporten von Kopien

Welches Potenzial das Arbeiten mit Transporten von Kopien hat, zeigt das folgende Beispiel:

Wir nehmen an, dass in unserem kleinen Projekt drei Testrunden notwendig sind, bevor unsere Änderungen produktiv gesetzt werden. Im Fall A arbeiten wir in der normalen Transportschiene. Im Fall B mit Transporten von Kopien.

Fall A verwendet insgesamt 3 Workbench- und 3 Customizingaufträge. Für jede Testrunde wird je ein Workbench- und Customizingauftrag benötigt. Hieraus ergeben sich folgende Schritte:

• Initiales Setup und initiale Entwicklung auf Workbench- und Customizingauftrag 1
• Transport von Workbench- und Customizingauftrag 1 in das Q-System
• Erste Testrunde
• Korrekturen auf Workbench- und Customizingauftrag 2
• Transport von Workbench- und Customizingauftrag 2 in das Q-System
• Zweite Testrunde
• Korrekturen auf Workbench- und Customizingauftrag 3
• Transport von Workbench- und Customizingauftrag 3 in das Q-System
• Finaler Test
• Transport von Workbench- und Customizingauftrag 1, 2 und 3 in das P-System

Fall B benötigt einen Workbench- und einen Customizingauftrag. Die Änderungen aus den Testrunden werden über Transporte von Kopien abgebildet. Hieraus ergeben sich folgende Schritte:

• Initiales Setup und initiale Entwicklung auf Workbench- und Customizingauftrag 1
• Transport von Kopien in das Q-System
• Erste Testrunde
• Korrekturen auf Workbench- und Customizingauftrag 1
• Transport von Kopien in das Q-System
• Zweite Testrunde
• Korrekturen auf Workbench- und Customizingauftrag 1
• Transport von Kopien in das Q-System
• Finale Test
• Transport von Workbench- und Customizingauftrag 1 in das P-System

In unserem Beispiel reduziert sich die Anzahl der importieren Transporte im Produktivsystem um 66%. Natürlich haben wir hier nur ein kleines und sehr einfaches Beispiel verwendet. Allerdings gibt der Prozentwert einen Eindruck in welche Richtung sich die Anzahl der Transporte durch den Einsatz von Transporte von Kopien entwickeln kann.

Das System, die Anforderungen und die Ausgangssituation sind in jedem Unternehmen unterschiedlich, so dass das Arbeiten mit Transporten von Kopien auch zu unterschiedlichen Einsparpotentialen führt. Festzuhalten bleibt: Die Anzahl an benötigten Workbench- / Customizingaufträgen wird durch den Einsatz von Transporten von Kopien dramatisch sinken. Somit reduziert sich der Aufwand für das Managen der Transporte.

 

Objektsperren bleiben bei Transporten von Kopien erhalten

Ein weiterer Vorteil der Nutzung von Tansporten von Kopien ist der Erhalt der Sperren von Repository-Objekten im Entwicklungssystem. Wird ein solches Objekt im Entwicklungssystem angepasst, so wird es in einem bestimmten Workbenchauftrag (hier: Auftrag 1) gesperrt.

Wird dieser Transport nun freigegeben und in das Qualitätssicherungssystem geschoben, wird die Objektsperre aufgehoben. Das Objekt kann im Entwicklungssystem bei erneuter bzw. weiterer Anpassung jetzt einem neuen Auftrag (bspw. Auftrag 2) zugeordnet werden – z.B. im Rahmen eines anderen Projekts von einem anderen Entwickler.

Auftrag 1 enthält in unserem Beispiel also einen älteren Stand des betrachteten Objekts. Jetzt muss das zweite Projekt allerdings vor dem ersten Projekt live gehen. Somit wird mit Auftrag 2 nun zunächst die aktuelle Version des betrachteten Objekts in das Produktivsystem transportiert. Beim Go-Live von Projekt 1 besteht nun die Gefahr, dass mit Auftrag 1 eine alte Version unseres Objekts ins Produktivsystem transportiert wird. Ergebnis: Wir haben einen „Überholer“ und unterschiedliche Systemstände. Aus diesem Grund muss die Transportreihenfolge unbedingt eingehalten werden.

Transporte von Kopien erleichtern das Monitoring dieser Reihenfolge, da der ursprüngliche Workbenchauftrag im Idealfall erst beim Go-Live transportiert wird. Unser Objekt bleibt daher die ganze Zeit über gesperrt. Muss das gesperrte Objekt auch im Rahmen eines anderen Projekts verändert werden, bemerkt der Entwickler die Sperre umgehend und muss sich mit dem anderen Team abstimmen.