Build kaputt machen: Was es ist, Ursachen und wie man es im Projekt vermeidet

Was bedeutet Build kaputt machen in der Entwicklung

Einen Build kaputt zu machen ist eine Situation, in der das Projekt nach Änderungen nicht mehr gebaut wird. Im Kontext von CI/CD bedeutet dies, dass die Build-Pipeline fehlschlägt und kein Artefakt erstellt wird.

In der Welt der Mobil- und Webentwicklung ist ein Build der Prozess der Übersetzung von Quellcode in eine ausführbare Datei oder ein Paket. Für Android ist es das Erstellen einer APK oder AAB über Gradle; für iOS die Kompilierung über Xcode; für Webprojekte das Bündeln über Webpack oder Vite. Sie können den Build in jeder dieser Phasen kaputt machen.

Moderne Versionskontrollsysteme und CI/CD-Tools wie Jenkins, GitHub Actions und GitLab CI erkennen automatisch einen kaputten Build und benachrichtigen das Team. In den meisten Projekten gilt die Regel: Wenn der Build kaputt ist, wird die Priorität aller anderen Aufgaben gesenkt, bis der Build repariert ist.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Diese Zeile macht den Build kaputt
    val number: Int = "not a number"
}

In diesem Beispiel verursacht die Zuweisung eines Strings zu einer Variablen vom Typ Int einen Kompilierungsfehler. Typkonflikte sind eine der häufigsten Ursachen für einen kaputten Build in statisch typisierten Sprachen.

Hauptursachen für Build-Fehler

Es gibt mehrere Kategorien von Fehlern, die zu einem kaputten Build führen. Laut der GitLab-Analyse für 2024 verteilen sich die Ursachen wie folgt.

Die tückischste Kategorie sind Abhängigkeitsprobleme. Die Aktualisierung einer Bibliothek in einem Modul kann den Build in einem benachbarten Modul kaputt machen, wenn sich die API oder das Verhalten von Methoden ändert.

Syntaxfehler hingegen werden schnell erkannt — der Compiler gibt die genaue Zeile und den Fehlertyp an. Deshalb gelten statisch typisierte Sprachen in Bezug auf die Build-Stabilität als zuverlässiger als dynamisch typisierte.

Wie ein kaputter Build das Team beeinflusst

Ein kaputter Build wirkt sich direkt auf die Produktivität des Teams aus. Wenn der Build fehlschlägt, können Entwickler die aktuelle Version des Projekts nicht aus dem Repository beziehen, und die CI-Pipeline wird für alle nachfolgenden Änderungen blockiert.

Eine Atlassian-Studie aus dem Jahr 2023 zeigte, dass Projekte, bei denen der Build länger als vier Stunden kaputt bleibt, durchschnittlich 25% der produktiven Zeit des Teams verlieren. Entwickler sind gezwungen, ihre Aufmerksamkeit auf die Diagnose des Problems zu richten, anstatt ihre Aufgaben zu erfüllen.

Neben der Produktivität leidet auch die Moral im Team. Der Entwickler, der den Build kaputt gemacht hat, steht unter Druck von Kollegen. In gesunden Teams gilt die Regel: Nicht für einen kaputten Build bestrafen, aber eine sofortige Behebung verlangen. Die Blameless Culture ist ein Ansatz, bei dem der Vorfall als systemisches Problem analysiert wird, nicht als Fehler einer Person.

In verteilten Teams kann ein kaputter Build die Arbeit von Kollegen in einer anderen Zeitzone blockieren. Wenn ein Entwickler aus Europa den Build vor Feierabend kaputt macht, kann das Team in Asien einen ganzen Arbeitstag verlieren, während es auf die Behebung wartet.

Wie man einen kaputten Build verhindert

Die Prävention eines kaputten Builds beginnt mit lokalen Überprüfungen vor dem Commit. Jeder Entwickler sollte vor dem Pushen von Änderungen Tests und den Build ausführen. Die wichtigsten Präventionsmethoden sind in mehrere Ebenen unterteilt.

• Pre-Commit-Hooks — automatische Prüfungen vor dem Erstellen eines Commits, einschließlich Lintern und Formatierern
• Lokaler Build — Ausführen der Kompilierung vor dem Push, insbesondere bei statisch typisierten Sprachen
• Unit-Tests — Abdeckung wichtiger Module mit Tests zur frühzeitigen Erkennung von Regressionen
• Code-Review — Überprüfung von Änderungen durch einen Kollegen vor dem Merge in den Hauptzweig

Die zweite Ebene ist die Konfiguration der CI/CD-Pipeline. Jeder Pull-Request muss vor dem Merge automatischen Build und Tests durchlaufen. Wenn der Build fehlschlägt, wird der PR blockiert, bis er behoben ist. Dieser Ansatz wird als Gated Commit bezeichnet und in den meisten modernen Projekten verwendet.

Die dritte Ebene ist Monitoring und Statistik. Teams verfolgen die MTTR-Kennzahl (Mean Time To Repair). Je niedriger dieser Indikator, desto schneller reagiert das Team auf einen kaputten Build. Der Zielwert liegt bei maximal 30 Minuten.

Was tun, wenn der Build kaputt ist

Wenn der Build kaputt ist, besteht der erste Schritt darin, zu identifizieren, welcher Entwickler die letzten Änderungen vorgenommen hat. Git bietet das Tool git bisect, mit dem Sie den Commit finden können, der den Build durch binäre Suche kaputt gemacht hat.

# Bisect mit bekannten guten und schlechten Commits starten
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git checkt einen Commit in der Mitte aus
# Build und testen, dann markieren:
git bisect good  # if build passes
git bisect bad   # if build fails

# Nach ~log2(n) Schritten zeigt git den Übeltäter
git bisect reset

Nach dem Auffinden des problematischen Commits gibt es zwei mögliche Vorgehensweisen. Die erste ist das Zurücksetzen der Änderungen mit git revert, wenn die Behebung Zeit erfordert. Dies ist der sicherste Ansatz, insbesondere wenn der Build das gesamte Team blockiert.

Die zweite Option ist eine sofortige Korrektur mit einem neuen Commit. Dieser Ansatz ist vorzuziehen, wenn das Problem lokal und klar ist. Nach der Korrektur pushen Sie die Änderungen und bestätigen, dass der Build erfolgreich ist. In jedem Fall sollte die Wiederherstellungszeit des Builds eine Stunde nicht überschreiten.