Buildi pozmaq: bu nədir, səbəbləri və layihədə necə qarşısını almaq olar

İnkişafda buildi pozmaq nə deməkdir

Buildi pozmaq — dəyişikliklər etdikdən sonra layihənin yığılmasını dayandırdığı vəziyyətdir. CI/CD kontekstində bu, qurğu pipeline-nin səhvlə bitdiyi və artefaktın yaradılmadığı anlamına gəlir.

Mobil və veb inkişaf dünyasında build mənbə kodunun icra olunan fayla və ya paketə çevrilməsi prosesidir. Android üçün bu Gradle vasitəsilə APK və ya AAB qurğusu, iOS üçün Xcode vasitəsilə kompilyasiya, veb layihələr üçün isə Webpack və ya Vite vasitəsilə yığılmasıdır. Buildi bu mərhələlərin hər hansı birində pozmaq olar.

Müasir versiya nəzarət sistemləri və CI/CD alətləri, məsələn Jenkins, GitHub Actions və GitLab CI, pozulmuş buildi avtomatik aşkarlayır və komandaya xəbərdarlıq edir. Əksər layihələrdə qayda qoyulub: əgər build pozulubsa, qurğu düzəldilənə qədər bütün digər tapşırıqların prioriteti aşağı salınır.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Bu sətir buildi pozur
    val number: Int = "not a number"
}

Bu nümunədə sətirin Int tipli dəyişənə mənimsədilməsi kompilyasiya xətasına səbəb olur. Type mismatch — statik tipli dillərdə buildin pozulmasının ən çox yayılmış səbəblərindən biridir.

Qurğunun pozulmasının əsas səbəbləri

Buildin pozulmasına gətirib çıxaran bir neçə kateqoriya səhvlər mövcuddur. GitLab-ın 2024-cü il analitikasına görə, səbəblərin bölgüsü aşağıdakı kimidir.

Ən məkrli kateqoriya — asılılıq problemləri. Bir modulda kitabxananın yenilənməsi qonşu modulda buildi poza bilər, əgər API və ya metodların davranışı dəyişibsə.

Sintaksis səhvləri isə tez aşkarlanır — kompilyator dəqiq sətri və səhv növünü göstərir. Buna görə statik tipli dillər qurğu sabitliyi baxımından dinamik tipli dillərdən daha etibarlı hesab olunur.

Pozulmuş build komandaya necə təsir edir

Pozulmuş build birbaşa komandanın məhsuldarlığına təsir edir. Qurğu uğursuz olduqda, proqramçılar repozitoriyadan layihənin cari versiyasını əldə edə bilmirlər, CI pipeline isə bütün sonrakı dəyişikliklər üçün bloklanır.

Atlassian-ın 2023-cü il tədqiqatı göstərdi ki, buildi dörd saatdan çox pozulmuş vəziyyətdə qalan layihələr komandanın məhsuldar vaxtının orta hesabla 25%-ni itirir. Proqramçılar öz tapşırıqlarını yerinə yetirmək əvəzinə problemin diaqnostikası ilə məşğul olmaq məcburiyyətində qalırlar.

Məhsuldarlıqdan əlavə, mənəvi iqlim də əziyyət çəkir. Buildi pozan proqramçı həmkarlarının təzyiqini hiss edir. Sağlam komandalarda qayda qəbul edilib: pozulmuş buildə görə cəzalandırma yox, təcili düzəliş tələb etmək. Blameless culture — hadisənin kiminsə səhvi deyil, sistemli problem kimi təhlil edildiyi yanaşma.

Paylanmış komandalarda pozulmuş build başqa saat qurşağındakı işçilərin işini bloklaya bilər. Avropalı proqramçı işdən çıxmamışdan əvvəl buildi pozubsa, Asiyadakı komanda düzəliş gözləyərək bütün iş gününü itirə bilər.

Pozulmuş buildin qarşısını necə almaq olar

Pozulmuş buildin qarşısını almaq committdən əvvəl lokal yoxlamalarla başlayır. Hər bir proqramçı dəyişikliklər göndərməzdən əvvəl testləri və qurğunu işə salmalıdır. Profilaktikanın əsas üsulları bir neçə səviyyəyə bölünür.

• Pre-commit hooklar — commit yaradılmamışdan əvvəl avtomatik yoxlamalar, o cümlədən linterlər və formatterlər
• Lokal qurğu — xüsusilə statik tipli dillər üçün pushdan əvvəl kompilyasiyanı işə salmaq
• Vahid testlər — reqressiyaların erkən aşkarlanması üçün əsas modulları testlərlə əhatə etmək
• Code review — dəyişikliklərin əsas brança merg edilməzdən əvvəl həmkar tərəfindən yoxlanılması

İkinci səviyyə — CI/CD pipeline-nin konfiqurasiyası. Hər bir Pull Request mergdən əvvəl avtomatik qurğu və testdən keçməlidir. Əgər qurğu uğursuz olarsa, PR düzəlişə qədər bloklanır. Bu yanaşma gated commit adlanır və müasir layihələrin əksəriyyətində istifadə olunur.

Üçüncü səviyyə — monitorinq və statistika. Komandalar qurğunun bərpa müddəti metrikasını — MTTR (Mean Time To Repair) izləyirlər. Bu göstərici nə qədər aşağı olarsa, komanda pozulmuş buildə bir o qədər tez reaksiya verir. Hədəf dəyər — 30 dəqiqədən çox olmamalıdır.

Build pozulubsa nə etməli

Build pozulduqda, ilk addım — proqramçılardan hansının sonuncu dəyişikliklər etdiyini müəyyən etməkdir. Git git bisect alətini təqdim edir ki, bu da qurğunu pozan commiti ikili aştar vasitəsilə tapmağa imkan verir.

# Məlum yaxşı və pis commitlər bisectə başla
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git ortadakı commiti yoxlayır
# Qur və test et, sonra qeyd et:
git bisect good  # if build passes
git bisect bad   # if build fails

# Təxminən log2(n) addımdan sonra git günahkarı göstərir
git bisect reset

Problemli commit aşkar edildikdən sonra iki variant mümkündür. Birincisi — düzəliş vaxt tələb edirsə, dəyişiklikləri git revert vasitəsilə geri qaytarmaq. Bu, xüsusilə build bütün komandanı blokladıqda ən təhlükəsiz yanaşmadır.

İkinci variant — yeni commit ilə təcili düzəliş. Bu yanaşma problem lokal və aydın olduqda üstünlük təşkil edir. Düzəlişdən sonra dəyişikliklər push edilməli və buildin uğurla keçdiyinə əmin olunmalıdır. Hər halda qurğunun bərpa müddəti bir saatdan çox olmamalıdır.