Bryta bygget: vad det är, orsaker och hur man undviker i projektet

Vad innebär det att bryta bygget i utveckling

Att bryta bygget är situationen när projektet efter att ha gjort ändringar slutar att byggas. I sammanhanget CI/CD innebär detta att byggpipelinen avslutas med ett fel och artefakten skapas inte.

I världen av mobil- och webbutveckling är bygget processen att omvandla källkod till en körbar fil eller ett paket. För Android är det kompilering av APK eller AAB via Gradle, för iOS — kompilering via Xcode, för webbprojekt — byggning via Webpack eller Vite. Bygget kan brytas i vilken som helst av dessa faser.

Moderna versionshanteringssystem och CI/CD-verktyg som Jenkins, GitHub Actions och GitLab CI upptäcker automatiskt ett brutet bygge och meddelar teamet. I de flesta projekt finns regeln: om bygget är brutet sänks prioriteringen för alla andra uppgifter tills kompileringen är reparerad.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Den här raden bryter bygget
    val number: Int = "not a number"
}

I detta exempel orsakar tilldelningen av en sträng till en variabel av typen Int ett kompileringsfel. Type mismatch — en av de vanligaste orsakerna till brutet bygge i statiskt typade språk.

Huvudorsaker till byggbrott

Det finns flera kategorier av fel som leder till ett brutet bygge. Enligt GitLabs analys för 2024 ser fördelningen av orsaker ut som följer.

Den mest lömska kategorin — beroendeproblem. Uppdatering av ett bibliotek i en modul kan bryta bygget i en angränsande modul om API eller metodernas beteende har ändrats.

Syntaxfel upptäcks däremot snabbt — kompilatorn anger exakt rad och feltyp. Därför anses statiskt typade språk vara mer pålitliga när det gäller kompileringsstabilitet än dynamiskt typade språk.

Hur ett brutet bygge påverkar teamet

Ett brutet bygge påverkar direkt teamets produktivitet. När kompileringen misslyckas kan utvecklarna inte få den aktuella versionen av projektet från repositoryt och CI-pipelinen blockeras för alla efterföljande ändringar.

Forskning av Atlassian från 2023 visade att projekt där bygget förblir brutet längre än fyra timmar förlorar i genomsnitt 25% av teamets produktiva tid. Utvecklare tvingas ägna sig åt att diagnostisera problemet istället för att utföra sina uppgifter.

Förutom produktiviteten lider också det moraliska klimatet. Utvecklaren som bröt bygget känner press från kollegor. I friska team gäller regeln: straffa inte för brutet bygge, men kräv omedelbar reparation. Blameless culture — ett förhållningssätt där incidenten analyseras som ett systemproblem, inte någons fel.

I distribuerade team kan ett brutet bygge blockera arbetet för anställda i en annan tidszon. Om en utvecklare från Europa bröt bygget innan han gick, kan teamet från Asien förlora en hel arbetsdag i väntan på reparation.

Hur man förebygger ett brutet bygge

Att förebygga ett brutet bygge börjar med lokala kontroller före commit. Varje utvecklare bör köra tester och kompilering innan de skickar ändringar. De viktigaste förebyggande metoderna delas in i flera nivåer.

• Pre-commit hooks — automatiska kontroller före skapandet av commit, inklusive linters och formatterare
• Lokal byggning — körning av kompilering före push, särskilt för statiskt typade språk
• Enhetstester — täckning av nyckelmoduler med tester för tidig upptäckt av regressioner
• Code review — kontroll av ändringar av en kollega före merge i huvudgrenen

Andra nivån — konfiguration av CI/CD-pipelinen. Varje Pull Request måste gå igenom automatisk byggning och testning före merge. Om byggningen misslyckas blockeras PR tills reparation. Detta tillvägagångssätt kallas gated commit och används i de flesta moderna projekt.

Tredje nivån — övervakning och statistik. Team följer metriken för återställningstid av kompilering — MTTR (Mean Time To Repair). Ju lägre denna indikator är, desto snabbare reagerar teamet på ett brutet bygge. Målvärde — inte mer än 30 minuter.

Vad man ska göra om bygget är brutet

När bygget är brutet är första steget att fastställa vilken utvecklare som gjorde de senaste ändringarna. Git tillhandahåller verktyget git bisect som gör det möjligt att hitta commiten som bröt kompileringen genom binär sökning.

# Starta bisect med kända bra och dåliga commits
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git checkar ut en commit i mitten
# Bygg och testa, markera sedan:
git bisect good  # if build passes
git bisect bad   # if build fails

# Efter ~log2(n) steg visar git boven
git bisect reset

Efter att ha hittat den problematiska commiten finns två alternativ. Första — återställning av ändringar via git revert, om reparation kräver tid. Detta är den säkraste metoden, särskilt när bygget blockerar hela teamet.

Andra alternativet — omedelbar reparation med en ny commit. Detta tillvägagångssätt är att föredra om problemet är lokalt och tydligt. Efter reparation, pusha ändringarna och se till att bygget gick igenom. I vilket fall som helst får återställningstiden för kompilering inte överstiga en timme.