Continuous Integration (CI)

Du nutzt Tools wie GitHub Actions, GitLab CI oder Jenkins. In einer YAML-Datei (.github/workflows/ci.yml) definierst du die Schritte:

on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm test

Sobald du pushst, siehst du in GitHub einen grünen Haken oder ein rotes Kreuz. "Don't break the build!" ist das oberste Gebot im Team.

1. Trunk-Based Development

Das Ziel von CI ist kurze Feedback-Loops. Wenn du einen langlebigen Branch ("Feature Branch") hast, den du 3 Wochen lang nicht mergest, machst du kein CI (auch wenn Jenkins läuft). Das nennt man "CI Theatre". Echtes CI bedeutet: Jeder commitet auf main (Trunk) oder sehr kurzlebige Branches (< 1 Tag). Das minimiert Konflikte.

2. Test Pyramid & Flaky Tests

Damit CI funktioniert, müssen Tests schnell sein (weniger als 10 Minuten). Wenn Tests 2 Stunden dauern, committet niemand mehr oft. Daher: Viele kleine Unit Tests (schnell), wenige langsame End-to-End Tests. Der Feind von CI sind Flaky Tests (Tests, die manchmal failen, manchmal passen, ohne Code-Änderung). Sie zerstören das Vertrauen ("Ach, der Test ist eh rot, ich merge trotzdem"). Behandle Flaky Tests wie Bugs!

3. Caching & Parallelisierung

Um Builds schnell zu halten:

• Dependency Caching: node_modules nicht jedes Mal neu laden.
• Docker Layer Caching: Alte Layer wiederverwenden.
• Parallel Jobs: Frontend-Tests und Backend-Tests gleichzeitig auf 2 Maschinen laufen lassen (Fan-out).

Hermetic Builds & Reproducibility

Ein großes Problem in CI ist: "Der Build hat heute funktioniert, morgen bricht er ab, obwohl sich der Code nicht geändert hat." Das passiert, wenn der Build Abhängigkeiten aus dem Internet zieht (z.B. ein wildes curl | bash in einem Makefile, oder npm install, das eine geupdatete Minor-Version lädt). Die Profilösung sind Hermetic Builds (z. B. via Bazel oder Nix). Ein hermetischer Build schneidet während des Kompiliervorgangs das Netzwerk komplett ab. Der Compiler hat nur Zugriff auf vorher deklarierte und per Hash festgenagelte Artefakte. Das garantiert 100%ige Reproduzierbarkeit – du kannst Commit X Jahre später bauen und bekommst Bit-für-Bit dasselbe Binary.

Test Containers und flüchtige Infrastruktur

Wie testet man Code, der eine echte PostgreSQL-Datenbank braucht, in der CI Pipeline? Früher hat man eine (globale) Datenbank für alle Tests aufgesetzt. Folge: "State Bleeding" (Test A löscht den User, den Test B gerade braucht). Der Standard heute sind Testcontainers (eine Library für Java/Go/Node). Der Unit-Test selbst triggert die Docker-API, fährt eine leere, frische PostgreSQL hoch, führt die Schema-Migrationen aus, testet dagegen und verwirft den Container am Ende. Jeder CI-Lauf und sogar jeder Test-Node hat totale Isoliertheit ("Ephemeral Environments").

Shift-Left (SAST, DAST, SCA)

CI ist der ideale Ort für "Shift-Left" – also Probleme so früh (so weit links auf dem Zeitstrahl) wie möglich zu finden. Anstatt Security erst beim Pentest vor dem Release zu prüfen, läuft sie im CI:

1. SAST (Static Application Security Testing): Tools wie SonarQube lesen den Quellcode und warnen vor SQL-Injection.
2. SCA (Software Composition Analysis): Tools wie Trivy oder Snyk scannen die package.json und melden "Library X ist veraltet und hat eine CVE". Erst wenn diese Sicherheitstests lokal im CI grün sind, wird der Code als "integriert" betrachtet.