5. CI/CD 06.06.2024¶

5.1. Einleitung¶

Die kontinuierliche Integration und kontinuierliche Bereitstellung bzw. Auslieferung (Continuous Integration and Continuous Delivery/Deployment, kurz CI/CD) sind wesentliche Bestandteile im Verlauf der Softwareentwicklung. Sie optimieren und beschleunigen den Softwareentwicklungs-Lifecycle unter der Verwendung von sogenannten Pipelines. Dieser Bericht beleuchtet die Prinzipien, Vorteile und Herausforderungen von CI/CD sowie deren Implementierung und Best Practices.

Die Grafik betont die fortlaufende und zyklische Natur des CI/CD-Prozesses, bei dem jeder Schritt nahtlos in den nächsten übergeht, um eine effiziente und zuverlässige Softwarebereitstellung zu gewährleisten.

5.2. Prinzipien von CI/CD¶

5.2.1. Continuous Integration (CI)¶

Continuous Integration beschreibt den Prozess, bei dem neuer Code regelmäßig und sicher in die bestehende Codebasis integriert wird. Nachdem Änderungen im Repository vorgenommen wurden, wird eine Kette von Ereignissen in Gang gesetzt. Ein typischer erster Schritt in dieser Kette ist die Erstellung der neuesten Version des Quellcodes. Wenn der Build erfolgreich ist, werden automatische Tests durchgeführt. Das Team wird über den Status dieses Prozesses informiert und erhält einen Bericht, der Details wie Build-Nummer, Defekte und Anzahl der Tests enthält. Continuous Integration (CI) hilft sicherzustellen, dass die Software vollständig integriert ist.

Typischerweise umfasst die CI-Pipeline die folgenden Aufgaben:

Änderungen im Quellcode-Repository erkennen (neue Commits erscheinen)
Analyse der Qualität des Quellcodes
Projekt-Build
Durchführung aller Unit-Tests
Durchführung aller Integrationstests
Erzeugung von deploybaren Artefakten
Statusbericht erstellen

Wenn einer der obigen Schritte fehlschlägt, erhält das Team eine Meldung darüber. Der Defekt kann anschließend behoben und comitted werden, wodurch die Pipeline erneut getriggert wird.

5.2.2. Continuous Delivery (CD)¶

Mithilfe von Continuous Delivery, das in Verbindung mit CI funktioniert, wird die Bereitstellung von Infrastruktur und Anwendungen automatisiert. Sobald der Code im Rahmen des CI-Prozesses getestet und gebuildet wurde, stellt CD sicher, dass er mit allem verpackt ist, was er benötigt, um jederzeit in jede Umgebung bereitgestellt zu werden. CD kann alles abdecken, von der Bereitstellung der Infrastruktur bis hin zur Bereitstellung der Anwendung in der Test- oder Produktionsumgebung. Mit CD wird die Software so erstellt, dass sie jederzeit in die Produktion deployt werden kann. Continuous Delivery ist eine Notwendigkeit für das darauffolgende automatische Deployment.

5.2.3. Continuous Deployment (CD)¶

Continuous Deployment (CD) baut auf den Prinzipien der Continuous Integration auf und geht noch einen Schritt weiter. Hierbei wird der Code automatisch nach dem erfolgreichen Durchlaufen aller Tests in eine Produktionsumgebung überführt. Dies automatisiert den Bereitstellungsprozess und beschleunigt die Einführung neuer Funktionen für Benutzer.

Wie bei Continuous Integration werden auch beim Continuous Deployment Codeänderungen in einem gemeinsamen Repository zusammengeführt, Tests und Builds automatisiert und diese Schritte in kleinen Abschnitten durchgeführt. Ohne eine solide kontinuierliche Integration ist es äußerst schwierig, die kontinuierliche Bereitstellung erfolgreich umzusetzen.

5.3. CI/CD Fundamentals¶

Es gibt acht grundlegende Elemente von CI/CD, die eine maximale Effizienz für Ihren Entwicklungszyklus sicherstellen. Sie erstrecken sich über Entwicklung und Bereitstellung.

Single Source Repository: Ein Repository, das alle erforderlichen Dateien und Skripte zum Erstellen von Builds enthält, ist entscheidend.

Häufige check-ins in den Main Branch: Häufige Integration des Codes in den Hauptzweig.

Automatisierte Builds: Die CI-Prozesse sollten den Code automatisch in eine verwendbare Anwendung verpacken und kompilieren können.

Selbsttestende Builds: Testskripte sollten sicherstellen, dass failed Tests zu einem fehlgeschlagenen Build führt.

Häufige Iterationen: Kleine, häufige Iterationen durchführen, anstatt große Änderungen vorzunehmen. Auf diese Weise können Änderungen bei Bedarf leicht rückgängig gemacht werden.

Stabile Testumgebungen: Der Code sollte in einer geklonten Version der Produktionsumgebung getestet werden.

Maximale Sichtbarkeit: Maximale Sichtbarkeit bedeutet, dass jeder den Fortschritt überwachen und potenzielle Bedenken identifizieren kann.

Vorhersehbare Deployments jederzeit: Die CI/CD-Test- und Verifizierungsprozesse sollten streng und zuverlässig sein und dem Team das Vertrauen geben, Updates jederzeit bereitzustellen.

5.4. Vorteile von CI/CD¶

Zufriedenere Nutzer und Kunden: Weniger Fehler gelangen in die Produktion, was zu einer besseren Nutzererfahrung und höherer Kundenzufriedenheit führt.
Beschleunigte Time-to-Value: Durch die Möglichkeit, jederzeit zu deployen, können Produkte und neue Funktionen schneller auf den Markt gebracht werden, was zu niedrigeren Entwicklungskosten und einem Wettbewerbsvorteil führt.
Weniger Probleme zu lösen: Häufigeres Testen in kleineren Chargen und früher im Entwicklungszyklus reduziert die Anzahl von nötigen Bugfixes.
Zuverlässigere Einhaltung von Terminen: Die Beseitigung von Bereitstellungsengpässen und die Vorhersagbarkeit von Deploys erhöhen die Zuverlässigkeit bei der Einhaltung von Terminen.
Freisetzung von Entwicklungszeit: Die Automatisierung von Prozessen gibt Entwicklern mehr Zeit für Implementierungstätigkeiten und steigert die Produktivität erheblich.
Weniger Kontextwechsel: Echtzeit-Feedback erleichtert Entwicklern die Konzentration auf eine Aufgabe.
Schnellere Wiederherstellung: CI/CD erleichtert die Fehlerbehebung und Wiederherstellung.

5.5. Stages und Jobs¶

Die verschiedenen Phasen einer CI/CD Pipeline, die nacheinander durchlaufen werden, werden Stages genannt. Jede Stage enthält eine oder mehrere Jobs, die spezifische Aufgaben ausführen. Häufige Stages sind:

Build: Kompiliert den Code und erstellt ausführbare Dateien oder Artefakte. Beispiele: make, npm install.
Test: Führt automatisierte Tests aus, um die Qualität des Codes sicherzustellen. Beispiele: Unit-Tests, Integrationstests, End-to-End-Tests.
Deploy: Stellt die erstellten Artefakte auf einer Staging- oder Produktionsumgebung bereit. Beispiel: Hochladen der Artefakte auf einen Server oder in die Cloud.

Innerhalb einer Stage gibt es die Möglichkeit Jobs auszuführen. Jobs sind untergeordnete Aufgaben einer Stage und können parallel ausgeführt werden. Ein Beispiel hierfür wäre, wenn man in einer Test-Stage unterschiedliche Jobs für Unit-Tests, Integration-Tests und End-to-end-Tests.

5.6. Implementierung von CI/CD¶

Pipelines werden in GitLab mithilfe von .gitlab-ci.yml-Files implementiert. Sobald diese in die Codebase integriert werden, erkennt GitLab diese als Konfigurationsdatei für CI/CD. Bei der Erstellung einer GitLab-CI/CD-Pipeline kann man wie folgt vorgehen (Am Beispiel: Pipeline zum builden und testen der Backend-Anwendung):

5.6.1. Festlegung des Basis-Image der Pipeline und Integration des Postgres-Services als Nebencontainter¶

image: mcr.microsoft.com/dotnet/sdk:8.0

services:
  - postgres:latest

5.6.2. Festlegung der Variablen, die in der Pipeline verwendet werden¶

variables:
  POSTGRES_DB: 'todo'
  POSTGRES_USER: 'postgres'
  POSTGRES_PASSWORD: '${POSTGRES_PASSWORD}'
  ASPNETCORE_ENVIRONMENT: 'Production'
  TODO_DB_CONNECTION_STRING: 'Server=postgres;Database=${POSTGRES_DB};Username=${POSTGRES_USER};Password=${POSTGRES_PASSWORD};'
  SOURCE_CODE_PATH: 'todo-app/packages/todo-api'

5.6.3. Jobs (Beispiel: start_db)¶

start_db:
  stage: todo_api
  tags:
    - dotnet
  script:
    - 'apt-get update && apt-get install -y postgresql-client'
    - 'until pg_isready -h postgres -U "$POSTGRES_USER"; do sleep 5; done'

Neben dem Stage-Namen, wird dem Job einen Tag hinzugefügt welcher den zu verwendenden Runner definiert. Im Script-Teil des Jobs wird der eigentliche auszuführende Code implementiert. In diesem Fall wird zuerst der PostgreSQL-Client installiert und anschließend darauf gewartet bis der PostgreSQL-Dienst bereit ist.

5.7. Fazit¶

CI/CD sind wesentliche Praktiken der Softwareentwicklung, die die Effizienz und Qualität der Softwarebereitstellung erheblich verbessern. Trotz des Aufwands, der mit der Erstellung einer für ein Projekt maßgeschneiderten CI/CD-Pipeline einhergeht, bietet diese meist viele verschieden Vorteile. Mühselige wiederkehrende Handlungen im Prozess der Softwareentwicklung, die ohne eine automatisierte Pipeline von Hand gemacht werden müssen und dadurch potenziell fehleranfällig sind, fallen durch eine CI/CD-Pipeline weg. Zusammenfassend kann man sagen, dass eine CI/CD-Pipeline in vielen Fällen den Aufwand der Erstellung gerecht wird und die Vorteile meist überwiegen.