Mit CI/CD erhöhen wir die Softwarequalität und verkürzen konstant die Releasezyklen

In vorangegangenen Beiträgen haben wir unser Gildenkonzept und mit der Container, Kubernetes & Cloud-native-Gilde eine konkrete Gilde vorgestellt:

• Agile Softwareprojekte und Innovation: Gilden bei eXXcellent solutions
• Von Containern, Orchestern und Wolken

Im Wesentlichen geht es uns bei unseren Gilden darum, Wissen zwischen Projekten zu erhalten, nutzbar zu machen und damit Mehrwerte zu schaffen.

Das gilt insbesondere im Bereich CI/CD, also der kontinuierlichen Integration (Continuous Integration) und dem Ausliefern von Artefakten (Continuous Delivery). In einer kurzen Zusammenfassung, dem sogenannten Elevator Pitch, geht es uns um Folgendes::

Die Automatisierung von Bauen und Ausliefern (CI/CD), ist elementarer Bestandteil moderner Software-Projekte und hat durch DevOps stark an Bedeutung gewonnen. Wir sind zentrale Sammelstelle für Wissen und Lösungen rund um CI/CD und bieten den Projekten Tools, Blueprints, Vorlagen und Beratung. «

CI/CD - Was war das nochmal?

Agiler Entwicklungsprozess im CI/CD - ©eXXcellent solutions

Softwareprojekte werden heutzutage oft in einem agilen Entwicklungsprozess umgesetzt, dessen Vorteil eine flexible Planung ist, bei der iterativ an Problemen gearbeitet wird. CI/CD ist eine Methode, die dieses Vorgehen weiter unterstützt. Durch die Automatisierung der früher oftmals händisch durchgeführten Prozesse soll zum einen die Qualität erhöht und zum anderen aber auch der Entwicklungs- und Releasezyklus verkürzt werden.

Konkret heißt Continuous Integration (CI) also, dass alle Änderungen in einem Projekt automatisch überprüft werden sollen. Ziel ist es, so viele Aspekte wie möglich zu automatisieren - beginnend vom Bau des Projekts über die statische Analyse (Code, Security) bis hin zu diversen Tests (Unit, Integration, System, Ende zu Ende).

Das zweite Teilstück ist das Continuous Delivery (CD). Auch hier ist es das Ziel, die Entwickler einerseits durch Automatisierung zu entlasten, gleichzeitig aber auch die Fehleranfälligkeit manueller Prozesse zu umgehen. Je nach Projekt kann ein Ausliefern von Artefakten komplett anders aussehen. Vom Ausliefern auf einen Kundenserver bis zur Lieferung fertiger Container, welche nur noch gestartet werden müssen, ist alles denkbar.

Wir schreiben explizit von Artefakten, da nicht nur das entstandene Programm ein Ergebnis eines Projekts ist - auch die interne und externe Dokumentation sollte Bestandteil eines Projekts sein.

Ein Blick unter die Haube

Die Begriffe Continuous Integration und Continuous Delivery sind relativ allgemein gehalten und daher schwer greifbar. Daher wollen wir zunächst einen Blick unter die CI/CD Haube werfen, um zu sehen, in welche Bereiche sich CI/CD grob unterteilen lässt. Diese sind in der folgenden Grafik dargestellt:

Bereiche des CI/CD - ©eXXcellent solutions

1 - Build

Der Bereich Build umfasst das klassische Bauen einer Anwendung mit den bekannten und bewährten Build Tools wie Maven, Gradle oder Ant auf Backend-Seite oder npm und yarn, welche oft im Frontend eingesetzt werden.

2 - Test

Unter Tests verstehen wir nicht nur die klassischen Unit-Tests (Junit, Jest), sondern auch die Ausführung von Integrations- und End-to-End-Tests. Bei den Unit-Tests werden nur kleine isolierte Teile einer Software getestet, was auch das "mocken" von nicht benötigten Softwarekomponenten beinhaltet. Bei Integrations- und End-to-End-Tests hingegen wird das gesamte Softwareprodukt vom Beginn (z.B. Frontend, Rest-Schicht) bis zum Ende (z.B. Datenbank, ausgangsseitige Schnittstellen) getestet. Auch die regelmäßige Ausführung von Load- oder Stresstests, welche die Funktion der Anwendung unter Last prüfen sollen, gehören dazu.

3 - Static Analysis

Ein wichtiger Punkt hinsichtlich Wartbarkeit und Code-Qualität ist die Verwendung von Tools zur statischen Codeanalyse (z.B. Sonar). Diese Tools prüfen anhand fest definierter Regelsets, ob der Code den jeweiligen Ansprüchen des Projekts genügt. Durch die Aktivierung von individuell definierbaren Quality Gates ist es mithilfe von entsprechendem Tooling möglich, den kompletten Build-Prozess zu "failen", sobald die festgelegten Quality Gates nicht erreicht werden. Auch ein direktes Feedback in der IDE ist heute durch Verwendung entsprechender Plugins möglich.

4 - Deploy

Während die vorab genannten Punkte eher der Kategorie Continuous Integration zugeordnet werden können, geht es beim Thema Deployment darum, die Anwendung in eine reale Umgebung zu integrieren. Dabei kann es sich sowohl um eine Testumgebung bei einem Dienstleister als auch um ein Integrations-, Wartungs- oder Produktivsystem beim Kunden handeln. Auch die Art der auszuliefernden Artefakte kann von einzelnen Dateien über Jars oder Ears bis hin zu fertigen Docker Images variieren.

5 - Post Processing

Das Thema Post Processing beinhaltet alle Artefakte und Prozesse, die nicht unmittelbar Teil der ausgelieferten Software, aber dennoch wichtiger Bestandteil im Softwareentwicklungs- und Wartungsprozess sind. Allen voran ist hier das Thema Dokumentation im Rahmen des "docs as code" Prinzips zu nennen.

Gab es das nicht schon immer?

Einzeln für sich genommen sind Dinge wie Build-, Test- oder auch Qualtitätssicherungsprozesse nichts Neues und schon seit vielen Jahren in der Softwareentwicklung etabliert. Neu ist hingegen, diese einzelnen Punkte in einen strukturierten, aufeinander aufbauenden Workflow zu bringen und so weit wie möglich zu automatisieren. Außerdem sollten diese Prozesse idealerweise nicht mehr lokal auf den Rechnern der Entwickler stattfinden, sondern auf einer Projekt-einheitlichen Remote-Umgebung, auf der die Integrations- und Deployment Prozesse automatisiert, nach einheitlichen Regeln und mit gemeinsamen Triggern ausgeführt werden. Und genau das verstehen wir unter CI/CD. Damit diese Remote-Prozesse nicht "from scratch" aufgesetzt werden müssen, bieten viele Plattformen heutzutage eine eigene CI/CD-Toolchain. Wir verwenden im Unternehmen die GitLab CI Tools. Hier spielt der Begriff Pipeline eine wichtige Rolle.

Pipelines

Unter einer Pipeline verstehen wir ein Element, welches die einzelnen Schritte eines Continuous-Integration- und Continuous-Deployment-Prozesses zusammenfasst, um diese auf einem meist remote laufenden Prozess auszuführen. Eine Pipeline besteht aus:

• Jobs, die definieren, was zu tun ist (z.B. Code compilieren oder testen) und
• Stages, welche die Jobs in eine Reihenfolge bringen und festlegen, wann diese auszuführen sind. Dabei kann eine Stage mehrere Jobs parallel ausführen.

Eine Pipeline wird in GitLab CI in einer einzelnen Datei pro Repository mit dem Namen gitlab-ci.yaml definiert. Diese wird dann bei jedem definierten Trigger (z.B. einem Push in den "Master Branch"), analysiert, um alle notwendigen Stages zu triggern. Eine GitLab CI Pipeline kann beispielsweise folgendermaßen aussehen:

Beispiel einer GitLab CI Pipeline - ©eXXcellent solutions

Ausgewählte Arbeitsergebnisse

Documentation as Code

Auch wir wissen, dass das Dokumentieren von Prozessen nicht unbedingt das Lieblingsthema vieler Entwickler ist. Trotzdem lohnt sich Dokumentation auf lange Sicht eigentlich immer. Ein großes Problem beim Schreiben von Dokumentationen ist, dass die Dokumentation oft nicht als Teil des Entwicklungsprozesses gesehen wird. Das erschwert nicht nur den Reviewprozess, es ist oft auch eine Hürde für das Erweitern oder Aktualisieren von Dokumentationen.

Integration in den Entwicklungsprozess

Eine Dokumentation wird praktischerweise in Form von einfachen textbasierten Dateien erstellt. So sind sie mit jedem beliebigen Editor erweiterbar und lesbar. Wir nutzen hierfür AsciiDoc als leicht erlernbare Sprache, die trotzdem extrem mächtig ist. Somit ist die Hürde, die Dokumentation zu aktualisieren, für Entwickler sehr gering. Gleichzeitig gibt es extrem gute Werkzeuge, um dieses Rohformat in fast jedes Ausgabeformat zu konvertieren.

Ein weiterer Vorteil ist bei dieser Form der Dokumentation, dass in den Reviews die Unterschiede zwischen dem neuen und alten Stand sehr einfach darstellbar sind. Somit kann ein Team auch weitere Richtlinien in den Prozess integrieren. Es ist beispielsweise denkbar, dass für alle Codeanpassungen vom Reviewer erwartet wird, dass die Dokumentation aktualisiert und/oder entsprechend erweitert wird.

©fancycrave1 - pixabay.com

Anschließend werden die Dokumentationen vom textuellen Roh-Format in die entsprechenden Ausgabeformate mit entsprechendem Styling umgewandelt. Dafür setzen wir diverse Open Source Tools ein, die in einem Docker Container gebündelt werden. Das erlaubt uns ein unkompliziertes Anpassen der einzelnen Tools. Gleichzeitig ist die Nutzung für andere Teams entsprechend einfach.

So ist es beispielsweise möglich:

• Dokumentationen automatisch im PDF oder HTML Ausgabeformate und entsprechend unserem Corporate Design zu konvertieren, 
• HTML Präsentationen dank RevealJS zu erzeugen und
• die Dokumente automatisch in unser Confluence upzuloaden.

Das bedeutet, wir können sozusagen als "Quelle der Wahrheit", alle Dokumentationen innerhalb eines Projekts im Repository halten und die jeweiligen Ausgabeformate über unsere Pipeline erzeugen. Gleichzeitig haben wir eine saubere Leseansicht im internen Confluence oder als PDF für Kunden und neue Mitarbeiter im Projekt.

CD - Automatische Versionierung und Deployment auf eine Kubernetes Umgebung

Automatische Versionierung und Deployment auf eine Kubernetes Umgebung - ©eXXcellent solutions

Ein weiteres Thema, das wir angegangen sind, ist die Möglichkeit, die Versionen von Applikationen von GitLab verwalten zu lassen. In unseren Projekten beobachteten wir, dass Artefakte wie Docker Container oder Jar-Files zwar per CI Pipeline automatisch in eine Docker Registry oder in einen Nexus veröffentlicht wurden, die Version des neuen Artefakts musste jedoch vor dem Release manuell gepflegt werden (z.B. in der pom.xml).

Deshalb haben wir ein Tool entwickelt, bei dem mit Hilfe des letzten Tags die neue Version ermittelt wird. Das bedeutet, die neue Version wird in einer eigenen Stage definiert, welche im entsprechenden Projekt die Dateien automatisch anpasst und in das Repository pushed. Da wir die Version als Artefakt in der CI Pipeline speichern, kann die neue Version in den verschiedensten Stages wiederverwendet werden, zum Beispiel zum Bau des neuen Docker Containers. Bei einem neuen Docker Image in der Registry kann in der nächsten Stage dieses Image auf einem Development System deployed werden. Auch dies kann beispielsweise auf einer Kubernetes Umgebung vollständig automatisiert erfolgen. Bei Kubernetes werden die Applikationen mit Hilfe von yaml-Files beschrieben, in denen die Image Version aktualisiert werden kann und im einfachsten Fall mit Hilfe von kubectl deployed wird.

Bei einem Development System, welches immer den aktuellsten Stand der Entwicklung repräsentiert, hat man die Möglichkeit durch nächtliche Integrations- oder Perfomanztest frühzeitig Fehlfunktionen oder Performanz Probleme identifizieren zu können. Somit ist die Auslieferung eines robusten Updates sichergestellt.

Den beschriebenen Ablauf haben wir in mehrere kleine Tools, die jeweils nur eine Funktion umfassen, aufgeteilt. So kann für jedes Projekt die Funktion ausgesucht und zusammengefügt werden, die für die jeweiligen Anforderungen und Architektur des Projektes am Besten passen.

Nutzt man im Projekt den kompletten Ablauf, kann man eine Applikation releasen und auf einer Development Umgebung ausliefern und testen, ohne dass ein Entwickler auch nur ein Stückchen Configuration manuell anpassen muss. Ein Klick in der CI Pipeline genügt.

Erfahrungen & Learnings aus der Praxis

Inzwischen haben wir ca. ein Jahr Gildenarbeit hinter uns gebracht und in dieser Zeit hat sich einiges getan und auch verändert. Im Folgenden möchten wir einen kurzen Überblick über unsere wichtigsten Learnings geben.

Agilität funktioniert

Wir sind bewusst mit einem agilen Ansatz ins Rennen gegangen - das bedeutet:

• nicht alle Doings bis ins kleinste Detail auszuplanen,
• sondern leichtgewichtig zu starten,
• zu schauen, wie sich die Dinge entwickeln,
• zu sehen, was funktioniert und was funktioniert nicht,
• um daraus zu lernen und Dinge anzupassen.

Dieser Ansatz hat sich absolut bewährt. Das zeigt sich dadurch, dass wir in der noch relativ jungen Gilden-Geschichte schon einiges auf die Strecke gebracht haben und somit viele Projekte unterstützen konnten. Das wäre sicherlich nicht der Fall gewesen, wenn wir uns im ersten halben Jahr mit der Ausarbeitung der Feinkonzepte beschäftigt hätten,.

Tools als Docker Image

Um Projekte mit diversen Tools zu unterstützen, bauen wir alle prozessvereinfachenden Tools als Docker Image. Diese Images können lokal oder in der CI Umgebung in Pipelines eingebunden werden. Das reduziert erheblich den Aufwand, unsere Tools zu integrieren, da jedes Projekt die Bausteine auf gleiche Weise einbindet. Durch Docker wird gleichzeitig das Problem gelöst, die richtige Laufzeitumgebung einrichten zu müssen und das wiederum ermöglicht eine einfache Integration bestimmter Versionen im Projekt. Durch die Nutzung von Docker Containern können diese Tools prinzipiell auf allen Betriebssystemen und Umgebungen laufen.

Eine gute Dokumentation der Tools ist entscheidend

Das beste Tool hilft nicht viel, wenn es schlecht dokumentiert ist. Auch wenn die Integration von Docker Images in GitLab CI im Grunde ziemlich "straight forward" ist, ist eine exakte und möglichst vollständige Dokumentation notwendig, damit die Tools auch genutzt werden. Mithilfe unserer eigenen "exxcellent-documentation-tools" stellen wir eine vollständige Dokumentation inklusive eines getting-started-Kapitels zur Verfügung.

Die Dokumentation ist in AsciiDoc geschrieben und befindet nach dem "docs as code" Prinzip im jeweiligen Repository. Über das documentation-tool wird es automatisiert in HTML, PDF und Confluence-Beitragsform veröffentlicht. Alle Formate sind über unsere zentrale Gilden-Confluence-Seite verlinkt und einfach auffindbar.

Organisation wie ein Softwareprojekt

In unserer Gilde "CI/CD" arbeiten aktuell vier Personen mit einer Kapazität von 10%-20% als ständige Mitarbeiter, denn es hat sich gezeigt, dass ein unstrukturiertes Vorgehen und die Kommunikation auf Zuruf nur bedingt funktioniert. Stattdessen organisieren wir uns in der Gilde wie in einem kleinen (agilen) Kundenprojekt, unter anderem mit folgenden Elementen:

• Wöchentliche Meetings zu einem festen Termin (Zeit ca. 45 Minuten)
• Planung und Organisation der Doings über ein Ticketsystem (GitLab Issues)
• Regelmäßige Backlog Refinements und Umpriorisierungen
• Ca. halbjährige grobe Richtungsplanung in Miro Board
• Rolle Gildenmeister angelehnt an die Scrum-Rolle Product Owner, der sich um Struktur, Auftritt und Organisation kümmert.

Wichtig dabei: Fester Gildentag, statt immer mal wieder!

Ein weiteres wichtiges Learning: Es hat sich bewährt, bei beispielsweise 20% Gildentätigkeit einen ganzen Tag in der Woche für die Gilde zu reservieren, anstatt jeden Tag ein bisschen für die Gildenthemen zu arbeiten. Auf diese Weise fallen ständige Kontextwechsel zwischen Projekt und Gilde weg und wir können uns deutlich besser auf die jeweiligen Aufgaben konzentrieren.

Immer die Werbetrommel rühren

Obwohl die Gilde aktuell ausschließlich innerhalb eXXcellent solutions unterwegs ist, ist es keine Selbstverständlichkeit, dass immer alle Mitarbeiter:innen die Tätigkeiten und Tools der Gilde kennen. Deshalb ist es auch hier notwendig, die interne Werbetrommel zu rühren, um die Mitarbeiter:innen über neue Entwicklungen auf dem Laufenden zu halten oder bestehende Tools wieder ins Gedächtnis zu rufen. Im Einzelnen informieren wir über folgende Kanäle:

• Regelmäßige Updates über Mattermost
• Blogposts im eXXcellent solutions Confluence
• Webcasts (inkl. Recording) mit Live Demos der Tools
• Vorstellung neuer Tools in der monatlichen Architektenrunde
• Transparenz und Information über öffentlich zugängliche Protokolle in Confluence

Ein gutes Team ist wichtig

Last but not least funktioniert eine Gilde auch nur dann, wenn die Zusammensetzung und die Größe des Teams passt. Mit vier ständigen Mitgliedern haben wir eine Teamgröße, die zwar noch überschaubar ist, aber uns dennoch erlaubt, Dinge voranzutreiben und parallel an verschiedenen Themen zu arbeiten. Die Zusammensetzung und auch die Zusammenarbeit in unserem Team funktioniert sehr gut. Wir arbeiten alle am gleichen Ziel, kommunizieren regelmäßig und haben
(meistens 😉) Spaß bei der Arbeit. Die Gilde bringt Abwechslung vom Projektalltag und
bietet die Chance Neues zu lernen.

Fazit & Ausblick

Bereits in unserem ersten Gilden-Jahr hat sich gezeigt, dass das CI/CD-Thema extrem viel Potential hat. Es ist ein Thema, welches alle Projekte in unserem Haus tangiert. Die Spanne reicht dabei vom vor zehn Jahren entwickelten Legacy-Projekt mit traditionellem Build-Setup bis hin zum topaktuellen "State of the Art"-Projekt, welches komplett auf Technologien wie Docker und Kubernetes basiert.

Unser Ziel für die Zukunft ist es, sowohl für die alte als auch neue Projektwelt Ansprechpartner und Anlaufpunkt zu sein und ältere Projekte bei der Migration zu neuen Technologien zu unterstützen. Wir wollen durch selbst entwickelte Tools den CI/CD-Prozess optimieren sowie geeignete Templates und Guides mit Best Practices zur Verfügung stellen, auf die neue Projekte mit möglichst geringem Aufwand aufsetzen können. Letztendlich geht es auch darum, eine weitergehende Homogenität und Synergieeffekte zwischen den Projekten zu schaffen.

Die Gilden bei eXXcellent solutions: Gilden Portraits

• Agile Softwareprojekte und Innovation: Gilden bei eXXcellent solutions
  
  
• Von Containern, Orchestern und Wolken: Die Gilde „Container, Kubernetes & Cloud Native“ 
  
  
• eXXcellent solutions Technology Radar: Wegweiser für unseren Kundenerfolg! Die Gilde "Technology Radar & Best Practices"
  
  
• Zugriff von überall? Authentifizierung ist wichtiger denn je! Die Gilde "Authorization, Authentication, Single Sign On (SSO)"
  
  
• Lernen, um zu Lernen: Die Gilde AI, Machine Learning & Data Science

In der nächsten Folge unserer Artikelserie stellt sich die eXXcellent solutions Gilde "Technology Radar" im Portrait ausführlicher vor. Um unsere Gilden Portraits nicht zu verpassen, melden Sie sich am Besten gleich hier bei unserem Newsletter an.

Weitere Informationen:

Über die Autoren:

Wolfram Gulde ist Software Architect bei der eXXcellent solutions. Nach seinem Informatikstudium hat er schon diverse größere Projekte in Bereichen wie Postautomatisierung, Gesundheitswesen, Energiewirtschaft und Automotive mitentwickelt und als Architekt betreut. Parallel zu seiner Projekttätigkeit interessiert und engagiert er sich in den Bereichen CI/CD, DevOps, JavaScript-Frameworks und der Erstellung von "Software as a Service"-Lösungen.

Karina Schulz arbeitet als Software Engineer bei der eXXcellent solutions. Nach dem Studium der Informationssystemtechnik, hat sie in verschiedenen Projekten im IOT-Umfeld als Entwicklerin gearbeitet. Durch eine durchgehende Microservice-Struktur im Projekt konnte sie bereits viele Erfahrungen im Bereich CI/CD, Docker und Kubernetes sammeln.