Sira ang build: ano ito, dahilan at paano maiwasan sa proyekto

Ano ang ibig sabihin ng sira ang build sa pag-develop

Ang masira ang build ay sitwasyon kung kailan pagkatapos gumawa ng mga pagbabago, ang proyekto ay humihinto sa pag-build. Sa konteksto ng CI/CD, nangangahulugan ito na ang compilation pipeline ay nagtatapos sa error at hindi nagagawa ang artifact.

Sa mundo ng mobile at web development, ang build ay proseso ng pag-convert ng source code sa executable file o package. Para sa Android ito ay compilation ng APK o AAB sa pamamagitan ng Gradle, para sa iOS — compilation sa pamamagitan ng Xcode, para sa web projects — pag-build sa pamamagitan ng Webpack o Vite. Maaaring masira ang build sa alinman sa mga yugtong ito.

Ang mga modernong version control system at CI/CD tools, tulad ng Jenkins, GitHub Actions at GitLab CI, ay awtomatikong nakakakita ng sirang build at nag-aabiso sa team. Sa karamihan ng proyekto mayroong patakaran: kung sira ang build, bababa ang priyoridad ng lahat ng iba pang gawain hanggang sa maayos ang compilation.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Ang linyang ito ay sumisira sa build
    val number: Int = "not a number"
}

Sa halimbawang ito, ang pagtatalaga ng string sa variable na may uri na Int ay nagdudulot ng compilation error. Type mismatch — isa sa mga pinakakaraniwang dahilan ng sirang build sa statically-typed na mga wika.

Mga pangunahing dahilan ng pagkasira ng compilation

Mayroong ilang kategorya ng mga error na humahantong sa sirang build. Ayon sa analytics ng GitLab para sa 2024, ang distribusyon ng mga dahilan ay ang mga sumusunod.

Ang pinaka-mapanganib na kategorya — problema sa dependency. Ang pag-update ng library sa isang module ay maaaring makasira ng build sa kalapit na module, kung nagbago ang API o pag-uugali ng mga pamamaraan.

Ang syntax error, sa kabilang banda, ay mabilis na natutuklasan — ang compiler ay nagpapakita ng eksaktong linya at uri ng error. Kaya naman ang statically-typed na mga wika ay itinuturing na mas maaasahan sa konteksto ng stability ng compilation kaysa sa dynamically-typed na mga wika.

Paano nakakaapekto ang sirang build sa team

Ang sirang build ay direktang nakakaapekto sa produktibidad ng team. Kapag ang compilation ay bigo, hindi makukuha ng mga developer ang kasalukuyang bersyon ng proyekto mula sa repository, at ang CI pipeline ay naba-block para sa lahat ng kasunod na pagbabago.

Ang pananaliksik ng Atlassian noong 2023 ay nagpakita na ang mga proyekto kung saan nananatiling sira ang build nang higit sa apat na oras ay nawawalan ng average na 25% ng produktibong oras ng team. Ang mga developer ay napipilitang ilihis ang atensyon sa pag-diagnose ng problema sa halip na gawin ang kanilang mga gawain.

Bukod sa produktibidad, naaapektuhan din ang moral na klima. Ang developer na sumira ng build ay nakakaramdam ng pressure mula sa mga kasamahan. Sa malulusog na team mayroong patakaran: huwag parusahan dahil sa sirang build, ngunit hingin ang agarang pag-aayos. Blameless culture — approach kung saan ang insidente ay sinusuri bilang systemic na problema, hindi pagkakamali ng isang tao.

Sa mga distributed team, ang sirang build ay maaaring mag-block sa trabaho ng mga empleyado sa ibang time zone. Kung ang developer mula sa Europe ay sumira ng build bago umuwi, ang team mula sa Asia ay maaaring mawalan ng isang buong araw ng trabaho sa paghihintay ng pag-aayos.

Paano maiwasan ang sirang build

Ang pag-iwas sa sirang build ay nagsisimula sa lokal na pagsusuri bago mag-commit. Bawat developer ay dapat magpatakbo ng mga pagsubok at compilation bago magpadala ng mga pagbabago. Ang mga pangunahing paraan ng pag-iwas ay nahahati sa ilang antas.

• Pre-commit hook — awtomatikong pagsusuri bago gumawa ng commit, kabilang ang linter at formatter
• Lokal na compilation — pagpapatakbo ng compilation bago mag-push, lalo na para sa statically-typed na mga wika
• Unit test — pag-coverage ng mga key module ng mga pagsubok para sa maagang pagtuklas ng regression
• Code review — pagsusuri ng mga pagbabago ng kasamahan bago i-merge sa pangunahing branch

Ikalawang antas — konfigurasyon ng CI/CD pipeline. Bawat Pull Request ay dapat dumaan sa awtomatikong compilation at pagsubok bago i-merge. Kung bigo ang compilation, ang PR ay ba-block hanggang sa pag-aayos. Ang approach na ito ay tinatawag na gated commit at ginagamit sa karamihan ng modernong proyekto.

Ikatlong antas — monitoring at statistics. Sinusubaybayan ng mga team ang metric ng oras ng pag-recover ng compilation — MTTR (Mean Time To Repair). Kung mas mababa ang indicator na ito, mas mabilis ang reaksyon ng team sa sirang build. Target na halaga — hindi hihigit sa 30 minuto.

Ano ang gagawin kung sira ang build

Kapag sira ang build, ang unang hakbang ay alamin kung sinong developer ang huling gumawa ng mga pagbabago. Ang Git ay nagbibigay ng tool na git bisect na nagbibigay-daan upang mahanap ang commit na sumira ng compilation sa pamamagitan ng binary search.

# Simulan ang bisect gamit ang alam na mabuti at masamang commit
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Sinusuri ng Git ang isang commit sa gitna
# Buuin at subukan, pagkatapos ay markahan:
git bisect good  # if build passes
git bisect bad   # if build fails

# Pagkatapos ng ~log2(n) hakbang, ipinapakita ng git ang salarin
git bisect reset

Pagkatapos mahanap ang problematikong commit, may dalawang opsyon. Una — i-revert ang mga pagbabago sa pamamagitan ng git revert, kung ang pag-aayos ay nangangailangan ng oras. Ito ang pinakaligtas na approach, lalo na kapag ang build ay nagba-block sa buong team.

Ikalawang opsyon — agarang pag-aayos gamit ang bagong commit. Mas gusto ang approach na ito kung ang problema ay lokal at malinaw. Pagkatapos ng pag-aayos, i-push ang mga pagbabago at tiyaking matagumpay ang build. Sa anumang kaso, ang oras ng pag-recover ng compilation ay hindi dapat lumampas ng isang oras.