Pipeline (CI/CD)

GitHub Actions Beispiel:

name: CI
on: [push]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm install
      - run: npm test

Du siehst grüne Haken oder rote Kreuze direkt neben deinem Commit auf GitHub.

1. Declarative vs. Scripted

Früher (Jenkins): Man schrieb Groovy-Code (if (branch == 'master') {sh '...'}). Mächtig, aber Spaghetticode. Heute (GitHub Actions, GitLab CI): Man schreibt YAML (Deklarativ). "Ich will einen Job, der Node 16 nutzt." Der CI-Server entscheidet, wie er das macht (Docker Container starten). Das ist sicherer und leichter zu lesen, aber manchmal unflexibel (Loops sind schwer).

2. Runner & Executors

Die Pipeline läuft nicht "in der Cloud". Sie läuft auf einem Runner. Das ist ein Server (oder Container), der auf Arbeit wartet.

• Linux Runner: Standard.
• Windows/Mac Runner: Nötig für iOS/VStudio Apps.
• Docker-in-Docker (dind): Der Runner startet selbst Docker Container. Nötig, um Docker Images zu bauen inside CI. Wichtig: Ephemeral Runners (Wegwerf-Runner). Nach dem Job wird der Runner zerstört. Verhindert, dass "Müll" vom vorherigen Job (Logs, Tempfiles) den nächsten Build beeinflusst.

3. Caching Strategies

Der Flaschenhals: npm install dauert 5 Minuten. Jede Pipeline fängt bei Null an (Ephemeral). Du musst Caches nutzen! Der Runner lädt node_modules aus einem S3-Cache herunter (Checksum package-lock.json), bevor er npm install macht. Wenn sich package-lock.json nicht geändert hat, dauert npm install nur 1 Sekunde. Gute Caching-Strategie spart 50% der Build-Zeit (und damit Geld).

1. GitOps & Declarative Pull Architecture

Der klassische "Push"-Pipeline Flow besagt: Jenkins baut den Code, loggt sich über einen SSH-Key auf dem Webserver (oder Kubernetes API) ein und drückt (pusht) den Code (kubectl set image...) hart ins System. Das ist im Enterprise-Sektor ein gigantisches Security-Problem (Jenkins in einer DMZ hat de-facto Gott-Root-Admin-Keys für den Prod-Cluster). Die moderne Konter-Bewegung ist GitOps (ArgoCD / Flux). Die CI-Pipeline endet abrupt nach dem Docker-Build. Sie committet lediglich das neue Image-Tag (v1.1) deklarativ in ein Git-Konfigurations-Repository. Im Kubernetes Prod-Cluster sitzt der ArgoCD-Agent, welcher isoliert aus dem eigenen Netzwerk in Abständen "pulled". Er detektiert die Git-Änderung und zieht den Code selbstständig ab. Der Cluster aktualisiert sich von Innen heraus. Die CI/CD-Pipeline hat absolut keine Credentials für Produktionsumgebungen, was die Angriffsvektoren vernichtend minimiert.

2. Idempotency in Deployment-Scripts

Dilettantische Pipelines scheitern kläglich. Der Befehl mysql_query("CREATE TABLE user") geht im initialen Deployment durch. Im 2. Deployment (z.B. ein Typo-Fix im Backend-Code) rammt der Roboter den exakt selben Query dumm in die Datenbank. MySQL wirft fatal Error (Table exists), die Pipeline zerschellt lautstark. Cloud-Infrastruktur Pipelines müssen zwingend idempotent sein. Man nutzt Infrastructure-as-Code (Terraform/Ansible) oder Code-Logik: IF NOT EXISTS CREATE.... Eine idempotente Task kann 1 oder 10.000 Mal am Tag rennen (auch im Abbruch-Desaster-Fall), das Endergebnis ist streng monoton und der Zielzustand der Infrastruktur ist verlässlich der exakt selbe, ohne dass Errors geworfen werden.

3. Pipeline Metrics (DORA)

Wer DevOps sagt, muss DORA-Metriken (DevOps Research and Assessment) messen. Große Firmen füttern all ihre Pipeline-API Webhooks in eine Zeitreihendatenbank. Sie optimieren auf:

1. Deployment Frequency: Wie oft pusht die Pipeline pro Woche auf Production (Agilität).
2. Lead Time For Changes: Commit eingetippt -> Pipeline Build -> Code Live beim Kunden (Speed / Pipelinedauer).
3. Change Failure Rate: Wie viel Prozent der Pipeline-Deploys zerschießen die Produktion und triggern Rollbacks?

   Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: GitHub Actions Beispiel: yaml name: CI on: [push] jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - run: npm install - run: npm test Du siehst grüne Haken oder rote Kreuze direkt neben deinem Commit auf GitHub.
4. Time To Restore: Pipeline-Dauer für Bugfix-Deployment Thematiken (Incident Reaction). Ohne Telemetrie ist eine Hochlast-CI/CD-Pipeline reiner Blindflug.