CI/CD

Typischer Ablauf (Pipeline):

1. Du änderst die Farbe eines Buttons.
2. Du schickst den Code an GitHub/GitLab.
3. Die Pipeline springt an (Du siehst grüne Haken ✔️).
4. Test: "Klickt der Button noch?" -> ✔️.
5. Build: "Baue die App." -> ✔️.
6. Deploy: "Lade auf Webserver." -> ✔️. 5 Minuten später sieht der Kunde den neuen Button. Ohne dass du einen Finger rührst.

Praxisroutine

In der Praxis lernst du CI/CD, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Continuous Delivery vs. Deployment

Ein feiner Unterschied im "CD":

• Continuous Delivery: Die Software könnte jederzeit live gehen (der Release-Button ist bereit), aber ein Mensch muss noch klicken.
• Continuous Deployment: Alles geht vollautomatisch live. Wenn du Freitagabend Code pushst, ist er 10 Minuten später beim Kunden. (Nur für sehr mutige Firmen wie Netflix/Facebook).

2. Shift Left

CI/CD ermöglicht "Shift Left". Fehler sollen so früh wie möglich (links im Zeitstrahl) gefunden werden. Ein Fehler auf dem Entwickler-Laptop zu finden kostet 1 €. Ihn in der Pipeline zu finden kostet 10 €. Wenn der Kunde ihn findet, kostet es 1.000 € (Image-Schaden).

1. GitOps und Declarative Pipelines

Moderne CI/CD Pipelines klickt man nicht mehr in einer Weboberfläche (wie im frühen Jenkins) zusammen. Sie leben als "Pipeline as Code" (z.B. .gitlab-ci.yml, Jenkinsfile) direkt zusammen mit dem Source Code im Repo. Die Weiterentwicklung davon ist GitOps (oft mit Tools wie ArgoCD). Hier "pusht" die Pipeline das Artefakt nicht mehr brutal auf den Server. Stattdessen ändert der CI/CD-Runner nach erfolgreichem Build nur ein config-Repo (z.B. "setze image=v2"). Der Kubernetes-Server horcht auf dieses Repo und "zieht" (pullt) sich die Änderung vollautomatisch rein. Wenn jemand manuell im Cluster fummelt, überschreibt Kubernetes es sofort wieder mit dem Zustand aus Git (dem "Single Source of Truth").

2. Blue-Green Deployment & Canary Releases

Wie deployst du Facebook live, ohne dass 2 Milliarden User einen Error sehen, während der Container bootet? Man nutzt fortschrittliche Deployment-Strategien:

• Blue-Green: Aktuell läuft Version "Blau" für alle Kunden. Die Pipeline deployt eine komplett neue Version "Grün" auf parallelen Maschinen. Wenn "Grün" den Healtcheck besteht, legt der Load Balancer blitzartig den Schalter um. Alle User sind auf Grün. Kein Ausfall.
• Canary: Die Pipeline schickt zuerst nur 5% der echten User auf den neuen Container (wie ein Kanarienvogel in der Mine). Ein automatisiertes Matrix-System prüft die Error-Logs. Sinkt die Conversion-Rate oder steigen die 500er-Fehler, stoppt die Pipeline und macht sofort ein Rollback der 5%. Fliegt der Vogel weiter, rollt man auf 100% aus.

3. Ephemeral Environments

Die höchste Kunst der Automation. Wenn ein Entwickler einen Pull Request (PR) in Git erstellt, baut die Pipeline nicht nur Code. Sie deployt eine komplette, temporäre Version des gesamten Systems (inklusive Dummy-Datenbank) unter einer generierten URL (z.B. pr-42.firma.com). Der Produktmanager kann den PR sofort live im Browser testen. Sobald der PR in den Main-Branch ge-merged wird, zerstört die Pipeline dieses Wegwerf-Environment ("Ephemeral") wieder rückstandslos, um Cloud-Kosten zu sparen.