CI/CD in der Praxis

Einleitung

#

Continuous Integration (CI) und Continuous Deployment (CD) sind heute zentrale Bestandteile moderner Softwareentwicklung. Sie helfen uns, Software schneller, zuverlässiger und mit weniger manuellen Schritten bereitzustellen. In diesem Artikel schauen wir uns an, wie ein typischer CI/CD-Prozess in der Praxis aussieht, welche Tools wir nutzen können und welche Schritte notwendig sind, um eine Pipeline aufzubauen.

Warum CI/CD?

#

Wenn wir Software entwickeln, wollen wir sicherstellen, dass Änderungen nicht nur auf unserem Laptop funktionieren, sondern auch in Produktion stabil laufen. Genau hier setzt CI/CD an:

• CI (Continuous Integration): Alle Code-Änderungen werden regelmäßig integriert, getestet und automatisch überprüft. Fehler fallen sofort auf.
• CD (Continuous Deployment oder Delivery): Erfolgreich getestete Änderungen können automatisiert in Staging- oder Produktionsumgebungen ausgerollt werden.

Das Ziel: Kurze Feedbackzyklen und eine stabile, schnelle Auslieferung.

Typischer CI/CD-Workflow

#

Ein praxisnaher CI/CD-Prozess lässt sich in vier Hauptschritte gliedern:

1. Code Commit
   Entwickler:innen pushen ihren Code in ein zentrales Repository (z. B. GitHub, GitLab, Bitbucket).

2. Build & Test
   Der Code wird gebaut, Abhängigkeiten installiert und automatische Tests ausgeführt.

3. Staging Deployment
   Wenn die Tests erfolgreich sind, wird die Anwendung in eine Staging-Umgebung deployed. Dort können wir manuell prüfen, ob alles wie erwartet läuft.

4. Production Deployment
   Schließlich wird die Anwendung in die Produktionsumgebung ausgerollt – je nach Setup automatisch oder nach manueller Freigabe.

Visualisierung der Pipeline

#

Die folgenden Diagramme helfen uns, den Ablauf zu verstehen. Zuerst ein klassisches CI/CD-Pipeline-Schema:

flowchart TD
    A[Code Commit] --> B[Build]
    B --> C[Tests]
    C --> D[Staging Deployment]
    D --> E[Production Deployment]

Jeder Schritt ist abhängig vom vorherigen. Schlägt ein Schritt fehl, stoppt die Pipeline automatisch, um fehlerhafte Software nicht weiter zu verbreiten.

Diese sequenzielle Ausführung bringt mehrere Vorteile mit sich:

• Frühe Fehlererkennung: Probleme werden sofort erkannt, bevor sie sich auf nachgelagerte Schritte auswirken
• Ressourcenschonung: Zeitaufwändige Deployments werden nur bei erfolgreichen Tests durchgeführt
• Qualitätssicherung: Nur getesteter und validierter Code erreicht die Produktionsumgebung
• Klare Verantwortlichkeiten: Jeder Schritt hat einen definierten Zweck und Erfolgskriterien

Falls ein Schritt fehlschlägt, erhalten Entwickler:innen sofortiges Feedback mit detaillierten Logs, um das Problem schnell identifizieren und beheben zu können.

Beispiel mit GitLab CI

#

Schauen wir uns an, wie eine einfache Pipeline in GitLab aussehen könnte. In der Datei .gitlab-ci.yml definieren wir die Jobs:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - npm install
    - npm run build

test-job:
  stage: test
  script:
    - npm run test

deploy-job:
  stage: deploy
  script:
    - ./deploy.sh
  only:
    - main

Einfache Erklärung

#

• stages: Legt die Reihenfolge der Schritte fest.
• build-job: Installiert Abhängigkeiten und baut die Anwendung.
• test-job: Führt Tests aus (z.B. Unit-Tests, Linting).
• deploy-job: Rollt die Anwendung aus, sobald die Tests erfolgreich sind und der Branch main genutzt wird.

Detaillierte Erklärung der Pipeline-Konfiguration (mit Erweiterungen)

#

Diese GitLab CI-Konfiguration zeigt eine einfache, aber effektive Pipeline-Struktur. Lassen Sie uns jeden Bereich genauer betrachten:

Stages-Definition:

stages:
  - build
  - test
  - deploy

Die stages definieren die Ausführungsreihenfolge. GitLab führt alle Jobs einer Stage parallel aus, bevor zur nächsten Stage übergegangen wird.

Build-Job (im Detail):

build-job:
  stage: build
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour

Der Build-Job sollte idealerweise auch Artefakte erstellen, die in nachfolgenden Jobs verwendet werden können. Diese werden temporär gespeichert und nach einer Stunde automatisch gelöscht.

Test-Job (erweitert):

test-job:
  stage: test
  script:
    - npm run test
    - npm run lint
  coverage: '/Coverage: \d+\.\d+%/'
  artifacts:
    reports:
      junit: test-results.xml
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

Erweiterte Test-Jobs können Code-Coverage messen und Testergebnisse in GitLab visualisieren.

Deploy-Job (mit Umgebungen):

deploy-job:
  stage: deploy
  script:
    - ./deploy.sh
  environment:
    name: production
    url: https://myapp.example.com
  only:
    - main
  when: manual

Das environment-Schlüsselwort ermöglicht es, Deployments in GitLab zu verfolgen. Mit when: manual wird das Deployment erst nach manueller Bestätigung ausgeführt.

Zusätzliche nützliche Konfigurationen:

• cache: Abhängigkeiten zwischen Pipeline-Läufen zwischenspeichern
• rules: Modernere Alternative zu only/except für komplexere Bedingungen
• needs: Jobs parallel ausführen, auch über Stage-Grenzen hinweg
• variables: Umgebungsvariablen für die gesamte Pipeline definieren

Automatisierung und Feedback

#

Ein entscheidender Vorteil von CI/CD ist das schnelle Feedback. Entwickler:innen wissen innerhalb weniger Minuten, ob ihr Code funktioniert. Tools wie GitLab CI, GitHub Actions, Jenkins oder CircleCI ermöglichen uns:

• Parallele Testläufe
• Benachrichtigungen bei Fehlern
• Automatische Rollbacks bei gescheiterten Deployments

Best Practices

#

Damit CI/CD in der Praxis wirklich Mehrwert bringt, sollten wir ein paar Regeln beachten:

• Tests ernst nehmen: Eine Pipeline ist nur so gut wie die Tests, die sie ausführt.
• Schnelligkeit optimieren: Builds sollten nicht ewig dauern – kleine, modulare Jobs sind besser.
• Automatisieren, wo es Sinn macht: Wiederkehrende Aufgaben (Linting, Sicherheitsprüfungen, Container-Builds) sollten automatisiert laufen.
• Transparenz: Jeder im Team sollte den Status der Pipeline sofort erkennen können.

Fazit

#

Mit CI/CD schaffen wir es, Softwareänderungen sicher, automatisiert und in hoher Frequenz auszuliefern. Der Einstieg ist oft einfacher, als es auf den ersten Blick wirkt: ein Git-Repository, ein CI/CD-Tool und ein paar saubere Testfälle – schon können wir loslegen.

Der größte Gewinn liegt darin, dass wir Fehler früh erkennen, schneller Feedback bekommen und unsere Produktivität als Team steigern.

flowchart TD
    Dev["Entwickler:innen"] --> CI["Continuous Integration"]
    CI --> CD["Continuous Deployment"]
    CD --> Prod[Produktion]
    Prod --> Feedback["Feedback an Team"]
    Feedback --> Dev

So entsteht ein Kreislauf, durch den die Produktqualität kontinuierlich verbessert werden kann.

Wenn Sie Fragen oder Anmerkungen zum Artikel haben, kontaktieren Sie mich gerne über die unten genannten Kanäle.

Weiterführend:

• GitLab CI/CD Dokumentation
• GitHub Actions
• Jenkins