Die bisher in Automic Release Automation (ARA) umgesetzte Release- und Deployment-Automatisierung wurde vollständig ersetzt und erweitert. Dazu wurde in Cloudomation Engine ein Prozess aufgesetzt, der folgende Schritte umfasst:

1. Operators steigen in Cloudomation ein, um ein Deployment zu starten. Dazu wählen Sie aus folgenden Optionen:
   1. Welche Komponente(n) sollen deployed werden: 10+ Komponenten stehen zur Auswahl
   2. Wohin sollen die Komponenten deployed werden: 30+verschiedene Kundenumgebungen stehen zur Auswahl.
   3. Welche Version soll deployed werden.
      
      Operators können Komponenten in mehrere Kundensysteme zugleich deployen. Jede Kundenumgebung ist leicht unterschiedlich und besteht aus zumindest 5 separaten Servern, auf die eine Vielzahl unterschiedlicher Komponenten deployed werden. Die Automatisierung berücksichtigt alle Varianten der Kundensysteme und löst vorhandene Abhängigkeiten der einzelnen Schritte korrekt auf.
      
      
2. Informationen werden direkt aus Zielumgebungen ausgelesen: welche Komponenten in welchen Versionen sind aktuell installiert.
3. Es wird überprüft, ob es sich beim anstehenden Deployment um eine Patch-Update oder ein Major-Version-Update handelt.
   1. Das Zielsystem wird zuerst auf die nächste Major-Version upgedatet. Danach werden Updates für jede Patch-Version einzeln angewendet. Beispiel: Update von 3.0.2 auf 3.5.2: zuerst wird ein Update auf Version 3.5.0 durchgeführt, und dann separate Updates von 3.5.0 auf 3.5.1 und dann auf 3.5.2.
   2. Deployment-Abläufe werden für jedes Zielsystem separat ermittelt und durchgeführt. Wenn Operators mehrere Kundensysteme gleichzeitig updaten, wird für jedes Kundensystem berücksichtigt, welche Updates durchgeführt werden müssen, um zur Zielversion zu gelangen.
4. Installationsdateien werden aus dem Nexus Repository heruntergeladen. Hierbei werden kundenspezifische Pfade beachtet, da sowohl für verschiedene Betriebssysteme als auch für manche Kunden weitere spezielle Installationsdateien erstellt und in unterschiedlichen Pfaden in Nexus abgelegt werden.
5. Das Zielsystem wird gesperrt: Citrix Login für Kundensysteme wird für die Zeit des Updates gesperrt. Angemeldete User werden aus dem System abgemeldet.
6. Konfigurationsdateien werden angepasst. Dies geschieht in Abhängigkeit davon, welche Komponenten upgedatet werden und umfasst unterschiedliche Änderungen, wie z.B. das Eintragen geänderter Ports, sodass Komponenten auch nach einem Update korrekt miteinander kommunizieren können.
7. Je nach Komponente wird der jeweilige Update-Prozess durchgeführt: Tomcat Caches werden geleert, .war files werden in Zielsysteme kopiert und in Tomcat deployed.
   1. Für jede Komponente existieren Varianten des Installationsprozesses für Windows und Linux.
   2. Patch- und Major-Version-Updates unterliegen unterschiedlichen Checks. So wird bei Patch-Installationen nicht immer jeder Webservice aktualisiert, bei Major-Versions-Updates jedoch schon.
8. Es wird überprüft, ob bestimmte Komponenten erreichbar sind, die für die Datenbankmigration benötigt werden.
9. Datenbank-Migrations-Schritte werden aufgerufen. Dazu werden Oracle-SQL-Files in die Oracle Datenbank geladen und ausgeführt. Je nach Komponente werden mehrere Oracle-SQL files geladen und durchgeführt.
10. Komponenten werden reinitialisiert (durchgestartet). Dadurch werden Konfigurationsdateien neu geschrieben.
11. Ein weiteres Recompile-Oracle-SQL-File wird geladen und durchgeführt.
12. Je nach Komponente wird die Datenbank neu gestartet oder nicht neu gestartet.
13. Oracle Forms wird neu gestartet.
14. JSON-Files mit Zugangsdaten werden neu geschrieben.
15. Je nach Komponente werden Reports kopiert.
16. Zugriffsrechte für File-Systeme werden gesetzt.
17. Alle Services werden gestartet.
18. Alle Webservices werden gepollt und es wird gewartet, bis alle verfügbar sind.
19. Wenn der Gesamtprozess ohne Fehler abgeschlossen werden konnte, wird das Kundensystem wieder entsperrt und Citrix Login ist wieder möglich.
20. Nach erfolgreichem Update sowie im Fehlerfall werden Benachrichtigungen an Operators geschickt.
21. In den Benachrichtigungen können Operators wählen, ob der Fehler ignoriert, der Prozess abgebrochen oder ein Prozessschritt noch einmal durchgeführt werden soll.

Der Gesamtprozess wird in Cloudomation Engine durchgeführt und überwacht.

Eine Reihe weiterer Anwendungsfälle wurden ebenfalls umgesetzt, die teilweise vom übergreifenden Deployment-Prozess aufgerufen werden:

• Kundensysteme sperren und entsperren (Citrix Login sperren und User ausloggen, sowie wieder entsperren).
• Services in Kundensystemen stoppen und starten, sowohl in Windows- wie auch Linux-Umgebungen.
• Oracle SQL Plus ausführen, worüber Operators Oracle Skripte in Kundensystemen ausführen können. Operators können interaktiv angeben, wie Fehler behandelt werden sollen.
• Versions-Report erstellen: Die aktuelle Version von Komponenten in Kundensystemen wird ausgelesen und ein Report erstellt. Dazu wird die Version für unterschiedliche Komponenten entweder aus der Oracle Datenbank oder aus Binaries ausgelesen.