Theorie trifft Realität – Die Demo-App auf der Continuous Delivery Pipeline

In einem ersten Blog haben wir das Konzept der Continuous Delivery Pipeline aufgezeigt. Nun gilt es, die Theorie in die Praxis umzusetzen.

Anhand der Demo-Applikation erklären wir die konkreten Bausteine der Continuous Delivery Pipeline. Die Pipeline wird fassbar. Jeder erkennt typische Tools, welche ihm bei der tagtäglichen Arbeit sicherlich schon begegnet sind.

Theorie und Praxis. Das ist eine Geschichte die uns schon lange begleitet. Gerade heute Morgen habe ich gelesen, dass ein Stadtwald in Schutzzonen aufgeteilt werden soll, die nur wenige hundert Meter gross sind. Das heisst, dass ich innerhalb von wenigen hundert Metern in einem zusammenhängenden Wald z.B. Pilze sammeln darf oder nicht. Ich bin gespannt auf die Umsetzung in der Praxis! Die Umsetzung in die Praxis ist auch bei der Continuous Delivery Pipeline das Thema. Wir haben das Konzept beschrieben und auch audiovisuell festgehalten. Den Beweis, dass das Konzept auch funktioniert, haben wir anhand einer Demo-Applikation aus der Praxis demonstriert.

Die Demo-App ist eine Mini-Version einer Applikation, die in der Praxis mehrere hundert Transaktionen pro Sekunde bewältigt und Millionen von Datensätzen verwaltet. Bei der Installation und bei Updates kam es stets zu unvorhergesehenen Ausfällen oder Anomalien im Verhalten. Manuell eingefügte Konfigurationsparameter oder nicht identische Umgebungen waren die Ursache. Dass diese kostenintensiven Ausfälle nicht sein müssen, haben wir anhand der Demo-App bewiesen. Der gesamte Prozesse wurde vollständig automatisiert.

Blog_Bild_Pipeline der Demo-App_01.png
Abbildung 1: Die Pipeline der Demo-App wurde auf der Continuous Delivery Pipeline realisiert. Sie orchestriert den automatisierten Prozess um Anpassungen im Code in die Produktion zu bringen.

Wir haben eine Continuous Delivery Pipeline aufgebaut und darauf die Demo-App als Pipeline implementiert. Die Pipeline kann man anfassen und schauen, wie sie funktioniert. Im Webinar konnten wir nur Slides zeigen, darum war eine Live Demo nicht möglich. Aber wir kommen gerne vorbei und zeigen Ihnen die Pipeline in Aktion.

Version Control: Um die Pipeline bzw. den Installationsprozess anzustossen, checken wir im Versionierungs-System eine Änderung an unserer Codebasis ein. Wir verwenden mehrere Git-Repositories um Applikationscode und Konfigurationen zu verwalten.

Continuous Integration: Der CI-Server prüft jede Minute, ob sich etwas geändert hat. Bei Änderungen kompiliert er den Code und UnitTests und Integrationstests werden ausgeführt. Bei Erfolg wird ein Artefakt (WAR) erzeugt und im Artefakt Repository abgelegt. Danach meldet er der Pipeline, dass die Artefakte bereit sind und die Installation starten kann. Als CI-Server haben wir Jetbrains Teamcity verwendet, als Integrationstest-Framework JBoss Arquillian.

Configuration Management: Die Pipeline provisioniert als nächstes die für die Demo-App benötigte Infrastruktur. Als  Konfigurations-Management Tool verwenden wir Chef, Docker und Hashicorp’s Vagrant.

Artefact Repository: Damit die Applikation und die Infrastruktur auf die Gegebenheiten der Umgebung abgestimmt ist, holt sich die Pipeline diese Informationen aus dem Konfiguration Management (z.B. IP-Adressen, Credentials, Ports). Die zu installierenden Artefakte (Applikation und Datenbank) werden aus dem Artefakt Repository geholt. Das Repository ist ein Read-Only Speicher. Einmal im Repository gespeichert, kann ein Artefakt nicht mehr verändert werden (Audit). Als Produkt für das Repository haben wir Sonatype Nexus verwendet.

Database Lifecycle Management: Via Database Lifecycle Management (DLM) erstellen wir die benötigten Datenbankstrukturen und füllen diese mit Nutzdaten. Mit DLM ist es möglich, Best Practices bei der Erstellung von Datenbankmanipulationen Firmenweit durchzusetzen, ohne manuellen Review. Es wird massgeblich dieselbe Infrastruktur verwendet, wie für die Applikation nötig ist. Durch die Automatisierung werden die Fehlerquellen minimiert und die Geschwindigkeit derjenigen der agilen Softwareentwicklung angeglichen. Wir haben hier Flyway eingesetzt, eine Open-Source-Lösung.

Der via Konfigurations-Management installierte Applikationsserver (Oracle Weblogic) wird nun auf die Installation der Applikation vorbereitet. Es wird eine eigene Domäne erstellt und konfiguriert (Datenbankverbindung, Sicherheit).

Simulationen: Um die Integrationstests wiederholbar ausführen zu können, werden Simulationen welche die Umsysteme abstrahieren gestartet. Wiederholbar heisst, dass die Tests nicht aufgrund von nicht verfügbaren Umsystemen oder geänderten Testdaten fehlschlagen. Die Simulationen wurden mit CA Service Virtualisation erstellt.

Das Web Archive (WAR), welches die Applikation enthält wird als nächstes in die vorbereitete Weblogic-Domäne installiert. Die im WAR enthaltenen Konfigurationsdateien werden mit den Parametern aus dem Konfiguration Management bestückt. Diese Aufgabe erledigt der Bus.

Automatische Tests: Die funktionalen Anforderungen werden durch automatisierte System-Integrationstests überprüft. Die automatisierten Tests wurden mit CA DevTest (Siehe auch Blog: CPO SV 9.0) implementiert. Werden die Tests erfolgreich ausgeführt, wird die Installation als erfolgreich im Bus gespeichert. Schlagen Tests fehl, gibt es die Möglichkeit, auf den letzten Release-Stand zurückzufahren, welcher die Tests erfolgreich bestanden hat. Das nennt man automatisches Rollback.

Continuous Delivery Pipeline: Die Continuous Delivery Pipeline haben wir mit CA Release Automation realisiert. Ein Hauptaspekt für diese Entscheidung ist die Tatsache, dass Hunderte vordefinierte Adapter für Tools wie JIRA, Chef, Jenkins oder HP Quality Center mitgeliefert werden. Eine Integration in bestehende Umgebungen ist so einfach und schnell möglich. Die abstrakte Modellierung von Umgebungen und Prozessen bietet eine grosse Flexibilität um eine Applikation auf einer Maschine oder auf mehreren Cluster-Umgebungen zu installieren – ohne Anpassungen und auf Knopfdruck. Mit der Continuous Deliviery Pipeline ist es möglich, mit der aktuellen Infrastruktur zu starten ohne tiefgreifende Veränderungen. Basierend auf dieser Plattform, kann der Gesamtprozess unter Einbezug aller beteiligten Personen optimiert werden ins digitale Zeitalter.