Trunk-Based Development — mi ez, elvek és munka egy ágban

Mi az a Trunk-Based Development?

Trunk-Based Development (TBD) — verziókezelési módszertan, amelyben minden fejlesztő naponta többször integrálja a változtatásait egyetlen fő ágba (trunk, main vagy master). Ellentétben a Git Flow-val és annak hosszú élettartamú feature-ágaival, a TBD minimálisra csökkenti az ágak élettartamát néhány órára, ritkán 1–2 napra. A fő cél az „egyesítés poklának" (merge hell) elkerülése, amikor egy nagy funkció hetekig tartó fejlesztés után kerül a trunk-ba.

A Google Cloud DevOps, 2024 szerint a Trunk-Based Development a magas teljesítményű DevOps csapatok egyik kulcsgyakorlata. A State of DevOps Report (Puppet, 2023) kutatása kimutatta, hogy a TBD-t használó csapatok 30%-kal gyorsabban állnak helyre a hibákból és 50%-kal ritkábban találkoznak kritikus hibákkal éles környezetben. A TBD kötelező a Continuous Deployment-hez.

Trunk-Based Development nem jelenti azt, hogy a fejlesztők ellenőrzés nélkül közvetlenül a trunk-ba commitolnak. A TBD-ben rövid élettartamú feature-ágakat használnak, amelyek az MR létrehozása és gyors kódreview (néhány órán belül) után kerülnek a trunk-ba. Ha a review több mint egy napig tart — ez azt jelenti, hogy a funkciót kisebb részekre kell bontani.

State of DevOps Report: adatok a TBD-ről

Az éves State of DevOps Report (Puppet/DORA) nyomon követi a magas teljesítményű csapatok gyakorlatait. 2015 óta a TBD a top 3 gyakorlat között van, amelyek korrelálnak a magas szállítási gyakorisággal (deploy frequency) és az alacsony helyreállítási idővel (MTTR). A TBD-t alkalmazó csapatok 2–3-szor gyakrabban telepítenek kódot és 30%-kal gyorsabban állnak helyre a hibákból (DORA, 2023).

Feature Toggles: befejezetlen kód kezelése ágak nélkül

Feature Toggles (funkciókapcsolók, feature flags) — a funkciók be- és kikapcsolásának mechanizmusa a kód megváltoztatása nélkül. A TBD-ben a feature toggles helyettesíti a feature-ágakat: a fejlesztő a befejezetlen kódot a trunk-ba commitolja, de egy feltételes kapcsoló mögé rejti. Amikor a funkció készen áll a megjelenítésre, a kapcsolót a konfigurációban átbillentik újratelepítés nélkül.

A Martin Fowler, 2024 szerint a feature toggles négy típusra osztható: release toggles (a funkció láthatóságának kezelése), experiment toggles (A/B tesztelés), ops toggles (műveleti paraméterek kezelése) és permission toggles (hozzáférés szerepkörök alapján). Mobil projektekben a release toggles különösen hasznos: az új funkció a kiadás dátumáig rejtve marad, de a kód már a trunk-ban van és átmegy a CI/CD-n.

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

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

// Használat a kódban
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD a Trunk-Based Development-ben: kötelező gyakorlatok

Continuous Integration (CI) — a TBD legfontosabb összetevője. Minden push a trunk-ba (vagy az MR előtti ideiglenes ágba) elindít egy teljes pipeline-t: build, egységtesztek, integrációs tesztek, linterek, statikus elemzés, kódlefedettség ellenőrzése. Ha legalább egy szakasz meghiúsul — a változtatás szerzője kijavítja a kódot a következő commit előtt. „Eltört trunk — megállt fejlesztés" a TBD fő szabálya.

A Jez Humble, Continuous Delivery, 2024 szerint a Trunk-Based Development olyan CI pipeline-t igényel, amely 10–15 perc alatt fut le. Ha a build tovább tart — a fejlesztők ritkábban commitolnak, ami tönkreteszi a TBD értelmét. Android és iOS mobil projektekben a build 20–30 percig is tarthat, ami kevésbé kényelmessé teszi a TBD-t. Ilyen esetekben a csapatok Short-Lived Feature Branches-t (1 napos ágakat) használnak azonnali CI-vel.

# GitHub Actions TBD-hez (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

Rövid élettartamú ágak: munkaszabályok a TBD-ben

Rövid élettartamú ágak (short-lived branches) — kompromisszum a tiszta TBD (közvetlen commitok a trunk-ba) és a Git Flow között. Az ág legfeljebb 1–2 napig él, 1–3 commit változtatást tartalmaz, és a review után (legfeljebb 4 óra várakozás) a trunk-ba kerül. Ha a funkció több időt igényel — alegységekre bontják, mindegyik saját rövid élettartamú ággal.

A TBD Documentation, 2024 szerint a rövid élettartamú ágak szabályai: az ágat friss trunk-ból hozzák létre (legfeljebb 1 órás), nem szinkronizálják a trunk-kal merge/rebase útján (ha több mint 4 óra telt el — új ágat hoznak létre), az MR/PR-t az első commit után azonnal létrehozzák (még ha a munka nem is fejeződött be — Draftként).

Pre-tested commits: commitok garanciával

A Trunk-Based Development esetében fontos a pre-tested commits technika: a fejlesztő a commit előtt elindítja a CI pipeline-t a saját ágában, és csak zöld státusz után kerül a commit a trunk-ba. GitLab-ban ez Merge Request pipeline-okkal valósítható meg a „Merge when pipeline succeeds" opcióval. GitHub-ban — branch protection rules segítségével Required status checks beállításokkal. Ez garantálja, hogy a trunk soha nem tartalmaz eltört kódot.

• 1–2 nap — a short-lived branch maximális élettartama
• 1–3 commit — a változtatások optimális mérete
• 4 óra — maximális várakozási idő a kódreview-ra
• Hozz létre MR-t az első commit után azonnal, akár Draft státuszban is

Branch by Abstraction: kód csere elágazás nélkül

Branch by Abstraction — olyan technika, amely lehetővé teszi a rendszer egy részének cseréjét vagy jelentős módosítását hosszú élettartamú feature-ág létrehozása nélkül. A Git-beli elágazás helyett a fejlesztő létrehoz egy absztrakciót (interfészt), amely alatt mind a régi, mind az új megvalósítás működik. Fokozatosan az összes fogyasztót áthelyezik az új megvalósításra, majd a régit törlik.

A Branch by Abstraction, 2024 szerint a Branch by Abstraction lépései: 1) hozz létre absztrakciót a cserélendő komponenshez, 2) implementáld az új verziót az absztrakció alatt, 3) helyezd át a fogyasztókat az új megvalósításra konfiguráción keresztül, 4) távolítsd el a régi megvalósítást. Minden lépést kis adagokban commitolnak a trunk-ba, amelyek egyike sem töri el a CI/CD-t.

TBD vs Git Flow: megközelítések összehasonlítása

Trunk-Based Development és Git Flow — két ellentétes megközelítés az ágak kezelésére. A Git Flow hosszú élettartamú ágakat és szigorú hierarchiát használ, a TBD — egy ágat és rövid integrációs ciklusokat. A köztük való választás a csapat méretétől, a kiadások gyakoriságától és a CI/CD automatizálás szintjétől függ.

Tipikus hibák a Trunk-Based Development bevezetésekor

TBD-hibák leggyakrabban az elégtelen CI/CD-vel vagy gyenge commit-fegyelemmel kapcsolatosak. Az első hiba — a TBD bevezetése CI nélkül, ami az első sikertelen commitnál eltörik. Ha a trunk 15 percen belül nem javítható — a csapat elveszti a bizalmát a folyamatban és visszatér a hosszú ágakhoz. A második — hosszú élettartamú ágak engedélyezése „kizárólag ehhez a funkcióhoz", ami tönkreteszi az egész koncepciót.

A Paul Hammant, 2023 szerint a harmadik hiba — a kód gyenge modularitása. Trunk-Based Development megköveteli, hogy a kód független modulokra legyen bontva. Ha egy osztályban történt változtatás három másik modult elront — a fejlesztők nem tudnak kis adagokban commitolni. Negyedik — a feature toggles figyelmen kívül hagyása: a befejezetlen kód kapcsoló nélküli commitolásának kísérlete az egész csapat számára elrontja a trunk-ot.

Trunk-Based Development a mobilfejlesztésben

Trunk-Based Development a mobil projektekben sajátosságokkal rendelkezik a hosszú build-idő (20–30 perc Android és iOS esetén) és a szigorú minőségi követelmények miatt. A Google és a Spotify TBD-t használ a mobilfejlesztésben, short-lived branches alkalmazásával, kötelező CI-áthaladással a merge előtt. A feature toggles kezelése Firebase Remote Config vagy LaunchDarkly segítségével történik.

A LaunchDarkly Docs, 2024 szerint a mobilfejlesztésben a TBD előnyt jelent: a funkciókat a trunk-ban tesztelik a többi kóddal együtt a kiadás dátuma előtt, ami csökkenti az integrációs problémák kockázatát. Ha a CI pipeline több mint 15 percig tart — az 1 napos short-lived branches automatikus CI-vel minden push-nál optimális. Az Apple App Store és Google Play esetében a TBD megköveteli a staged rollouts beállítását feature toggles segítségével.

Feature Flags szolgáltatásként: LaunchDarkly és Firebase

A feature toggles kezeléséhez a TBD-ben platformokat használnak: LaunchDarkly (enterprise, teljes funkcionalitás), Firebase Remote Config (ingyenes kis projektekhez), Split.io (open-source). Ezek biztosítják: a funkciók célzott bekapcsolását a felhasználók százaléka alapján, A/B tesztelést, használat monitorozását és automatikus kikapcsolást hibák esetén. Mobil projektekben a Firebase Remote Config a legnépszerűbb választás a Firebase-el való integráció és az ingyenes 1000 felhasználós korlát miatt.