Die Transport Case-Methode für Automic-Deployments ist der Unterschied zwischen einem Release, das eine Stunde dauert, und einem Release, das in zwei Minuten erledigt ist. In Umgebungen mit Zehntausenden oder Hunderttausenden von Objekten ist das keine Annehmlichkeit – es entscheidet darüber, ob Deployments in das Wartungsfenster passen oder eben nicht. Teil 7 der 3C Release Manager for Automic Enablement Series beleuchtet den alternativen Deployment-Weg, den das Produkt bietet, welche Änderungen an der Umgebungskonfiguration nötig sind, um ihn zu nutzen, und warum er für jede Organisation entscheidend ist, die Automic in echter Enterprise-Größenordnung betreibt.
Vorherige Teile dieser Reihe
Dieser Artikel setzt die 3C Release Manager for Automic Enablement Series fort. Falls Sie die vorherigen Teile verpasst haben, können Sie hier nachlesen:
- Teil 1 – Snapshot-Funktion: Erfassung des vollständigen Zustands eines Automic-Clients als zeitgestempelte Baseline.
- Teil 2 – Diff-Funktion: Vergleich von Snapshots zur Erkennung von Objektänderungen und zur Sicherstellung von Release-Transparenz.
- Teil 3 – Umgebungen anlegen: Definition der technischen Verbindungen zu Automic-Clients, die Snapshots, Diffs und Deployments erst ermöglichen.
- Teil 4 – Kontrollierte Deployments: Transport von Objekten zwischen Clients mit automatischen Backups und definiertem Rollback-Pfad.
- Teil 5 – Add Related: Erfassung verschachtelter Workflow-Abhängigkeiten bis auf Skriptebene in einem einzigen Schritt.
- Teil 6 – Vier-Augen-Prinzip: technische Durchsetzung der Doppelfreigabe direkt im Deployment-Workflow.
Sind abhängigkeitsvollständige, kontrollierte Releases einmal etabliert, stoßen die meisten Teams als Nächstes an eine reine Durchsatzgrenze. Ausgereifte Automic-Clients enthalten Zehntausende von Objekten – manchmal Hunderttausende. In dieser Größenordnung wird die Deployment-Methode selbst zum begrenzenden Faktor.
Warum die Transport Case-Methode für Automic-Deployments bei großem Maßstab den Unterschied macht
Der Standard-Deployment-Weg in den meisten Automic-Tools ist XML-basiert: Jedes Objekt wird in XML serialisiert, übertragen und auf der Zielseite wieder importiert. Für eine Handvoll Objekte funktioniert das einwandfrei. Sobald die Objektanzahl jedoch in den Tausenderbereich geht, skaliert es schlecht. Ein Release mit 10.000 Objekten, das eine Stunde dauert, ist beim XML-Ansatz keine Seltenheit – und Releases mit 100.000+ Objekten sprengen Wartungsfenster komplett.
Das ist kein theoretisches Problem. Es ist einer der häufigsten Gründe, warum Enterprise-Automic-Teams ihre Releases in weniger, dafür größere Fenster bündeln, lange Downtimes in Kauf nehmen oder bestimmte Transporte schlicht so lange aufschieben, bis es nicht mehr anders geht. Die Transport Case-Methode setzt beim Durchsatzproblem an der Wurzel an, indem sie auf einen grundlegend schnelleren Übertragungsmechanismus umstellt.
Funktionsweise der Transport Case-Methode im 3C Release Manager
Im 3C Release Manager for Automic kann jede Umgebung so konfiguriert werden, dass sie einen von zwei Deployment-Wegen nutzt. Der Unterschied liegt in der Umgebungsdefinition. Eine Standardumgebung – zum Beispiel eine mit dem Namen AE24X0105XML, die auf Client 105 verweist – verwendet den klassischen XML-basierten Weg. Eine zweite Umgebung kann auf denselben Client verweisen, jedoch mit aktivierten Transport Case Settings konfiguriert sein, üblicherweise mit einem TC-Suffix benannt, etwa AE24X0105TC.
Die Systemparameter am Anfang der Konfiguration sind für beide nahezu identisch. Was sich ändert, ist die zusätzliche Verbindungsanforderung: Bei aktiviertem Transport Case benötigt die Umgebung zusätzlich zur JCP-Verbindung einen REST-Endpunkt, da die Transport Case-Methode über die REST-API von Automic arbeitet. Die Connections-Prüfung in der Umgebungsansicht bestätigt vor der Nutzung der Umgebung, dass beide Endpunkte erreichbar sind.
Ab diesem Punkt ist der Unterschied in der Benutzeroberfläche nicht mehr sichtbar. Snapshots aus einer Transport Case-Umgebung sehen identisch zu XML-Snapshots aus – Objekte werden weiterhin in XML-Struktur dargestellt, die Navigation bleibt gleich, und es gelten dieselben Diff- und Deployment-Workflows. Die Beschleunigung findet im Hintergrund statt, nicht in der Bedienung des Release Managers.
Wie sich das in Zahlen niederschlägt
Das nachfolgende Video zeigt zwei direkte Vergleiche aus demselben Client 105, bei denen 10.000 Objekte in Client 106 deployt werden:
- Snapshot (XML): etwas über zwei Minuten.
- Snapshot (Transport Case): etwas länger, da die XML-Strukturen weiterhin erfasst werden und zusätzlich für jedes Objekt ein Transport Case erzeugt wird.
- Deployment (XML): 4.098 Sekunden – rund 66 Minuten.
- Deployment (Transport Case): etwas mehr als zwei Minuten.
Auf der Snapshot-Seite sind beide Methoden in etwa vergleichbar. Auf der Deployment-Seite zeigt die Transport Case-Methode, woher sie ihren Namen hat: eine 30-fache Reduktion der Deployment-Zeit bei einer Last von 10.000 Objekten. Und nun rechne das auf 400.000 Objekte oder mehr hoch – ein Release-Umfang, der mit dem XML-Ansatz innerhalb eines normalen Change-Fensters schlicht nicht realistisch ist.
Was sich dadurch im Automic-Tagesbetrieb ändert
Der Wechsel auf den schnelleren Weg verändert vier Dinge, die für jeden relevant sind, der reale Release-Pläne verantwortet:
- Wartungsfenster werden wieder realistisch. Ein 60-minütiges Deployment, das auf zwei Minuten schrumpft, spart nicht nur Zeit – es entscheidet darüber, welche Releases überhaupt in das mit dem Business vereinbarte Betriebsfenster passen. Damit entfällt ein häufiger Grund, Transporte zu verschieben oder zu bündeln.
- Große Client-Migrationen werden machbar. Releases mit 100.000+ Objekten – vollständige Client-Transporte, Neuaufbau von Umgebungen, groß angelegte Konsolidierungen – verschieben sich von „theoretisch möglich" hin zu operativer Routine. Die XML-Methode skaliert nicht in diesen Größenordnungen; der REST-basierte Weg dagegen schon.
- Risikofenster schrumpfen. Jede Minute, in der ein Release läuft, ist eine Minute, in der sich der Ziel-Client in einem Übergangszustand befindet. Eine Reduzierung dieser Zeit um eine Größenordnung verkürzt unmittelbar das Risikofenster, in dem während des Transports etwas schiefgehen kann.
- Die Release-Frequenz kann steigen. Wenn Transporte zeitlich günstig sind, hören Teams auf, Änderungen für das nächste große Release-Fenster anzustauen. Kleinere, häufigere Rollouts werden möglich – genau die Richtung, in die moderne Release-Governance ohnehin weist.
Wann welche Methode verwendet werden sollte
Der XML-basierte Ansatz ist nicht obsolet. Für kleine Objektmengen, Ad-hoc-Fixes oder Umgebungen, in denen die REST-API nicht verfügbar ist, bleibt er der einfachere Standard – weniger Voraussetzungen, keine zusätzliche Endpunkt-Konfiguration. Der schnellere Weg ist die richtige Wahl, wenn die Objektmengen groß sind, wenn die Deployment-Zeit Teil der operativen Rahmenbedingungen ist oder wenn dasselbe Release wiederholt auf mehrere Ziele ausgerollt werden soll.
Ein pragmatisches Muster, das sich in der Praxis bewährt: Definiere beide Umgebungen parallel, beide verweisen auf denselben Ziel-Client, und wähle den Weg je nach Release aus. Routinemäßige Wartungsänderungen laufen über die XML-Umgebung; große Transporte und vollständige Migrationen über die Transport Case-Umgebung. Das Tool verarbeitet beide transparent.
Wo sich dies in das übergeordnete Release-Framework einfügt
Der schnellere Weg ersetzt nicht den Rest des Release-Frameworks – er ist ein Beschleuniger darunter. Snapshots erfassen weiterhin den Zustand. Diffs machen Änderungen weiterhin sichtbar. Kontrollierte Deployments schreiben weiterhin Backups und bieten Rollback. Die rekursive Erfassung verwandter Objekte löst weiterhin Abhängigkeiten auf. Die Doppelfreigabe setzt weiterhin die Genehmigung durch. Die Transport Case-Methode macht all das schnell genug, um es im Enterprise-Maßstab anwenden zu können.
Anders gesagt: Governance und Performance sind kein Trade-off mehr. Teams müssen sich nicht länger zwischen einem sauber kontrollierten Release-Prozess und einem, der innerhalb des Change-Fensters fertig wird, entscheiden – sie bekommen beides.
Wichtigste Erkenntnisse
- Die Transport Case-Methode ist ein alternativer Deployment-Weg, der die REST-API von Automic anstelle der XML-basierten Übertragung nutzt.
- Die Aktivierung erfolgt pro Umgebung: Aktiviere die Transport Case Settings in der Umgebungsdefinition und ergänze einen REST-Endpunkt zusätzlich zur JCP-Verbindung.
- In einem Benchmark mit 10.000 Objekten sank die Deployment-Zeit von rund 66 Minuten (XML) auf etwas über 2 Minuten – dieselbe Last, dasselbe Ziel, ein grundlegend schnellerer Weg.
- Die Beschleunigung ist im Enterprise-Maßstab entscheidend: Große Client-Migrationen, der vollständige Neuaufbau von Umgebungen und Transporte mit 100.000+ Objekten werden realistisch statt praxisfern.
- XML- und Transport Case-Umgebungen können parallel existieren und auf denselben Ziel-Client verweisen, sodass der passende Weg pro Release gewählt werden kann.
Für Organisationen, die Automic in großem Maßstab betreiben, ist dies eine der Funktionen, die den 3C Release Manager von einem nützlichen Werkzeug zu einer operativen Infrastruktur machen.
Möchtest du sehen, wie sich das Produkt bei deinen eigenen Automic-Lastgrößen schlägt? Vereinbare ein kostenloses Beratungsgespräch, um deine Anforderungen an die Release-Performance zu besprechen – oder erkunde den vollständigen Automic-Kurspfad an der Tricise University, um teamweit Skills für Releases im großen Maßstab aufzubauen.
