Ein Gastartikel von Martin Polak.
Kommt Ihnen das bekannt vor?
Der Software-Release-Termin rückt raschen Schrittes näher, die Zahl der enthaltenen Änderungen wächst immer weiter – aber der Testfortschritt hinkt hinterher, weil die Test-Umgebungen nicht bereit sind. Und das nur, weil es so aufwendig ist, die Software dauernd auf die Testumgebungen zu verteilen (“deployen”). Weil die Entwickler aufgrund des Release-Stresses nicht greifbar sind, Operations zu viel zu tun hat und so weiter.
Dadurch passieren beim Deployment dauernd Fehler und keiner weiß so richtig, was los ist. Und dann bleibt wieder einmal viel zu wenig Zeit zum vernünftigen Testen.
Dieses Mal geht das vielleicht noch gut, aber: Wie oft noch? Schließlich wird das Problem eher größer als kleiner. Man wandert auf immer schmalerem Grat.
Und dann kommt der große Tag (häufig: die große Nacht). Die neue Version geht “live”. Schweißnasse Finger huschen spät nachts über Tastaturen, Parameter werden via Messenger herumgeschickt, lange Excel-Listen durchgeackert und mit längst kaltem Kaffee wird die Müdigkeit bekämpft. Frühmorgens ist es endlich geschafft: Die neue Version ist veröffentlicht – hoffentlich fehlerfrei.
Automatisieren!
Wie schön wäre es doch, das Ganze zu automatisieren. Die Automic Automation ist ohnehin schon lange im Haus, Agenten sind überall verteilt. Warum also ist das alles noch nicht automatisiert und gescheduled?
Ganz einfach: Es ist mit viel Aufwand verbunden. All die notwendigen Parameter wie Pfade, Passwörter, Umgebungsvariablen müssen übersichtlich, wart- und skalierbar eingepflegt werden. Das wächst einem leicht über den Kopf.
Welcher Server gehört denn nun zu welcher Umgebung? Wo liegt welche Version der Konfigurations-Dateien und welches Datenbank-Schema passt dazu?
Es sind zu viele Applikationen, Versionen, Server und noch viel mehr Pfade, Passwörter und URLs. Diese Daten müssten in hunderte verschachtelte VARAs eingepflegt werden. Wer soll da den Überblick bewahren? Puh!
Und dann fällt es auch noch in den Verantwortungsbereich ganz verschiedener Abteilungen: Entwicklung, QA/Testing und Betrieb.
Da hilft der “DevOps”-Ansatz. Development und Operations nutzen gemeinsame Prozesse, Anreize und eben Tools, um der geschilderten Probleme Herr zu werden.
Und dafür liefert CDA die Lösung: Eine übersichtliche Web-Oberfläche und die notwendigen Strukturen, um diese Parameter geordnet zu verwalten, und die Werkzeuge, um beispielsweise Genehmigungsprozesse abzubilden.
Continuous… was?
Aber wie geht’s weiter? Wie baut man nun mit CDA eine robuste “Continuous Integration”-Pipeline und wie erweitert man das zu “Continuous Delivery”? Was heißt das denn überhaupt?
Unter “Continuous Integration” versteht man, dass die entwickelten Code-Teile aller beteiligten Teams so oft wie möglich (mindestens täglich!) miteinander kombiniert (“integriert”) werden. So stellt man sicher, dass diese gut miteinander funktionieren, und bemerkt früh, wenn dies nicht der Fall ist.
Unter “Continuous Delivery” versteht man, dass darüber hinaus zu jedem Zeitpunkt das entwickelte und kompilierte Paket bereit zur Veröffentlichung ist (selbst wenn es nicht veröffentlicht wird). Wenn man diesen Softwarestand auch noch sofort veröffentlicht, spricht man von “Continuous Deployment”.
Die Zutaten
Und wie erreicht man Continuous Integration oder Continuous Delivery? Dazu braucht man folgende, teilweise zumeist ohnehin vorhandene, Zutaten:
- Ein Versionsverwaltungssystem (z.B. GitLab, GitHub etc.)
- Einen Buildserver (z.B. Jenkins)
- Ein Software-Repository (z.B. Sonatype Nexus, FTP etc.)
- Ein Testautomatisierungs-Tool (z.B. Tricentis Tosca)
- Broadcoms Continuous Delivery Automation (CDA)
Das Rezept
Wie passt das jetzt alles zusammen?
Zum Beispiel so:
- Sobald im Versionsverwaltungssystem ein Entwickler Code in einen Entwicklungszweig (“Development-Branch”) eincheckt, wird automatisch der Buildserver (z.B. über dessen REST-API) angestoßen.
- Der angestoßene Buildserver kompiliert den Code (zu einem “Paket”) und lädt das entstandene Artefakt in das Software-Repository.
- Danach startet der Buildserver über die REST-API einen Workflow in CDA. Diesem Workflow werden Versionsnummer und andere Parameter übergeben, um in CDA ein “Package” (eine Version) für die entsprechende Applikation anzulegen und darin alle benötigten Parameter zu setzen.
- Zum Abschluss startet dieser Workflow das Deployment des Pakets auf die Test-Umgebung.
- Der Deployment-Workflow lädt aus dem Software-Repository die benötigten Artefakte herunter und führt alle nötigen Schritte auf den Servern der jeweiligen Umgebung aus.
- Am Ende dieses Deployment-Workflows wird das Testautomatisierungs-Tool aufgerufen, das die Tests durchführt und die Testergebnisse an CDA zurückspielt.
- Der Entwickler (und/oder andere Stakeholder) wird per E-Mail über alle relevanten Informationen (Testergebnisse etc.) in Kenntnis gesetzt. Alternativ kann auch ein Ticket angelegt werden.
Was haben wir dadurch erreicht?
Der entwickelte Code wurde kompiliert, geordnet abgelegt und durch CDA auf einer Testumgebung installiert, wo automatisiert getestet wurde. Abschließend wurden alle Stakeholder informiert.
Nun kann auf Knopfdruck in CDA dasselbe Paket entweder auf die nächsthöhere Umgebung (z.B. Abnahme oder Produktion) installiert oder, im Falle fehlgeschlagener Tests, abgelehnt werden. Der einzige manuelle Schritt in dieser CD-Kette war der Code-Check-in in das Versionierungssystem!
Und weil dieser Prozess jetzt so oft (und schmerzfrei!) läuft, ist er auch noch gut erprobt. Wenn die Konfigurationen der produktionsnahen Umgebungen möglichst jener der Produktionsumgebung entsprechen, kann selbst bei einem Produktiv-Deployment kaum mehr etwas schiefgehen. Die Vorteile liegen auf der Hand:
- Häufiges und frühes Testen der Software, aber auch des Deployment-Prozesses
- Hoher Grad an Standardisierung und Selbstdokumentation durch die Automatisierung
- Hohe Skalierbarkeit (derselbe Workflow wird für alle Umgebungen verwendet, Teile davon evtl. sogar Applikationsübergreifend!)
- Minimale manuelle Intervention
- Voller Audit-Trail
Oder, zusammenfassend: Eine konsistent höhere Applikations-Qualität und entspanntere Mitarbeiter!
Klingt interessant?
Wenn Sie einige der beschriebenen Herausforderungen aus eigener Erfahrung kennen und mehr darüber erfahren möchten, wie Sie diese überwinden können, kontaktieren Sie mich gerne über einen der unten angeführten Kanäle!
Martin Polak
Senior Consultant
Experte für Prozessautomatisierung im Bereich Continuous Everything mit Fokus auf CDA/ARA und Testautomatisierung. In seiner Freizeit findet man ihn abwechselnd im tiefen Schnee und Unterwasser.
Sixsentix ist ein Unternehmen, das sich auf Software-Qualität und Effizienz via Automatisierung spezialisiert hat.