Pipelines – die Basis jeder Cloud-Architektur

Was bedeuten die Begriffe CI und CD in der Praxis? Und warum trennt man die beiden Pipelines überhaupt?

Überblick

In der Continuous Integration Pipeline geht es darum, aus Quellcode eine auslieferbare Einheit (in vielen Fällen ein Software-Container) in einer für andere zugängliche Registry zu erzeugen.

Die Continuous Deployment / Delivery Pipeline bedient sich aus der Registry und verschiebt den Container in die Cloud, testet die Software in ihrem endgültigen Umfeld und dokumentiert (im Erfolgsfall) den Prozess in einem Tool wie z. B. Atlassian Confluence.

Ob man die Software ständig live aktualisieren möchte (CDelivery) oder ob man in bestimmten Releases von Zeit zu Zeit die Produktivsysteme aktualisiert (CDeployment) ist dabei relativ unwichtig. Im ersten Fall spielt dann aber die Laufzeit der beiden Pipelines in Summe ein bedeutende Rolle.

CI-Pipeline

Die CI-Pipeline startet automatisch nach dem Commit einer Code-Änderung in den Master-Branch (z. B. GitLab, GitHub). Dabei ist es wesentlich, keine Feature-Branches zu verwenden, da ansonsten das unmittelbare Feedback der Tests für den Entwickler verloren geht!

Wesentlich sind die Testschritte, die den Code isoliert von der späteren Cloud-Umgebung untersuchen:

  1. Code-Qualität 
    z. B. mittels SonarQube
  2. Unit-Tests
    z. B. mittels JUnit
  3. Consumer-Driven-Contracts
    z. B. mittels Pact

Gerade dem letzen Schritt kommt in Microservice-Umgebungen eine hohe Bedeutung zu: hier werden die REST und MQ-Schnittstellen auf Kompatibiliät getestet. Mehr dazu finden Sie in einem weiteren Blog-Beitrag „Consumer Driven Contracts mit Pact und Java“.

Natürlich können je nach Einsatz-Zweck der erzeugten Software weitere parallele Tests erfolgen: zum Beispiel kommt beim Einsatz von OpenSource-Libraries meist noch eine OWASP-Package-Analyse zum Einsatz, die Angriffsvektoren untersucht, die durch die Importe von Fremdsoftware entstehen können.

CD-Pipeline

Da moderne Artifact-Repositories Events erzeugen können, reagiert die CD-Pipeline in vielen Fällen automatisch auf den Push eines neuen Containers in die Registry.

Im Cloud-Umfeld ist es von großer Bedeutung, dass auch abhängige Komponenten oder Infrastuktur-Bestandteile nicht manuell, sondern per Code erzeugt werden: hierzu dient der Pipeline-Schritt „Provision Resources“, der z. B. Datenbankinstanzen in AWS erzeugt oder Drittsysteme konfiguriert.

Der wesentliche Schritt in der CD-Pipeline sind die Integrations-Tests, die die Software in ihrer endgültigen Umgebung im Zusammenspiel mit den bereits vorhandenen Komponenten testet. In Container-Umgebungen laufen diese Tests nicht auf dem Build-Server (z. B. Jenkins-Environment) ab, sondern ebenfalls als Container parallel zum eigentlichen Microservice.

Unsere dringende Empfehlung ist es, die Infrastruktur-Dokumentation ebenfalls automatisiert zu erstellen. In obiger Grafik bedeutet der Schritt „Confluence Doku“, dass für einen Microservice die Endpunkte in bestimmte Wiki-Seiten eingetragen werden und auch die gültige REST-Schnittstellendefinition in Form eines Swagger.yml-Files ins Wiki hochgeladen wird.

Warum sollten CI und CD getrennt werden?

Die CI- und CD-Pipeline ist um ein vielfaches komplexer als Pipelines in herkömmlichen Application-Server-Umgebungen. Man behält eher den Überblick, wenn man den Prozess aufsplittet.

Arbeitet man mit Zulieferern zusammen, können diese die CI-Pipeline überspringen und direkt Container für die CD-Pipeline anliefern. Dies ist in Fällen hilfreich, in denen die Zulieferer Ihrer Firma keine Rechte am Quellcode eingeräumt haben.

Serverless und weitere Verfeinerungen

Manche Unternehmen benutzen neben Containern auch Serverless-Funktionen wie z. B. AWS Lambda. Auch diese durchlaufen im Prinzip die beiden oben gezeigten Pipelines – dürfen dabei aber bestimmte Schritte einfach überspringen.

Bei größeren oder verteilten Entwicklungsteams bietet es sich an, die Pipelines auch in die Team-Messenger (z. B. Slack oder Mattermost) zu integrieren, so dass Fehler schneller rückgemeldet UND gleich auch mit den Kollegen diskutiert werden können. Das vermeidet die EMail-Flut mit CC:-„an alle“ in größeren Teams.

In der CD-Phase sollten bei öffentlichen Services, die personenbezogene Daten verarbeiten, ebenfalls noch automatisierte Penetration-Tests laufen.

Auch die Pipelines selbst sollten nicht von Hand erstellt werden, sondern automatisiert (z. B. in Form von Jenkins Seed Jobs) erzeugt werden. Das ermöglicht einen Cloud-Provider-Wechsel und dient als Basis für ein Disaster-Recovery.

 

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.