Trunk-Based Development — bu nima, tamoyillari va bitta filialda ishlash

Trunk-Based Development nima?

Trunk-Based Development (TBD) — bu barcha ishlab chiquvchilar o'z o'zgarishlarini kuniga bir necha marta yagona asosiy filialga (trunk, main yoki master) birlashtiradigan versiya boshqarish metodologiyasidir. Uzoq muddatli feature-filiallariga ega Git Flow dan farqli o'laroq, TBD filiallarning umrini bir necha soatga, kamdan-kam 1–2 kungacha kamaytiradi. Asosiy maqsad — katta funksiya haftalab rivojlanishdan so'ng trunk bilan birlashtirilganda yuzaga keladigan «merge do'zaxi»dan (merge hell) qochishdir.

Google Cloud DevOps, 2024 ma'lumotlariga ko'ra, Trunk-Based Development yuqori samaradorlikka ega DevOps jamoalarining asosiy amaliyotlaridan biridir. State of DevOps Report (Puppet, 2023) tadqiqoti shuni ko'rsatdiki, TBD dan foydalanadigan jamoalar nosozliklardan 30% tezroq tiklanadi va ishlab chiqarishda tanqidiy nuqsonlar bilan 50% kamroq duch keladi. TBD Continuous Deployment uchun majburiydir.

Trunk-Based Development ishlab chiquvchilar tekshiruvsiz to'g'ridan-to'g'ri trunk-ga commit qiladi degani emas. TBD da qisqa muddatli feature-filiallari ishlatiladi, ular MR yaratilgandan va tez kod ko'rib chiqilishidan (bir necha soat ichida) so'ng trunk-ga birlashtiriladi. Agar ko'rib chiqish bir kundan ortiq davom etsa — bu funksiyani kichikroq qismlarga bo'lish kerakligini anglatadi.

State of DevOps Report: TBD haqida ma'lumotlar

Yillik State of DevOps Report (Puppet/DORA) yuqori samaradorlikka ega jamoalarning amaliyotlarini kuzatadi. 2015 yildan beri TBD yuqori yetkazib berish chastotasi (deploy frequency) va past tiklash vaqti (MTTR) bilan bog'liq bo'lgan top 3 amaliyot ichiga kiradi. TBD ni qo'llaydigan jamoalar kodni 2–3 marta tez-tez joylashtiradi va nosozliklardan 30% tezroq tiklanadi (DORA, 2023).

Feature Toggles: filiallarsiz tayyor bo'lmagan kodni boshqarish

Feature Toggles (xususiyat bayroqlari, feature flags) — kodni o'zgartirmasdan funksionallikni yoqish va o'chirish mexanizmidir. TBD da feature toggles feature-filiallarini almashtiradi: ishlab chiquvchi tayyor bo'lmagan kodni trunk-ga commit qiladi, lekin uni shartli bayroq orqasida yashiradi. Funksiya ko'rsatishga tayyor bo'lganda, bayroq qayta joylashtirmasdan konfiguratsiyada o'zgartiriladi.

Martin Fowler, 2024 ma'lumotlariga ko'ra, feature toggles to'rt turga bo'linadi: release toggles (funksiya ko'rinishini boshqarish), experiment toggles (A/B testlari), ops toggles (operatsion parametrlarni boshqarish) va permission toggles (rollar bo'yicha kirish). Mobil loyihalarda release toggles ayniqsa foydali: yangi funksionallik chiqarish sanasigacha yashirinadi, ammo kod allaqachon trunk da va CI/CD dan o'tadi.

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

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

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

Trunk-Based Development da CI/CD: majburiy amaliyotlar

Continuous Integration (CI) — TBD ning eng muhim komponentidir. Trunk-ga (yoki MR dan oldin vaqtinchalik filialga) har bir push to'liq pipeline ni ishga tushiradi: qurilish, birlik testlari, integratsiya testlari, linterlar, statik tahlil, kod qamrovini tekshirish. Agar hech bo'lmaganda bir bosqich muvaffaqiyatsiz bo'lsa — o'zgarishlar muallifi keyingi commitdan oldin kodni tuzatadi. «Buzilgan trunk — to'xtatilgan rivojlanish» TBD ning asosiy qoidasidir.

Jez Humble, Continuous Delivery, 2024 ma'lumotlariga ko'ra, Trunk-Based Development 10–15 daqiqada bajariladigan CI pipeline ni talab qiladi. Agar qurilish uzoq davom etsa — ishlab chiquvchilar kamroq commit qiladi, bu TBD ning ma'nosini yo'qotadi. Android va iOS mobil loyihalarida qurilish 20–30 daqiqa davom etishi mumkin, bu TBD ni kamroq qulay qiladi. Bunday hollarda jamoalar zudlik bilan CI bilan Short-Lived Feature Branches (1 kunlik filiallar) dan foydalanadi.

# TBD (Android) uchun 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

Qisqa muddatli filiallar: TBD da ishlash qoidalari

Qisqa muddatli filiallar (short-lived branches) — toza TBD (to'g'ridan-to'g'ri trunk-ga commitlar) va Git Flow o'rtasidagi murosadir. Filial 1–2 kundan ortiq yashamaydi, 1–3 commit uchun o'zgarishlarni o'z ichiga oladi va ko'rib chiqishdan so'ng (4 soatdan ortiq bo'lmagan kutish) trunk-ga birlashtiriladi. Agar funksiya ko'proq vaqt talab qilsa — u har biri o'z qisqa muddatli filialiga ega bo'lgan pastki vazifalarga bo'linadi.

TBD Documentation, 2024 ma'lumotlariga ko'ra, qisqa muddatli filiallar qoidalari: filial yangi trunk dan yaratiladi (1 soatdan eski bo'lmagan), merge/rebase orqali trunk bilan sinxronlashtirilmaydi (4 soatdan ko'proq vaqt o'tgan bo'lsa — yangi filial yaratiladi), MR/PR birinchi commitdan so'ng darhol yaratiladi (ish tugallanmagan bo'lsa ham — Draft sifatida).

Pre-tested commits: kafolatlangan commitlar

Trunk-Based Development uchun pre-tested commits texnikasi muhim: ishlab chiquvchi commitdan oldin o'z filialida CI pipeline ni ishga soladi va faqat yashil statusdan so'ng commit trunk-ga tushadi. GitLab da bu «Merge when pipeline succeeds» opsiyasi bilan Merge Request pipelines orqali amalga oshiriladi. GitHub da — Required status checks bilan branch protection rules orqali. Bu trunk hech qachon buzilgan kodni o'z ichiga olmasligini kafolatlaydi.

• 1–2 kun — short-lived branch uchun maksimal yashash muddati
• 1–3 commit — optimal o'zgarish hajmi
• 4 soat — kod ko'rib chiqish uchun maksimal kutish vaqti
• MR yarating birinchi commitdan so'ng darhol, hatto Draft statusida

Branch by Abstraction: filiallanmasdan kodni almashtirish

Branch by Abstraction — uzoq muddatli feature-filialini yaratmasdan tizimning bir qismini almashtirish yoki sezilarli darajada o'zgartirish imkonini beradigan texnikadir. Git da filiallanish o'rniga ishlab chiquvchi ham eski, ham yangi implementatsiya ishlaydigan abstraksiya (interfeys) yaratadi. Asta-sekin barcha iste'molchilar yangi implementatsiyaga o'tkaziladi, keyin eskisi o'chiriladi.

Branch by Abstraction, 2024 ma'lumotlariga ko'ra, Branch by Abstraction bosqichlari: 1) almashtiriladigan komponent uchun abstraksiya yarating, 2) abstraksiya ostida yangi versiyani implementatsiya qiling, 3) iste'molchilarni konfiguratsiya orqali yangi implementatsiyaga o'tkazing, 4) eski implementatsiyani o'chiring. Barcha qadamlar trunk-ga kichik qismlarda commit qilinadi, ularning hech biri CI/CD ni buzmaydi.

TBD vs Git Flow: yondashuvlarni solishtirish

Trunk-Based Development va Git Flow — filiallarni boshqarishga ikki qarama-qarshi yondashuvdir. Git Flow uzoq muddatli filiallar va qattiq iyerarxiyadan foydalanadi, TBD — bitta filial va qisqa integratsiya sikllari. Ularning o'rtasida tanlov jamoa hajmi, chiqarish chastotasi va CI/CD avtomatlashtirish darajasiga bog'liq.

Trunk-Based Development joriy etishdagi tipik xatolar

TBD xatolari ko'pincha yetarli darajada CI/CD yo'qligi yoki zaif commit intizomi bilan bog'liq. Birinchi xato — CI siz TBD joriy etish, birinchi muvaffaqiyatsiz commitda buziladi. Agar trunk 15 daqiqada tuzatilmasa — jamoa jarayonga ishonchini yo'qotadi va uzoq filiallarga qaytadi. Ikkinchi — «faqat bu funksiya uchun» uzoq muddatli filiallarga ruxsat berish, butun kontseptsiyani yo'q qiladi.

Paul Hammant, 2023 ma'lumotlariga ko'ra, uchinchi xato — kodning zaif modulliligidir. Trunk-Based Development kodning mustaqil modullarga bo'linishini talab qiladi. Agar bitta sinfdagi o'zgarish uchta boshqa modulni buzsa — ishlab chiquvchilar kichik qismlarda commit qila olmaydi. To'rtinchi — feature toggles ni e'tiborsiz qoldirish: bayroqsiz tayyor bo'lmagan kodni commit qilish urinishi butun jamoa uchun trunk ni buzadi.

Mobil ishlab chiqishda Trunk-Based Development

Trunk-Based Development mobil loyihalarda uzoq qurilish vaqti (Android va iOS uchun 20–30 daqiqa) va qattiq sifat talablari tufayli o'ziga xos xususiyatlarga ega. Google va Spotify mobil ishlab chiqishda TBD dan foydalanadi, merge dan oldin CI dan majburiy o'tish bilan short-lived branches ni qo'llaydi. Feature toggles Firebase Remote Config yoki LaunchDarkly orqali boshqariladi.

LaunchDarkly Docs, 2024 ma'lumotlariga ko'ra, mobil ishlab chiqishda TBD ustunlik beradi: funksiyalar chiqarish sanasigacha trunk da qolgan kod bilan birga sinovdan o'tkaziladi, bu integratsiya muammolari xavfini kamaytiradi. Agar CI pipeline 15 daqiqadan ko'proq vaqt olsa — har bir push da avtomatik CI bilan 1 kunlik short-lived branches optimaldir. Apple App Store va Google Play uchun TBD feature toggles orqali staged rollouts sozlashni talab qiladi.

Feature Flags xizmat sifatida: LaunchDarkly va Firebase

TBD da feature toggles ni boshqarish uchun platformalar ishlatiladi: LaunchDarkly (enterprise, to'liq funksionallik), Firebase Remote Config (kichik loyihalar uchun bepul), Split.io (open-source). Ular ta'minlaydi: foydalanuvchi foiziga ko'ra funksiyalarni maqsadli yoqish, A/B testlari, foydalanish monitoringi va xatolar paytida avtomatik o'chirish. Mobil loyihalarda Firebase Remote Config Firebase bilan integratsiya va 1000 foydalanuvchigacha bepul chegara sababli eng mashhur tanlovdir.