# CI/CD Concepts: Die Engine des modernen IT-Betriebs

TL;DR / Management Summary In der traditionellen IT dauerte ein Release Wochen. Mit CI/CD (Continuous Integration / Continuous Deployment) automatisieren wir den gesamten Weg vom Quellcode bis zur Live-Schaltung. Ein Senior Admin nutzt CI/CD Pipelines nicht nur für Software, sondern für die gesamte Infrastruktur (GitOps). Jede Änderung an einer Firewall-Regel (Artikel 553) oder einer Proxmox-VM (Artikel 715) fließt durch eine automatisierte Pipeline, wird getestet und erst dann in Produktion ausgerollt.

# 1. Was ist CI/CD?

Die zwei Hälften der Medaille.

# 1. Continuous Integration (CI)

Entwickler (oder Admins) schieben Code mehrmals täglich in ein Repository (Git).

• Vorgang: Das System baut die Software automatisch (Build) und führt Tests aus (Test).
• Ziel: Fehler frühzeitig finden (“Fail fast”).

# 2. Continuous Deployment / Delivery (CD)

Der geprüfte Code wird automatisch in die Zielumgebung ausgerollt (Deploy).

• Delivery: Der Code liegt bereit, der Admin drückt den Knopf für “Live”.
• Deployment: Der Code geht vollautomatisch live, sobald alle Tests grün sind.

# 2. Die Anatomie einer Pipeline

Der Weg der Arbeit.

Eine Pipeline besteht aus aufeinanderfolgenden Stufen (Stages):

1. Lint: Syntax-Prüfung (Ist das YAML valide?).
2. Test: Unit-Tests und Integration-Tests.
3. Build: Erstellen von Binaries oder Docker-Images.
4. Staging: Deployment in eine Test-Umgebung (LXC/VM in Proxmox).
5. Production: Der finale Schwenk in die Live-Umgebung.

# 3. Deep Dive: GitOps – CI/CD für Admins

Infrastruktur als Code.

In einer GitOps-Welt ist Git der “Single Point of Truth”.

• Konzept: Sie ändern nicht die VM-Eigenschaften in der Proxmox-GUI. Sie ändern die Datei vm.tf im Git.
• Pipeline:
  1. Git-Commit erkennt Änderung.
  2. CI-Runner führt terraform plan aus.
  3. Admin prüft die Änderung im Merge-Request.
  4. Merge -> terraform apply startet automatisch.

# 4. Day-2 Operations: Rollback & Sicherheit

Wenn die Pipeline brennt.

# Automatisierter Rollback

Wenn die Pipeline in der Staging-Phase Fehler meldet (z.B. HTTP 500), darf der Prozess niemals in Produktion fortgeführt werden.

• Feature: Moderne Pipelines können im Fehlerfall automatisch auf den letzten stabilen Git-Commit zurückrollen.

# 5. Troubleshooting & “War Stories”

Wenn die Automatik Amok läuft.

# Top 3 Fehlerbilder

1. Symptom: Pipeline schlägt ständig fehl ohne ersichtlichen Grund.

   • Ursache: Flaky Tests oder Ressourcen-Mangel am Runner (zu wenig RAM).
   • Lösung: Runner-Auslastung überwachen.

2. Symptom: Sensible Daten (Passwörter) landen im Git-Log.

   • Fix: Nutzen Sie CI/CD Variables (Masked) und Tools wie Vault (HashiCorp).

3. Symptom: Pipeline dauert 30 Minuten für eine kleine Änderung.

   • Fix: Nutzen Sie Caching für Pakete (apt/npm) im Runner.

# “War Story”: Der “Unendliche” Build-Loop

Ein Admin konfigurierte eine Pipeline, die am Ende des Laufs einen Zeitstempel in eine README-Datei schrieb und diese wieder ins Git pushte. Das Ereignis: Der Push der README triggerte eine neue Pipeline. Das Ergebnis: Innerhalb einer Nacht liefen 5000 Pipelines, verbrauchten alle Cloud-Credits und legten den Proxmox-Host des Runners lahm. Lehre: Vermeiden Sie “Self-Writing” Code in Pipelines. Nutzen Sie [skip ci] im Commit-Kommentar für automatisierte Commits.

# 6. Monitoring & Reporting

Pipeline-Health.

# Success Rate Dashboard

Überwachen Sie in GitLab oder Jenkins:

• Pipeline Duration.
• Fail-to-Success Ratio.
• KPI: Wie lange dauert es vom Code-Fix bis zum Live-Gang? (Lead Time).

# 7. Fazit & Empfehlung

CI/CD ist das Betriebssystem der modernen IT-Abteilung.

• Empfehlung: Starten Sie mit einfachen Pre-Commit Hooks (Linting).
• Wichtig: Trennen Sie Ihre Pipelines nach Umgebungen. Ein Fehler im “Dev”-Zweig darf niemals die “Prod”-Infrastruktur berühren.

# Anhang: Cheatsheet (Pipeline Flow)

# Referenzen

• Continuous Delivery: Reliable Software Releases (Book by Jez Humble)
• GitLab: CI/CD Guide for Beginners
• Martin Fowler: Continuous Integration