Zlomit build: co to je, příčiny a jak se vyhnout v projektu

Co znamená zlomit build ve vývoji

Zlomit build je situace, kdy po provedení změn projekt přestane sestavovat. V kontextu CI/CD to znamená, že pipeline sestavení končí chybou a artefakt není vytvořen.

Ve světě mobilního a webového vývoje je build proces převodu zdrojového kódu do spustitelného souboru nebo balíčku. Pro Android je to sestavení APK nebo AAB přes Gradle, pro iOS — kompilace přes Xcode, pro webové projekty — sestavení přes Webpack nebo Vite. Build lze zlomit v kterékoli z těchto fází.

Moderní systémy pro správu verzí a CI/CD nástroje, jako jsou Jenkins, GitHub Actions a GitLab CI, automaticky detekují zlomený build a upozorní tým. Ve většině projektů platí pravidlo: pokud je build zlomený, priorita všech ostatních úkolů klesá, dokud není kompilace opravena.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Tento řádek ničí build
    val number: Int = "not a number"
}

V tomto příkladu způsobí přiřazení řetězce proměnné typu Int chybu kompilace. Type mismatch — jedna z nejčastějších příčin zlomeného buildu ve staticky typovaných jazycích.

Hlavní příčiny rozbití kompilace

Existuje několik kategorií chyb, které vedou ke zlomenému buildu. Podle analýzy GitLabu za rok 2024 vypadá rozdělení příčin následovně.

Nejzákeřnější kategorie — problémy se závislostmi. Aktualizace knihovny v jednom modulu může zlomit build v sousedním modulu, pokud se změnilo API nebo chování metod.

Syntaktické chyby jsou naopak rychle detekovány — kompilátor ukazuje přesný řádek a typ chyby. Proto jsou staticky typované jazyky považovány za spolehlivější v kontextu stability kompilace než dynamicky typované jazyky.

Jak zlomený build ovlivňuje tým

Zlomený build přímo ovlivňuje produktivitu týmu. Když kompilace selže, vývojáři nemohou získat aktuální verzi projektu z repozitáře a CI pipeline je blokován pro všechny následující změny.

Výzkum Atlassian z roku 2023 ukázal, že projekty, kde build zůstává zlomený déle než čtyři hodiny, ztrácejí v průměru 25% produktivního času týmu. Vývojáři jsou nuceni věnovat se diagnostice problému místo plnění svých úkolů.

Kromě produktivity trpí i morální klima. Vývojář, který zlomil build, cítí tlak od kolegů. Ve zdravých týmech platí pravidlo: netrestat za zlomený build, ale vyžadovat okamžitou opravu. Blameless culture — přístup, kde je incident analyzován jako systémový problém, ne něčí chyba.

V distribuovaných týmech může zlomený build blokovat práci zaměstnanců v jiném časovém pásmu. Pokud vývojář z Evropy zlomil build před odchodem, tým z Asie může ztratit celý pracovní den čekáním na opravu.

Jak předejít zlomenému buildu

Prevence zlomeného buildu začíná lokálními kontrolami před commitem. Každý vývojář by měl spouštět testy a kompilaci před odesláním změn. Hlavní metody prevence se dělí do několika úrovní.

• Pre-commit hooky — automatické kontroly před vytvořením commitu, včetně linterů a formatterů
• Lokální sestavení — spuštění kompilace před pushem, zejména pro staticky typované jazyky
• Unit testy — pokrytí klíčových modulů testy pro včasné odhalení regresí
• Code review — kontrola změn kolegou před mergem do hlavní větve

Druhá úroveň — nastavení CI/CD pipeline. Každý Pull Request musí projít automatickým sestavením a testováním před mergem. Pokud sestavení selže, PR je blokován do opravy. Tento přístup se nazývá gated commit a používá se ve většině moderních projektů.

Třetí úroveň — monitoring a statistika. Týmy sledují metriku doby obnovení kompilace — MTTR (Mean Time To Repair). Čím nižší je tento ukazatel, tím rychleji tým reaguje na zlomený build. Cílová hodnota — ne více než 30 minut.

Co dělat, když je build zlomený

Když je build zlomený, prvním krokem je zjistit, který vývojář provedl poslední změny. Git poskytuje nástroj git bisect, který umožňuje najít commit, který zlomil kompilaci, binárním vyhledáváním.

# Zahaj bisect se známými dobrými a špatnými commity
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git zkontroluje commit uprostřed
# Sestav a otestuj, poté označ:
git bisect good  # if build passes
git bisect bad   # if build fails

# Po ~log2(n) krocích git ukáže viníka
git bisect reset

Po nalezení problémového commitu jsou možné dvě varianty. První — vrácení změn pomocí git revert, pokud oprava vyžaduje čas. To je nejbezpečnější přístup, zejména když build blokuje celý tým.

Druhá varianta — okamžitá oprava novým commitem. Tento přístup je preferován, pokud je problém lokální a jasný. Po opravě pushněte změny a ujistěte se, že build úspěšně prošel. V každém případě doba obnovení kompilace nesmí přesáhnout jednu hodinu.