CI / CD – deine Software kontinuierlich integrieren und deployen

Hi Leute,

wie ihr wisst arbeiten wir in der agilen Softwareentwicklung und nutzen Tools, welche die Philosophie von DevOps unterstützen. Ein zentraler Part ist das Thema CI / CD (Continuous Integration/ Continuous Deployment) und genau darüber möchte ich heute mit euch sprechen. Mein Fokus liegt auf der Bedeutung für uns und wie schwierig es ist, dieses Thema in einem Unternehmen einzuführen.

Nach meiner Erfahrung wird die Definition von CI / CD immer wieder gänzlich unterschiedlich interpretiert, weshalb wir die Worte für uns zuerst definieren müssen.

Das Ziel von CI / CD ist aus meiner Sicht, die Geschwindigkeit zwischen dem Abschluss der Entwicklung eines Stück Softwares und der Bereitstellung der daraus resultierenden Funktionen an den Kunden zu erhöhen. Damit die Software von Punkt A, dem Rechner eins Entwicklers zu Punkt B, dem Endgerät des Kunden gelangt, muss unsere Software mehrere Schritte in der CI / CD Pipeline durchlaufen. Hierbei ist es von höchster Bedeutung, dass so viel wie möglich automatisiert und qualitätsgesichert geschieht. Wir wollen sicher gehen, dass nur Software geliefert wird, welche funktioniert und nicht für einen Ausfall der IT Systeme sorgt.

Denn stellt euch vor, ein Entwickler von Udemy liefert Software, hat aber in der Pipeline „getrickst“ und nicht ausreichend automatisiert getestet und auf einmal geht die Website von Udemy nicht mehr. Für das Unternehmen ein nicht tragbarer Zustand.

Continuous Integration

Damit wir diesen Qualitätsanspruch umsetzen können, wird die Software, welche entwickelt wird, innerhalb von CI regelmäßig und automatisiert getestet. Tools wie beispielsweise Jenkins oder Gitlab CI ermöglichen uns eine Pipeline zu realisieren und zu automatisieren. Dadurch wird die Qualität der Software erhöht, denn die Feedback-Schleife, die ein Kernprinzip von DevOps ist, nimmt an Geschwindigkeit zu. Wenn du als Entwickler deine Software in die Pipeline „gepusht“ hast, bekommst du schon nach wenigen Minuten die Rückmeldung, ob du die Qualitätsansprüche erreicht hast oder nacharbeiten musst. Dabei hat das Ergebnis immer eine gleichbleibend hohe Qualität, denn die Pipeline ist immer gleich und liefert immer ein erwartetes Ergebnis.

Die Pipeline selbst ist das Herzstück von CI. Wir haben für jeden Microservice eine eigene Pipeline, welche sich unterscheiden kann, aber zum größten Teil einem vorher definierten generischen Muster entspricht. Du kannst dir das wie ein Fließband mit vordefinierten Schritten vorstellen. Wenn du definiert hast, dass dein Paket immer 30×30 cm groß ist und du an Schritt zwei die Größe misst, dann kannst du schon frühzeitig entscheiden, ob der Schritt eins erfolgreich abgeschlossen ist, weil das Paket die entsprechenden Maße hat oder es aus dem Fließband aussortiert wird. Nach diesem Prinzip durchläuft unsere Software jedes mal diese Pipeline, die automatisch gestartet wird, wenn ein Entwickler etwas Neues zu der Software hinzufügt.

Selbstgemalte Pipeline mit den definierten Schritten

Unsere Muster-Pipeline hat folgende Schritte:

  1. Code aus dem SCM auschecken
  2. Maven Build und Unit-Tests
  3. Versionsnummer generieren und festlegen
  4. Docker build
  5. Deployment in Test Umgebung
  6. Deployment in Integration Umgebung
  7. Weitere Schritte …

Schritt 5 und 6 sind jeweils Deployments in unterschiedlichen Openshift Namespaces in denen in weiteren Schritten Tests durchgeführt werden können. Eine Pipeline ist also je nach Bedarf erweiterbar. Wir können hier auch mehrere Stages abbilden. Eine Stage ist in unserem Fall ein Abschnitt, welcher als Ergebnis eine bestimmte Qualität hat. Gerne wird das auch Quality Gate genannt. Wenn du zum Beispiel deine Pipeline in Test und Integration einteilst, dann verfolgst du in der jeweiligen Stage ein eigenes Ziel. In der Test Stage ist das Ziel, dass dein Service, welchen du gerade durch die Pipeline bringst, in sich selbst funktioniert. Also wirst du in diesem Schritt Tests durchführen, die lediglich deinen Service testen (zum Beispiel Unit- oder API-Tests).
Nach dem erfolgreichen Durchlaufen der Test-Stage steht also fest, dass dein Service funktioniert und das tut was er soll. Ist das nicht der Fall? Dann sollten die automatisierten Tests überarbeitet werden :-).

Jetzt bist du an einem Punkt, an dem dein Service vermutlich mit anderen Services kommunizieren muss. Dafür haben wir die Integrations-Stage eingeführt. Wir haben zwangsläufig eine Abhängigkeit zu Anderen (Services, Softwareentwicklern, …) und müssen daher prüfen, ob unsere Software gemeinsam lauffähig ist. Wenn die Pipeline in einen Namespace deployt hat, welcher auch andere Services enthält, können nun die Services miteinander getestet und ausprobiert werden. Ziel dabei ist, dass du am Ende dieser Phase von deinem Service behaupten kannst, dass dieser so auch in Produktion, also vom Kunden verwendet werden kann.

Continuous Delivery

Jetzt kommt DER Zwischenschritt, denn die Abkürzung CD kann auch für Continuous Delivery stehen. Als Lieferung werden hier alle Artefakte verstanden, welche für das Deployment deines Services benötigt werden. Wenn du meinen Artikel Docker Begriffe die du kennen musst gelesen hast, dann weißt du, dass Docker Images in Repositories wie zum Beispiel Artifactory abgelegt werden können. Und genau das machen wir natürlich auch mit unseren Images. Diese liegen mit Versionsnummern in dem Repository und warten darauf, in Produktion ausgerollt zu werden. Das Gute an der Pipeline ist natürlich, dass in diesem Repository per Definition nur Images liegen, welche jede vorherige Stage durchlaufen und dadurch die richtige Qualität erreicht haben.

Continuous Deployment

Wo viele bei Contiuous Delivery aufhören, fängt der eigentliche Spaß beim Continuous Deployment erst an. Eine Kette ist nur so stark wie das schwächste Glied und wenn das Deployment nicht automatisiert funktioniert, dann wird die Geschwindigkeit der Entwicklung zwar schneller, aber der Mehrwert durch neue Features für die Kunden wird nicht unmittelbar weitergegeben. Ich erlebe es bei uns immer wieder, dass viele Menschen noch Angst davor haben, dass Software automatisch ausgerollt wird. Hier ist nach meiner Erfahrung, gerade in großen Unternehmen, viel Überzeugungsarbeit zu leisten.
Mein Tipp: Du musst einfach Ergebnisse liefern und zeigen, dass es geht. Mit Ergebnissen erarbeiten wir uns Vertrauen und das ist es wert!

Der Vorteil ist, dass du in kurzen Abständen immer kleine Teile deiner Software bereitstellen und somit das Risiko klein halten kannst, denn die Änderungen sind überschaubar. Wenn du jedoch nur alle drei Monate Software einführst, dann können Änderungen dabei sein, welche dich mehrere Tage und Nächte beschäftigen. Die Auswirkungen sind auf den Testsystemen meistens anders als das in der realen Produktion der Fall ist.

Wie sind deine Erfahrungen mit CI / CD? Hast du schon eine Pipeline, welche wirklich in Produktion deployt?
Spannend ist in diesem Kontext auch das Thema Canary Deployment, mit dem ich mich jetzt mehr beschäftigen werde. Auch hier werde ich dich natürlich auf dem Laufenden halten.

Bis dahin

Kevin

Leave a Reply

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