Test AutomationCI-/CD-Pipelines

Continuous Integration (CI) umfasst die Schritte vom Source-Code bis zum auslieferbaren (und getesteten) Artefakt, während Continuous Delivery (CD) die Bereitstellung des Artefakts an den Endnutzer beschreibt. 

Heutzutage greifen diese beiden Bestandteile nahtlos ineinander, so dass wir ausschließlich von CI-/CD-Pipelines sprechen. Im Grunde genommen handelt es sich hier um ein klassisches EVA-Prinzip: Aus Input-Daten (Sourcecode, Bilder, etc.) werden ausführbare Artefakte erzeugt und ausgeliefert.

Einmal eingerichtet bilden sie das Rückgrat einer Software-Entwicklung:

• Alle wiederkehrenden Aufgaben werden einmalig eingerichtet und können dann beliebig oft wiederholt werden.
• Die Auslieferung einer Software ist damit nicht mehr an das Spezialwissen einzelner Team-Mitglieder gebunden, sondern erfolgt automatisiert und dokumentiert.
• Die CI-/CD-Pipeline verbindet alle beteiligten Systeme (Code-Verwaltung, Test-Systeme, Artefakt-Repositories und Deployment).

Für die Ausführung von CI-/CD-Pipelines haben sich über die Jahre einige „Standard-Lösungen“ etabliert:

• Jenkins
• TeamCity
• Bamboo
• GitLab
• Azure

Da wir immer wieder gefragt werden, welches System wir empfehlen: Aus langjähriger Erfahrung wissen wir, dass es keine allgemeingültige Antwort gibt. Während die Pipeline in einem Tool mit Groovy geschrieben wird, verwenden andere Tools graphische Interfaces oder YAML. Abhängig vom Projekt, dem Umfeld und dem vorhandenen Know-how sollte die Entscheidung für ein passendes Tool getroffen werden. Prinzipiell ist jedes der Tools hervorragend geeignet, die Pipelines auszuführen und bietet Schnittstellen für die beteiligten Systeme zur Code-Verwaltung bis zum Deployment.

Sprechen Sie uns einfach an, wenn wir Sie bei der Auswahl eines passenden Pipeline-Tools unterstützen können!

Eine Pipeline-Definition kann je nach CI-/CD-Lösung etwas anders aussehen. Um Ihnen zu verdeutlichen, wie eine Pipeline aufgebaut sein und welche Aufgaben sie übernehmen kann, nehmen wir hier einmal das Beispiel einer deklarativen Jenkins-Pipeline. Eine solche Pipeline besteht mindestens aus drei Teilen:

• Die Spezifizierung der Maschine (agent), auf der die Pipeline oder Teile davon auszuführen sind – die Maschine kann auch variabel gesetzt werden (any)
• Die Festlegung der einzelnen Stufen (stages/stage), die durchlaufen werden sollen (z.B. Build, Test, Deploy) – diese können sequenziell oder auch parallel verlaufen
• Die Beschreibung der Schritte (steps), die in den jeweiligen Ebenen ausgeführt werden sollen – dies kann beispielsweise ein Shell-Skript sein oder ein Tool-Aufruf, um Applikationscode neu auszurollen, einen Test zu starten, oder eine andere Pipeline anzustoßen

Mit einer solchen Minimal-Pipeline können bereits viele wichtige Prozesse automatisiert werden. Zudem bieten sich hier eine Vielzahl weiterer Optionen an, um Ihre CI-/CD-Prozesse individuell zu konfigurieren und an Ihre Bedürfnisse anzupassen.

Abzugrenzen von CI-/CD-Pipelines sind Tools für das Build-Management. Diese Tools sind Spezialisten für den ersten Schritt einer jeden CI-/CD-Pipeline: Dem Erzeugen eines lauffähigen Artefakts aus Sourcecode, Bildern, Fonts oder Bibliotheken. In der Testautomatisierung nutzen wir Build-Management-Tools wie Maven oder Gradle, um Testautomatisierungslösungen zu bauen und auf dem Testsystem bereitzustellen.

Der letzte Schritt einer Pipeline ist in aller Regel das Veröffentlichen der Software bzw. das weitere Deployment in den Live-Betrieb. Umgangssprachlich werden diese Begriffe oftmals synonym verwendet, beschreiben jedoch unterschiedliche Bereiche:

• Release: Bereitstellung der Software zur weiteren Verwendung, z.B. in einem Artefakt-Repository wie Nexus
• Deploy: Ausrollen der im Release-Schritt bereitgestellten Software zum Kunden. Oftmals kommen dabei Container-Technologien wie Docker oder OpenShift zum Einsatz.

Wie oft das Deployment in die Produktiv-Umgebung erfolgt, hängt von der konkreten Projektsituation ab. In hochregulativen Bereichen gibt es oft definierte Zeitfenster für ein Update, während bei agilen Projekten durchaus kontinuierliche Aktualisierungen möglich sind.

Sprechen Sie uns an, damit wir gemeinsam die perfekte Pipeline definieren und umsetzen können!

Gern stehen wir Ihnen mit Know-how, konkreten Unterstützungsleistungen und zugehörigen Lizenz- und Supportangeboten zur Verfügung.