Gastbeitrag: Stopp! Ein Upgrade wird durchgeführt

Dieser Artikel ist nicht von mir, sondern von Roney Uba. Roney ist ein befreundeter Automic Experte aus Brasilien. Viel Spaß mit dem Gastbeitrag zu Versions-Upgrades.

Abhängig von der Größe Ihres Automation Engine Environments, warten bei einem Upgrade der Version unterschiedliche Herausforderungen. Das kann beispielsweise der Zeitrahmen sein, das Testen oder parallel laufende Veränderungen. Deshalb zeige ich Ihnen, wie Sie die Guideline-Prinzipien von Philipp dafür benutzen können.

Aber bevor wir damit loslegen, will ich eine kurze Geschichte erzählen.

Ich schreibe diesen Artikel auf meiner Reise zu neuen Herausforderungen. Für mich gibt es keine bessere Zeit zum Schreiben, als während eines 10-stündigen Flugs über den Atlantik.

Wirklich! Ich bin dafür sogar bei der Sitzauswahl strategisch vorgegangen und habe einen Platz in einem Dreierblock gewählt, in dem schon ein Sitz reserviert war, in der Hoffnung, dass keiner den übrigen Platz will und ich noch ein paar Zentimeter mehr zur Verfügung habe.

Bei dieser Reise habe ich mein altes Leben und meine Heimat hinter mir gelassen, um mich an einem neuen Ort darauf zu konzentrieren, die Welt zu verändern – und zwar durch Automatisierung.

Aber kehren wir zum Thema zurück. Wenn Sie ein Update durchführen, fangen Sie normalerweise mit der Umgebung Development an, machen dann Acceptance und schließlich Production. Das gilt für normale Umgebungen mit drei Ebenen.

Aber wenn Ihr Development schon auf der neuen Version läuft, können die Objekte nicht mehr mit DB unload/DB load transportiert werden. Das funktioniert nämlich nur von einer alten Version auf eine neuere. So können an Ihrem System keine Änderungen mehr durchgeführt werden, bis die anderen Umgebungen ebenfalls aktualisiert wurden, alles getestet ist und Production eingerichtet wurde.

Um das zu lösen, verwenden wir Philipps Guideline-Prinzipien.

WHAT
Gute Koordination der Upgradeprozesse mit den fortlaufenden Objektänderungen, die für Prozessoptimierungen oder Geschäftsvorgänge benötigt werden, ohne lange Aussetzzeiten und manuelle Änderungen an Acceptance oder Production.

HOW
Die Arbeitsumgebung von 3 Tiers auf 5 Tiers aufstocken. Acceptance und Development bestehen jetzt aus zwei Umgebungen, nämlich einer alten und einer neuen Version des Systems.
Um Synchronisierungsprobleme und manuelle Änderungen zu vermeiden, gibt es nur einen Eingangspunkt für Änderungen: die Umgebung Old Development.

DESIGN
Wenn nur in Old Development Änderungen eingeführt werden, stellt man sicher, dass unload und load von transportierten Objekten sowohl auf der alten, als auch der neuen Version funktioniert.
Um alle Umgebungen zu synchronisieren, werden alle Transportrouten parallel durchgeführt, wie in der Grafik unten dargestellt.
Abhängig davon, wie Sie Parameter und Werte aus Development auf andere Umgebungen übertragen, müssen Sie die neuen Regeln entsprechend anpassen. Wenn Sie zum Beispiel DB Change benutzen, um Servenamen von Development nach Acceptance zu übersetzen, müssen Sie es kopieren und entsprechend des neuen Ziels anpassen.

Zusätzlich müssen Sie unter Umständen einige Probleme in der Job-Konfiguration beheben, da nicht alle Versionen kompatibel sind, zum Beispiel unterscheidet sich manchmal die Anzahl an Parametern in einer Skriptfunktion. Das kann auch während des Transports auf die Umgebung mit der neuen Version geschehen.

Daneben können Sie schon Änderungen an der Job-Konfiguration planen, um den Prozess des Upgrades auszunutzen. Fügen Sie beispielsweise Queues hinzu, die auf dem alten System noch nicht genutzt werden. Wenn Sie das machen, denken Sie an die Anforderungen aus WHAT und planen Sie, wie es durchgeführt werden muss.

Noch ein letzter Hinweis: Änderungen, die vor dem Ende des Upgrades an Production (altes System) gehen, müssen auch auf dem alten System von Acceptance getestet werden.