Build breken: wat is het, oorzaken en hoe te vermijden in een project

Wat betekent build breken in ontwikkeling

Build breken is de situatie waarin het project na het aanbrengen van wijzigingen niet meer bouwt. In de context van CI/CD betekent dit dat de build-pipeline eindigt met een fout en er geen artefact wordt aangemaakt.

In de wereld van mobiele en webontwikkeling is de build het proces van het omzetten van broncode naar een uitvoerbaar bestand of pakket. Voor Android is dit het bouwen van APK of AAB via Gradle, voor iOS — compilatie via Xcode, voor webprojecten — bouwen via Webpack of Vite. De build kan in elk van deze fasen worden gebroken.

Moderne versiebeheersystemen en CI/CD-tools zoals Jenkins, GitHub Actions en GitLab CI detecteren automatisch een gebroken build en stellen het team op de hoogte. In de meeste projecten geldt de regel: als de build gebroken is, wordt de prioriteit van alle andere taken verlaagd totdat de compilatie is hersteld.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Deze regel breekt de build
    val number: Int = "not a number"
}

In dit voorbeeld veroorzaakt het toewijzen van een string aan een variabele van het type Int een compilatiefout. Type mismatch — een van de meest voorkomende oorzaken van een gebroken build in statisch getypeerde talen.

Belangrijkste oorzaken van buildbreuk

Er bestaan verschillende categorieën fouten die leiden tot een gebroken build. Volgens de analyse van GitLab voor 2024 ziet de verdeling van oorzaken er als volgt uit.

De meest verraderlijke categorie — afhankelijkheidsproblemen. Het bijwerken van een bibliotheek in één module kan de build in een naburige module breken als de API of het gedrag van methoden is veranderd.

Syntaxisfouten worden daarentegen snel gedetecteerd — de compiler geeft de exacte regel en het type fout aan. Daarom worden statisch getypeerde talen als betrouwbaarder beschouwd in de context van buildstabiliteit dan dynamisch getypeerde talen.

Hoe een gebroken build het team beïnvloedt

Een gebroken build heeft directe invloed op de productiviteit van het team. Wanneer de compilatie faalt, kunnen ontwikkelaars de huidige versie van het project niet uit de repository halen en wordt de CI-pipeline geblokkeerd voor alle volgende wijzigingen.

Onderzoek van Atlassian uit 2023 toonde aan dat projecten waarin de build langer dan vier uur gebroken blijft, gemiddeld 25% van de productieve tijd van het team verliezen. Ontwikkelaars worden gedwongen zich bezig te houden met het diagnosticeren van het probleem in plaats van hun taken uit te voeren.

Naast productiviteit lijdt ook het morele klimaat. De ontwikkelaar die de build heeft gebroken, voelt druk van collega’s. In gezonde teams geldt de regel: niet straffen voor een gebroken build, maar onmiddellijk herstel eisen. Blameless culture — een benadering waarbij het incident wordt geanalyseerd als een systeemprobleem, niet als iemands fout.

In gedistribueerde teams kan een gebroken build het werk van medewerkers in een andere tijdzone blokkeren. Als een ontwikkelaar uit Europa de build heeft gebroken voordat hij wegging, kan het team in Azië een hele werkdag verliezen in afwachting van het herstel.

Hoe een gebroken build te voorkomen

Het voorkomen van een gebroken build begint met lokale controles vóór de commit. Elke ontwikkelaar moet tests en de compilatie uitvoeren voordat hij wijzigingen verzendt. De belangrijkste preventiemethoden zijn onderverdeeld in verschillende niveaus.

• Pre-commit hooks — automatische controles vóór het aanmaken van een commit, inclusief linters en formatters
• Lokale build — het uitvoeren van de compilatie vóór het pushen, vooral voor statisch getypeerde talen
• Unittests — het afdekken van kernmodules met tests voor het vroegtijdig opsporen van regressies
• Code review — het controleren van wijzigingen door een collega vóór het mergen in de hoofdtak

Het tweede niveau — het configureren van de CI/CD-pipeline. Elke Pull Request moet vóór het mergen door een automatische build en testen gaan. Als de build faalt, wordt de PR geblokkeerd tot herstel. Deze benadering wordt gated commit genoemd en wordt in de meeste moderne projecten gebruikt.

Het derde niveau — monitoring en statistiek. Teams volgen de metriek van de hersteltijd van de build — MTTR (Mean Time To Repair). Hoe lager deze indicator, hoe sneller het team reageert op een gebroken build. Streefwaarde — niet meer dan 30 minuten.

Wat te doen als de build gebroken is

Wanneer de build gebroken is, is de eerste stap om vast te stellen welke ontwikkelaar de laatste wijzigingen heeft aangebracht. Git biedt de tool git bisect waarmee u de commit die de build heeft gebroken kunt vinden via binair zoeken.

# Start bisect met bekende goede en slechte commits
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git controleert een commit in het midden
# Bouw en test, markeer dan:
git bisect good  # if build passes
git bisect bad   # if build fails

# Na ~log2(n) stappen toont git de boosdoener
git bisect reset

Na het vinden van de problematische commit zijn er twee mogelijke acties. De eerste — het terugdraaien van wijzigingen via git revert, als het herstel tijd kost. Dit is de veiligste aanpak, vooral wanneer de build het hele team blokkeert.

De tweede optie — onmiddellijk herstel met een nieuwe commit. Deze aanpak heeft de voorkeur als het probleem lokaal en duidelijk is. Na het herstel moeten de wijzigingen worden gepusht en moet worden gecontroleerd of de build succesvol is verlopen. In elk geval mag de hersteltijd van de compilatie niet meer dan een uur bedragen.