Trunk-Based Development — ce este, principii și lucrul într-o singură ramură

Ce este Trunk-Based Development?

Trunk-Based Development (TBD) — metodologia de gestionare a versiunilor în care toți dezvoltatorii își integrează modificările într-o singură ramură principală (trunk, main sau master) de mai multe ori pe zi. Spre deosebire de Git Flow cu ramurile sale feature de lungă durată, TBD minimizează durata de viață a ramurilor la câteva ore, mai rar la 1–2 zile. Scopul principal este evitarea „iadului îmbinării" (merge hell), când o funcție mare este îmbinată cu trunk după săptămâni de dezvoltare.

Conform Google Cloud DevOps, 2024, Trunk-Based Development este una dintre practicile cheie ale echipelor DevOps de înaltă performanță. Cercetarea State of DevOps Report (Puppet, 2023) a arătat că echipele care utilizează TBD se recuperează cu 30% mai rapid după defecțiuni și întâmpină cu 50% mai rar defecte critice în producție. TBD este obligatoriu pentru Continuous Deployment.

Trunk-Based Development nu înseamnă că dezvoltatorii fac commit direct în trunk fără verificare. În TBD se folosesc ramuri feature de scurtă durată care, după crearea MR și o revizuire rapidă a codului (în câteva ore), sunt îmbinate în trunk. Dacă revizuirea durează mai mult de o zi — înseamnă că funcția trebuie descompusă în părți mai mici.

State of DevOps Report: date despre TBD

Raportul anual State of DevOps Report (Puppet/DORA) urmărește practicile echipelor de înaltă performanță. Din 2015, TBD se află în top 3 practici corelate cu frecvența ridicată de livrare (deploy frequency) și timpul scăzut de recuperare (MTTR). Echipele care practică TBD implementează codul de 2–3 ori mai des și se recuperează după defecțiuni cu 30% mai rapid (DORA, 2023).

Feature Toggles: gestionarea codului nefinalizat fără ramuri

Feature Toggles (fanioane de funcții, feature flags) — mecanism de activare și dezactivare a funcționalității fără modificarea codului. În TBD, feature toggles înlocuiesc ramurile feature: dezvoltatorul face commit la codul nefinalizat în trunk, dar îl ascunde în spatele unui fanion condițional. Când funcția este gata de afișare, fanionul este comutat în configurație fără o nouă implementare.

Conform Martin Fowler, 2024, feature toggles se împart în patru tipuri: release toggles (gestionarea vizibilității funcției), experiment toggles (testare A/B), ops toggles (gestionarea parametrilor operaționali) și permission toggles (acces pe bază de roluri). În proiectele mobile, release toggles sunt deosebit de utile: noua funcționalitate este ascunsă până la data lansării, dar codul este deja în trunk și trece prin CI/CD.

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

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

// Utilizare în cod
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD în Trunk-Based Development: practici obligatorii

Continuous Integration (CI) — cea mai importantă componentă a TBD. Fiecare push în trunk (sau în ramura temporară înainte de MR) pornește un pipeline complet: construire, teste unitare, teste de integrare, lintre, analiză statică, verificare a acoperirii codului. Dacă cel puțin o etapă eșuează — autorul modificărilor repară codul înainte de următorul commit. „Trunk stricat — dezvoltare oprită" este regula principală a TBD.

Conform Jez Humble, Continuous Delivery, 2024, Trunk-Based Development necesită un pipeline CI care se execută în 10–15 minute. Dacă construirea durează mai mult — dezvoltatorii fac commit mai rar, ceea ce distruge sensul TBD. În proiectele mobile Android și iOS, construirea poate dura 20–30 de minute, ceea ce face TBD mai puțin convenabil. În astfel de cazuri, echipele folosesc Short-Lived Feature Branches (ramuri de 1 zi) cu CI imediat.

# GitHub Actions pentru TBD (Android)
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

Ramuri de scurtă durată: reguli de lucru în TBD

Ramurile de scurtă durată (short-lived branches) — compromis între TBD pur (commituri directe în trunk) și Git Flow. Ramura trăiește cel mult 1–2 zile, conține modificări de 1–3 commituri și după revizuire (nu mai mult de 4 ore de așteptare) este îmbinată în trunk. Dacă funcția necesită mai mult timp — este împărțită în subsarcini, fiecare cu propria ramură de scurtă durată.

Conform TBD Documentation, 2024, regulile ramurilor de scurtă durată: ramura este creată dintr-un trunk proaspăt (nu mai vechi de 1 oră), nu se sincronizează cu trunk prin merge/rebase (dacă au trecut mai mult de 4 ore — se creează o ramură nouă), MR/PR se creează imediat după primul commit (chiar dacă lucrul nu este finalizat — ca Draft).

Pre-tested commits: commituri cu garanție

Pentru Trunk-Based Development este importantă tehnica pre-tested commits: dezvoltatorul înainte de commit pornește pipeline-ul CI în ramura sa și doar după statusul verde commitul ajunge în trunk. În GitLab aceasta se implementează prin Merge Request pipelines cu opțiunea „Merge when pipeline succeeds". În GitHub — prin branch protection rules cu Required status checks. Aceasta garantează că trunk nu conține niciodată cod stricat.

• 1–2 zile — durata maximă de viață a short-lived branch
• 1–3 commituri — dimensiunea optimă a modificărilor
• 4 ore — timpul maxim de așteptare pentru revizuirea codului
• Creează MR imediat după primul commit, chiar și în status Draft

Branch by Abstraction: înlocuirea codului fără ramificare

Branch by Abstraction — tehnică ce permite înlocuirea sau modificarea semnificativă a unei părți a sistemului fără a crea o ramură feature de lungă durată. În loc de ramificare în Git, dezvoltatorul creează o abstracție (interfață) sub care funcționează atât implementarea veche, cât și cea nouă. Treptat, toți consumatorii sunt trecuți pe noua implementare, după care cea veche este ștearsă.

Conform Branch by Abstraction, 2024, etapele Branch by Abstraction: 1) creați o abstracție pentru componentul înlocuit, 2) implementați noua versiune sub abstracție, 3) treceți consumatorii pe noua implementare prin configurare, 4) ștergeți implementarea veche. Toți pașii sunt comiți în trunk în porțiuni mici, niciuna dintre ele nederanjând CI/CD.

TBD vs Git Flow: compararea abordărilor

Trunk-Based Development și Git Flow — două abordări opuse ale gestionării ramurilor. Git Flow folosește ramuri de lungă durată și o ierarhie strictă, TBD — o singură ramură și cicluri scurte de integrare. Alegerea între ele depinde de dimensiunea echipei, frecvența lansărilor și nivelul de automatizare CI/CD.

Erori tipice la implementarea Trunk-Based Development

Erorile TBD sunt cel mai adesea legate de CI/CD insuficient sau de disciplina slabă a commiturilor. Prima eroare — implementarea TBD fără CI, care se strică la primul commit eșuat. Dacă trunk nu poate fi reparat în 15 minute — echipa pierde încrederea în proces și revine la ramurile lungi. A doua — permiterea ramurilor de lungă durată „exclusiv pentru această funcție", ceea ce distruge întregul concept.

Conform Paul Hammant, 2023, a treia eroare — modularitatea slabă a codului. Trunk-Based Development necesită ca codul să fie împărțit în module independente. Dacă o modificare într-o clasă strică trei alte module — dezvoltatorii nu pot face commit în porțiuni mici. A patra — ignorarea feature toggles: încercarea de a comite cod nefinalizat fără fanion duce la stricarea trunk pentru întreaga echipă.

Trunk-Based Development în dezvoltarea mobilă

Trunk-Based Development în proiectele mobile are particularități din cauza duratei lungi de construire (20–30 de minute pentru Android și iOS) și a cerințelor stricte de calitate. Google și Spotify folosesc TBD în dezvoltarea mobilă, aplicând short-lived branches cu trecerea obligatorie a CI înainte de merge. Feature toggles sunt gestionate prin Firebase Remote Config sau LaunchDarkly.

Conform LaunchDarkly Docs, 2024, în dezvoltarea mobilă TBD oferă un avantaj: funcțiile sunt testate în trunk împreună cu restul codului până la data lansării, ceea ce reduce riscul problemelor de integrare. Dacă pipeline-ul CI durează mai mult de 15 minute — sunt optime short-lived branches de 1 zi cu CI automat la fiecare push. Pentru Apple App Store și Google Play, TBD necesită configurarea staged rollouts prin feature toggles.

Feature Flags ca serviciu: LaunchDarkly și Firebase

Pentru gestionarea feature toggles în TBD se folosesc platforme: LaunchDarkly (enterprise, funcționalitate completă), Firebase Remote Config (gratuit pentru proiecte mici), Split.io (open-source). Acestea oferă: activarea țintită a funcțiilor după procentul de utilizatori, testare A/B, monitorizarea utilizării și dezactivarea automată la erori. În proiectele mobile, Firebase Remote Config este cea mai populară alegere datorită integrării cu Firebase și a pragului gratuit de până la 1000 de utilizatori.