Continuous Integration (CI)

Continuous Integration (CI, kontinuierliche Integration) bedeutet, dass Entwickler kleine Änderungen häufig in den Hauptbranch mergen und ein Server bei jedem Push oder Pull Request den Code baut und die automatisierten Tests ausführt. Es geht um schnelles Feedback: Wenn eine Änderung etwas kaputt macht, erfährt der Autor es, solange die Änderung noch frisch ist, und nicht Tage später bei einem großen Merge.

Beispiel (GitHub Actions)

Eine minimale Pipeline, die die Testsuite bei jedem Pull Request und bei Pushes auf main ausführt:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

Endet npm test mit einem Exit-Code ungleich null, schlägt der Job fehl und der Pull Request zeigt einen roten Check. Zusammen mit einer Branch Protection, die diesen Check verlangt, kann kaputter Code nicht gemergt werden.

Wofür Tester in der CI verantwortlich sind

• Welche Tests wo laufen. Schnelle Unit- und API-Tests bei jedem Pull Request; langsamere End-to-End-Suites beim Merge oder zeitgesteuert. Eine Pull-Request-Pipeline, die 40 Minuten dauert, wird irgendwann nicht mehr genutzt.
• Qualität des Signals. Ein Flaky Test in einem blockierenden Job erzieht die Leute dazu, auf „Re-run“ zu klicken. Stellen Sie Flaky Tests unter Quarantäne, damit ein roter Build immer etwas bedeutet.
• Artefakte. Veröffentlichen Sie Reports, Traces und Screenshots fehlgeschlagener Läufe, damit niemand einen Fehler lokal reproduzieren muss, nur um ihn zu sehen.
• Parallelisierung. Eine lange Suite per Sharding auf mehrere Maschinen zu verteilen, hält die Feedbackzeit konstant, während die Suite wächst.

Unterschied zu CD

Continuous Delivery erweitert CI: Jeder bestandene Build wird paketiert und releasefertig gehalten, meist über Staging-Umgebungen. Continuous Deployment geht noch einen Schritt weiter und bringt jede bestandene Änderung automatisch in Produktion. CI ist die Grundlage für beides; ohne eine vertrauenswürdige Testsuite bei jedem Commit ist keines davon sicher.

Häufige Fehler

CI nur nächtlich laufen lassen, den Hauptbranch tagelang rot lassen und die Pipeline als den Ort betrachten, an dem Tests geschrieben werden, statt an dem sie laufen. CI ist ebenso sehr eine Teamgewohnheit wie ein Tool: kleine Merges und „fix or revert“, sobald der Build bricht.