Automic stellt von Haus aus keinen Release-Prozess zur Verfügung. Automic Objekte können nur mit Hilfe eines Transportkoffers oder XML Import/Export in andere Automic Umgebungen transportiert werden.
Diese Art des Transports macht es sehr schwierig, Änderungen im Fehlerfall rückgängig zu machen, da keine Abhängigkeiten zwischen den transportierten Automic-Objekten bestehen. Dies ist umso problematischer, als praktisch alle Automic-Implementierungen aus mehr als einem Objekt bestehen. Daher ist es wichtig, dass immer alle transportierten Objekte zusammen verteilt und im Notfall auch wieder zurückgespielt werden können.
Automic bietet seit Jahren Action Packs an, die sehr gut geeignet sind, Automic-Erweiterungen zu installieren und zu verwalten. Für die Verteilung von Automic Erweiterungen sind sie nicht optimal, da Automic über keinen leistungsfähigen Release-Prozess verfügt.
Aus diesem Grund haben wir die b4A Packages entwickelt. Diese sind speziell für das Ausrollen von Automic-Implementierungen entwickelt worden, bieten aber auch andere interessante Features.
In meinem ersten Blog habe ich diese Features beschrieben und in meinem zweiten Blog Praxisbeispiele unserer Kunden.
In diesem Blog konzentriere ich mich nur auf den Release-Prozess und seine Möglichkeiten zur Integration in einen DevOps-Prozess.
Ein Release-Prozess umfasst alle Schritte der Entwicklung von Automic-Automatisierungen, beginnend mit der Definition, über das Testen bis hin zur Installation in der Produktion. Ein elementares Merkmal ist dabei die konsequente Versionierung und Dokumentation aller Änderungen. Nur so können alle Änderungen zuverlässig nachvollzogen werden. Insbesondere im Fehlerfall ist es essenziell, einen Überblick über alle Änderungen inklusive einer Beschreibung zur Hand zu haben, um den Fehler schnell beheben zu können.
Ein best4Automic getriebener Release-Prozess funktioniert nur mit b4A Packages. Der erste Schritt ist die Einführung und Migration von neuen und bestehenden Automatisierungen in b4A Packages. Alle Vorteile habe ich in meinen früheren Blogs beschrieben.
Änderungen und Erweiterungen sind unterschiedlich komplex und reichen von minimalen Änderungen über die Einführung neuer Funktionen bis hin zu inkompatiblen Änderungen. Es hat sich bewährt, die Änderung durch eine dreistellige Versionsnummer (x.y.z) abzubilden. Für Bugfixes wird die erste Ziffer ‚z‘ hochgezählt, für die Einführung neuer Funktionalität, oft auch Minor Updates genannt, wird die zweite Ziffer ‚y‘ hochgezählt. Für Major Updates, die große, möglicherweise inkompatible Änderungen beinhalten, wird die dritte Ziffer ‚x‘ hochgezählt.
best4Automic vergibt die Versionsnummer automatisch. Alles was beim Erstellen eines neuen Releases angegeben werden muss ist, ob es sich um ein Fix, Minor oder Major Release handelt.
Diese Kategorisierung bestimmt auch den Zeitpunkt, wann Änderungen in die Produktion eingespielt werden können, da bei einem Major Release ein höheres Risiko für unangenehme Nebeneffekte besteht als bei einem Bugfix. Ein Grund mehr, die Art der Änderungen bereits an der Versionsnummer erkennen zu können.
Nachdem die b4A Packages erstellt wurden, müssen sie auf die verschiedenen Automic Umgebungen verteilt werden. Auch hier bietet best4Automic ein Modul, das die b4A Packages auf entfernten Automic Umgebungen installiert.
Alle in der Testumgebung gefundenen Fehler werden in der Entwicklungsumgebung behoben und daraus eine neue Version des b4A Package erstellt, wobei die dritte Stelle der Versionsnummer automatisch erhöht wird.
Flüchtigkeitsfehler können durch die automatischen Tests des b4A Package erkannt werden, sie ersetzen natürlich nicht die ausführlichen manuellen Tests in einer Testumgebung.
Nachdem das Paket erfolgreich getestet wurde, kann es in der Produktivumgebung installiert werden. Auch dies wird von best4Automic übernommen.
Tritt nun ein Fehler auf, kann dieser nur behoben werden, um die Produktion am Laufen zu halten. Die eigentliche Korrektur erfolgt immer in der Entwicklungsumgebung und das Deployment erst, nachdem das korrigierte Package in der Testumgebung getestet wurde. Die erhöhte Versionsnummer und die Beschreibung des Fixes ermöglichen es später, alle Änderungen nachzuvollziehen und sogar den Fix zurück zu rollen, falls dieser die Situation ‚verschlimmert‘ hat.
Tritt der Fehler in der Produktion erst nach einigen Wochen auf, kann es sein, dass in der Zwischenzeit bereits an der Weiterentwicklung der Pakete in der Entwicklungsumgebung gearbeitet wurde. Dieser Stand kann dann nicht mehr für die Behebung des Fehlers verwendet werden, da sonst unfertige Implementierungen indirekt in die Produktion gelangen würden.
Um dies zu verhindern, sichert der b4A Package Manager den aktuellen Entwicklungsstand und überschreibt ihn mit der Version, die in der Produktion verwendet wird. Nun verwenden Entwicklung und Produktion den gleichen Stand und es kann mit der Behebung des Problems in der Entwicklungsumgebung begonnen werden. Nachdem das Problem in der Entwicklungsumgebung behoben wurde, wird das b4A Package mit der entsprechenden neuen Versionsnummer neu gebaut.
Diese neue Version wird nun in der Testumgebung und später in der Produktionsumgebung installiert.
Nachdem das Problem behoben ist, wird die gesicherte Version wieder eingespielt und ggf. muss das Problem auch dort behoben werden. Die Entwicklung wird jedoch genau dort fortgesetzt, wo sie vor der Fehlerbehebung unterbrochen werden musste.
Das folgende Diagramm veranschaulicht diesen Prozess.
Alle oben beschriebenen Schritte können auch über die best4Automic REST Schnittstelle angesteuert werden. Somit ist es problemlos möglich, diese Schritte automatisiert durch eine CI/CD Lösung ausführen zu lassen und somit einen im Unternehmen etablierten DevOps Prozess zu integrieren.
Kay Koll berät und unterstützt seit über 30 Jahren Geschäftskunden in unterschiedlichen Rollen. In den letzten 15 Jahren lag sein Schwerpunkt auf der Automatisierung von Geschäftsprozessen.
Als Pre-Sales Engineer und Solution Architect war er beim Hersteller der Automic Automation Lösung für den technischen Teil des Verkaufsprozesses verantwortlich.
In seiner Rolle als Business Technology Manager bei best-blu consulting with energy sieht er sich als Trusted Adviser für Automic und Camunda Driven Automation.