Build elrontása: mi ez, okok és hogyan kerüljük el a projektben

Mit jelent a build elrontása a fejlesztésben

A build elrontása az a helyzet, amikor a módosítások után a projekt már nem építhető. A CI/CD kontextusában ez azt jelenti, hogy az építési pipeline hiba miatt ér véget és az artifact nem jön létre.

A mobil és webfejlesztés világában a build a forráskód futtatható fájllá vagy csomaggá alakításának folyamata. Android esetén ez APK vagy AAB építése Gradle segítségével, iOS esetén — fordítás Xcode segítségével, webprojektek esetén — építés Webpack vagy Vite segítségével. A build ezen szakaszok bármelyikében elrontható.

A modern verziókezelő rendszerek és CI/CD eszközök, mint a Jenkins, a GitHub Actions és a GitLab CI, automatikusan észlelik az elrontott buildet és értesítik a csapatot. A legtöbb projektben létezik az a szabály, hogy ha a build elromlott, az összes többi feladat prioritása csökken, amíg a fordítás meg nem javul.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Ez a sor elrontja a buildet
    val number: Int = "not a number"
}

Ebben a példában egy string hozzárendelése egy Int típusú változóhoz fordítási hibát okoz. A Type mismatch — az egyik leggyakoribb oka az elrontott buildnek a statikusan típusos nyelvekben.

A fordítás meghibásodásának fő okai

Számos hibakategória létezik, amelyek elrontott buildhez vezetnek. A GitLab 2024-es elemzése szerint az okok eloszlása a következő.

A legveszélyesebb kategória — a függőségi problémák. Egy könyvtár frissítése az egyik modulban elronthatja a buildet a szomszédos modulban, ha megváltozott az API vagy a metódusok viselkedése.

A szintaktikai hibák ezzel szemben gyorsan észlelhetők — a fordító pontosan megadja a hibás sort és a hiba típusát. Emiatt a statikusan típusos nyelveket megbízhatóbbnak tekintik a fordítási stabilitás szempontjából, mint a dinamikusan típusos nyelveket.

Hogyan hat az elrontott build a csapatra

Az elrontott build közvetlenül befolyásolja a csapat termelékenységét. Amikor a fordítás meghiúsul, a fejlesztők nem tudják megszerezni a projekt aktuális verzióját a tárhelyből, és a CI pipeline blokkolva van minden további módosítás számára.

Az Atlassian 2023-as kutatása kimutatta, hogy azok a projektek, ahol a build négy óránál tovább marad elrontva, átlagosan 25%-kal veszítenek a csapat produktív idejéből. A fejlesztők kénytelenek a probléma diagnosztizálásával foglalkozni ahelyett, hogy a saját feladataikat végeznék.

A termelékenységen kívül a morális klíma is szenved. Az a fejlesztő, aki elrontotta a buildet, nyomást érez a kollégák részéről. Az egészséges csapatokban az a szabály érvényes: ne büntessük az elrontott buildért, de követeljük meg az azonnali javítást. Blameless culture — az a megközelítés, ahol az incidenst rendszerszintű problémaként elemzik, nem pedig valakinek a hibájaként.

Az elosztott csapatokban az elrontott build blokkolhatja a más időzónában dolgozó munkatársak munkáját. Ha egy európai fejlesztő elrontotta a buildet a távozása előtt, az ázsiai csapat egy teljes munkanapot veszíthet a javításra várva.

Hogyan előzzük meg az elrontott buildet

Az elrontott build megelőzése a commit előtti helyi ellenőrzésekkel kezdődik. Minden fejlesztőnek futtatnia kell a teszteket és a fordítást a módosítások elküldése előtt. A megelőzés fő módszerei több szintre oszthatók.

• Pre-commit hookok — automatikus ellenőrzések a commit létrehozása előtt, beleértve a lintereket és formattereket
• Helyi fordítás — a fordítás futtatása push előtt, különösen statikusan típusos nyelveknél
• Egységtesztek — a kulcsmodulok lefedése tesztekkel a regressziók korai észleléséhez
• Code review — a módosítások ellenőrzése kolléga által a főágba történő merge előtt

Második szint — a CI/CD pipeline konfigurálása. Minden Pull Requestnek át kell esnie automatikus fordításon és tesztelésen a merge előtt. Ha a fordítás meghiúsul, a PR blokkolva van a javításig. Ezt a megközelítést gated commitnak hívják, és a legtöbb modern projektben használják.

Harmadik szint — monitoring és statisztika. A csapatok követik a fordítás helyreállítási idejének metrikáját — MTTR (Mean Time To Repair). Minél alacsonyabb ez a mutató, annál gyorsabban reagál a csapat az elrontott buildre. Célérték — legfeljebb 30 perc.

Mit tegyünk, ha a build elromlott

Amikor a build elromlott, az első lépés annak megállapítása, hogy melyik fejlesztő hajtotta végre az utolsó módosításokat. A Git biztosítja a git bisect eszközt, amely lehetővé teszi a buildet elrontó commit megtalálását bináris kereséssel.

# Kezdd el a bisect-et ismert jó és rossz committal
git bisect start
git bisect bad HEAD
git bisect good abc1234

# A Git megvizsgál egy közbenső commitot
# Építsd és teszteld, majd jelöld meg:
git bisect good  # if build passes
git bisect bad   # if build fails

# Kb. log2(n) lépés után a Git megmutatja a tettest
git bisect reset

A problémás commit megtalálása után két lehetőség van. Az első — a módosítások visszavonása a git revert segítségével, ha a javítás időt igényel. Ez a legbiztonságosabb megközelítés, különösen akkor, ha a build az egész csapatot blokkolja.

A második lehetőség — azonnali javítás új committal. Ez a megközelítés akkor előnyösebb, ha a probléma lokális és egyértelmű. A javítás után pusholni kell a módosításokat és meg kell győződni arról, hogy a build sikeresen lefutott. Minden esetben a fordítás helyreállítási ideje nem haladhatja meg az egy órát.