Trunk-Based Development — bu nədir, prinsipləri və bir budaqda iş

Trunk-Based Development nədir?

Trunk-Based Development (TBD) — bütün tərtibatçıların dəyişikliklərini gündə bir neçə dəfə tək bir əsas budaqda (trunk, main və ya master) birləşdirdiyi versiya idarəetmə metodologiyasıdır. Uzunömürlü feature-budaqları olan Git Flow-dan fərqli olaraq, TBD budaqların ömrünü bir neçə saata, nadir hallarda 1–2 günə qədər azaldır. Əsas məqsəd — böyük funksiya həftələrlə inkişafdan sonra trunk-a birləşdirildikdə yaranan „merge cəhənnəmi"ndən (merge hell) qaçmaqdır.

Google Cloud DevOps, 2024 məlumatlarına görə, Trunk-Based Development yüksək məhsuldar DevOps komandalarının əsas təcrübələrindən biridir. State of DevOps Report (Puppet, 2023) tədqiqatı göstərdi ki, TBD istifadə edən komandalar nasazlıqlardan 30% daha sürətli bərpa olunur və istehsalatda kritik defektlərlə 50% daha az qarşılaşır. TBD Continuous Deployment üçün məcburidir.

Trunk-Based Development tərtibatçıların yoxlamadan birbaşa trunk-a commit etməsi demək deyil. TBD-də qısaömürlü feature-budaqları istifadə olunur, onlar MR yaradıldıqdan və sürətli kod nəzərdən keçirməsindən (bir neçə saat ərzində) sonra trunk-a birləşdirilir. Əgər nəzərdən keçirmə bir gündən çox çəkirsə — bu, funksiyanın daha kiçik hissələrə bölünməsi lazım olduğunu göstərir.

State of DevOps Report: TBD haqqında məlumatlar

İllik State of DevOps Report (Puppet/DORA) yüksək məhsuldar komandaların təcrübələrini izləyir. 2015-ci ildən bəri TBD yüksək çatdırılma tezliyi (deploy frequency) və aşağı bərpa müddəti (MTTR) ilə korrelyasiya edən ilk 3 təcrübəyə daxildir. TBD tətbiq edən komandalar kodu 2–3 dəfə daha tez-tez yerləşdirir və nasazlıqlardan 30% daha sürətli bərpa olunur (DORA, 2023).

Feature Toggles: budaqsız hazır olmayan kodun idarə edilməsi

Feature Toggles (funksiya bayraqları, feature flags) — kodu dəyişmədən funksionallığı aktivləşdirmək və söndürmək mexanizmidir. TBD-də feature toggles feature-budaqlarını əvəz edir: tərtibatçı hazır olmayan kodu trunk-a commit edir, lakin onu şərti bayraq altında gizlədir. Funksiya göstərməyə hazır olduqda, bayraq yenidən yerləşdirmədən konfiqurasiyada dəyişdirilir.

Martin Fowler, 2024 məlumatlarına görə, feature toggles dörd növə bölünür: release toggles (funksiyanın görünməsinin idarə edilməsi), experiment toggles (A/B testləri), ops toggles (əməliyyat parametrlərinin idarə edilməsi) və permission toggles (rollar üzrə giriş). Mobil layihələrdə release toggles xüsusilə faydalıdır: yeni funksionallıq buraxılış tarixinə qədər gizlədilir, lakin kod artıq trunk-dadır və CI/CD-dən keçir.

// Android-də Kotlin-də Feature Toggle
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

    fun isEnabled(key: String): Boolean {
        return remoteConfig.getBoolean(key)
    }
}

// Kodda istifadə
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

Trunk-Based Development-də CI/CD: məcburi təcrübələr

Continuous Integration (CI) — TBD-nin ən vacib komponentidir. Trunk-a (və ya MR-dən əvvəl müvəqqəti budağa) hər push tam pipeline işə salır: qurulum, vahid testləri, inteqrasiya testləri, linterlər, statik analiz, kod əhatəsinin yoxlanılması. Əgər heç olmasa bir mərhələ uğursuz olarsa — dəyişiklik müəllifi növbəti commitə qədər kodu düzəldir. „Sıradan çıxmış trunk — dayandırılmış inkişaf" TBD-nin əsas qaydasıdır.

Jez Humble, Continuous Delivery, 2024 məlumatlarına görə, Trunk-Based Development 10–15 dəqiqəyə yerinə yetirilən CI pipeline tələb edir. Əgər qurulum daha uzun çəkirsə — tərtibatçılar daha az commit edir, bu da TBD-nin mənasını itirir. Android və iOS mobil layihələrində qurulum 20–30 dəqiqə çəkə bilər ki, bu da TBD-ni daha az rahat edir. Belə hallarda komandalar dərhal CI ilə Short-Lived Feature Branches (1 günlük budaqlar) istifadə edir.

# TBD (Android) üçün GitHub Actions
name: CI - TBD Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew testDebugUnitTest
      - name: Static analysis
        run: ./gradlew ktlintCheck detekt

Qısaömürlü budaqlar: TBD-də iş qaydaları

Qısaömürlü budaqlar (short-lived branches) — təmiz TBD (birbaşa trunk-a commitlər) və Git Flow arasında kompromisdir. Budaq 1–2 gündən çox yaşamır, 1–3 commit üçün dəyişiklikləri ehtiva edir və nəzərdən keçirmədən sonra (4 saatdan çox olmayan gözləmə) trunk-a birləşdirilir. Əgər funksiya daha çox vaxt tələb edirsə — o, hər biri öz qısaömürlü budağına sahib olan alt tapşırıqlara bölünür.

TBD Documentation, 2024 məlumatlarına görə, qısaömürlü budaqların qaydaları: budaq təzə trunk-dan yaradılır (1 saatdan köhnə olmayan), merge/rebase vasitəsilə trunk ilə sinxronlaşdırılmır (4 saatdan çox keçibsə — yeni budaq yaradılır), MR/PR ilk commitdən dərhal sonra yaradılır (iş tamamlanmasa belə — Draft kimi).

Pre-tested commits: zəmanətli commitlər

Trunk-Based Development üçün pre-tested commits texnikası vacibdir: tərtibatçı commitdən əvvəl öz budağında CI pipeline işə salır və yalnız yaşıl statusdan sonra commit trunk-a daxil olur. GitLab-da bu, „Merge when pipeline succeeds" seçimi ilə Merge Request pipelines vasitəsilə həyata keçirilir. GitHub-da — Required status checks ilə branch protection rules vasitəsilə. Bu, trunk-ın heç vaxt sıradan çıxmış kod ehtiva etməməsinə zəmanət verir.

• 1–2 gün — short-lived branch üçün maksimum yaşama müddəti
• 1–3 commit — optimal dəyişiklik ölçüsü
• 4 saat — kod nəzərdən keçirməsi üçün maksimum gözləmə müddəti
• MR yaradın ilk commitdən dərhal sonra, hətta Draft statusunda

Branch by Abstraction: budaqlanmadan kodun dəyişdirilməsi

Branch by Abstraction — uzunömürlü feature-budağı yaratmadan sistemin bir hissəsini əvəz etməyə və ya əhəmiyyətli dərəcədə dəyişdirməyə imkan verən texnikadır. Git-də budaqlanma əvəzinə tərtibatçı həm köhnə, həm də yeni implementasiyanın işlədiyi abstraksiya (interfeys) yaradır. Tədricən bütün istehlakçılar yeni implementasiyaya keçirilir, sonra köhnəsi silinir.

Branch by Abstraction, 2024 məlumatlarına görə, Branch by Abstraction mərhələləri: 1) əvəz edilən komponent üçün abstraksiya yaradın, 2) abstraksiya altında yeni versiyanı tətbiq edin, 3) istehlakçıları konfiqurasiya vasitəsilə yeni implementasiyaya keçirin, 4) köhnə implementasiyanı silin. Bütün addımlar trunk-a kiçik hissələrlə commit edilir, heç biri CI/CD-ni pozmur.

TBD vs Git Flow: yanaşmaların müqayisəsi

Trunk-Based Development və Git Flow — budaqların idarə edilməsinə iki əks yanaşmadır. Git Flow uzunömürlü budaqlar və ciddi iyerarxiyadan istifadə edir, TBD — bir budaq və qısa inteqrasiya dövrləri. Aralarında seçim komanda ölçüsündən, buraxılış tezliyindən və CI/CD avtomatlaşdırma səviyyəsindən asılıdır.

Trunk-Based Development tətbiqində tipik səhvlər

TBD səhvləri ən çox kifayət qədər CI/CD olmaması və ya zəif commit intizamı ilə bağlıdır. Birinci səhv — CI olmadan TBD tətbiqi, ilk uğursuz commitdə sıradan çıxır. Əgər trunk 15 dəqiqə ərzində düzəldilə bilmirsə — komanda prosesə inamını itirir və uzun budaqlara qayıdır. İkinci — „yalnız bu funksiya üçün" uzunömürlü budaqlara icazə vermək, bütün konsepsiyanı məhv edir.

Paul Hammant, 2023 məlumatlarına görə, üçüncü səhv — kodun zəif modulluğudur. Trunk-Based Development kodun müstəqil modullara bölünməsini tələb edir. Əgər bir sinifdə dəyişiklik üç digər modulu sıradan çıxarırsa — tərtibatçılar kiçik hissələrlə commit edə bilməz. Dördüncü — feature toggles-a məhəl qoymamaq: bayraq olmadan hazır olmayan kodu commit etmək cəhdi bütün komanda üçün trunk-ı sıradan çıxarır.

Mobil inkişafda Trunk-Based Development

Trunk-Based Development mobil layihələrdə uzun qurulum müddəti (Android və iOS üçün 20–30 dəqiqə) və ciddi keyfiyyət tələbləri səbəbindən xüsusiyyətlərə malikdir. Google və Spotify mobil inkişafda TBD istifadə edir, merge-dən əvvəl CI-nin məcburi keçidi ilə short-lived branches tətbiq edir. Feature toggles Firebase Remote Config və ya LaunchDarkly vasitəsilə idarə olunur.

LaunchDarkly Docs, 2024 məlumatlarına görə, mobil inkişafda TBD üstünlük verir: funksiyalar buraxılış tarixinə qədər trunk-da qalan kodla birlikdə sınaqdan keçirilir, bu da inteqrasiya problemləri riskini azaldır. Əgər CI pipeline 15 dəqiqədən çox çəkirsə — hər pushda avtomatik CI ilə 1 günlük short-lived branches optimaldır. Apple App Store və Google Play üçün TBD feature toggles vasitəsilə staged rollouts qurulmasını tələb edir.

Feature Flags xidmət kimi: LaunchDarkly və Firebase

TBD-də feature toggles idarə edilməsi üçün platformalardan istifadə olunur: LaunchDarkly (enterprise, tam funksionallıq), Firebase Remote Config (kiçik layihələr üçün pulsuz), Split.io (open-source). Onlar təmin edir: istifadəçi faizinə görə funksiyaların hədəflənmiş aktivləşdirilməsi, A/B testləri, istifadə monitorinqi və səhvlər zamanı avtomatik söndürmə. Mobil layihələrdə Firebase Remote Config Firebase ilə inteqrasiya və 1000 istifadəçiyə qədər pulsuz hədd səbəbindən ən populyar seçimdir.