Continuous Integration

Continuous Integration wird weithin missverstanden. Es ist nicht nur ein Build-Server. Es ist nicht nur das Ausführen von Tests bei jedem Commit. Das sind Werkzeuge, die CI unterstützen – aber CI selbst ist eine Praxis.

Echtes CI bedeutet:

• Jeder committet mindestens täglich in den Hauptbranch (oder Trunk)
• Jeder Commit löst einen Build- und Testlauf aus
• Wenn der Build fehlschlägt, hat das Beheben oberste Priorität
• Der Hauptbranch ist immer in einem auslieferbaren Zustand

Der „kontinuierliche" Teil ist entscheidend. Wenn du wöchentlich integrierst, ist das nicht kontinuierlich. Wenn du langlebige Feature-Branches hast, ist das nicht kontinuierlich. CI bedeutet, deine Arbeit jeden Tag mit der Arbeit aller anderen zu integrieren, normalerweise mehrmals täglich.

Echtes CI erfordert Trunk-Based Development: Jeder committet in den Hauptbranch (oft „Trunk" oder „Main" genannt).

Das klingt beängstigend. Werden die Leute nicht Dinge kaputt machen? Hier kommt die Disziplin ins Spiel:

• Führe Tests vor dem Commit aus (brich den Build nicht)
• Committe kleine Änderungen (einfacher zu integrieren, einfacher zu beheben)
• Behebe fehlerhafte Builds sofort (alle stoppen, bis er grün ist)
• Verwende Feature Flags für unvollständige Features (damit sie gemergt, aber nicht aktiviert werden können)

Langlebige Branches sind der Feind von CI. Wenn du wochenlang auf einem Branch entwickelst, integrierst du nicht. Du schiebst die Integration nur auf – und je länger du wartest, desto schwieriger wird es.

Branch für Stunden, nicht Tage. Integriere täglich, nicht wöchentlich.

Damit CI funktioniert, muss der Build- und Testzyklus schnell sein. Martin Fowler schlägt die 10-Minuten-Regel vor: Der gesamte Build, einschließlich aller Tests, sollte in unter 10 Minuten abgeschlossen sein.

Warum 10 Minuten? Weil:

• Entwickler schnelles Feedback zu ihren Änderungen brauchen
• Eine Stunde zu warten, um zu wissen, ob man etwas kaputt gemacht hat, zu langsam ist
• Lange Builds Entwickler dazu ermutigen, das lokale Ausführen von Tests zu überspringen

Wenn dein Build zu lange dauert:

• Parallelisiere Tests
• Verwende schnellere Hardware
• Optimiere die langsamsten Tests
• Erwäge Test-Kategorisierung (schnelle Unit-Tests vs. langsame Integrationstests)
• Überdenke das Testdesign (zu viel Datenbank? zu viel Netzwerk?)

Manche Teams führen lokal eine schnelle Teilmenge aus (Unit-Tests) und die vollständige Suite auf dem CI-Server. Das ist in Ordnung, solange die vollständige Suite schnell genug läuft, um zeitnahes Feedback zu geben.

Der Build wird fehlschlagen. Was zählt, ist, was als Nächstes passiert.

Die Regel: Wenn der Build fehlschlägt, wird das Beheben zur obersten Priorität. Alles andere stoppt.

Das mag extrem erscheinen, aber bedenke: Ein fehlerhafter Build bedeutet, dass das Team dem Hauptbranch nicht vertrauen kann. Die Arbeit aller ist blockiert, weil sie nicht sicher integrieren können. Jede Minute, die der Build fehlerhaft ist, ist eine Minute akkumuliertes Risiko.

Wer behebt es? Normalerweise die Person, die es kaputt gemacht hat. Aber wenn sie feststeckt, helfen andere. Ein fehlerhafter Build ist ein Teamproblem, kein individuelles Problem.

Wie man Fehler verhindert:

• Führe Tests lokal vor dem Commit aus
• Halte Änderungen klein (kleinere Änderungen = kleineres Risiko)
• Achte auf CI-Benachrichtigungen (behebe schnell)
• Committe nicht und gehe dann für den Tag

Manche Teams verwenden eine „CI-Sheriff"-Rotation – jemand, der dafür verantwortlich ist, den Build zu beobachten und Behebungen zu koordinieren. Das verhindert den Zuschauereffekt, bei dem jeder annimmt, dass jemand anderes es beheben wird.

CI ist die Grundlage für fortgeschrittenere Praktiken:

Continuous Delivery (CD): Jeder Commit kann in Produktion ausgeliefert werden. Deployment ist eine geschäftliche Entscheidung, keine technische.

Continuous Deployment: Jeder Commit, der Tests besteht, wird automatisch in Produktion ausgeliefert. Keine menschliche Genehmigung erforderlich.

Nicht jedes Team braucht Continuous Deployment. Aber jedes Team profitiert von CI. Fang dort an.

CI-Metriken, die man beobachten sollte:

• Build-Zeit (sollte unter 10 Minuten sein)
• Build-Häufigkeit (sollte mehrmals täglich pro Entwickler sein)
• Mittlere Zeit zur Behebung fehlerhafter Builds (sollte Minuten sein, nicht Stunden)
• Testabdeckung (keine perfekte Metrik, aber ein Signal)

Bei CI geht es nicht nur darum, Fehler zu finden. Es geht darum, einen Rhythmus zu schaffen, in dem Integration langweilig, routinemäßig und sicher ist. Wenn Integration sicher ist, wird alles andere einfacher.