Trunk-Based Development — ano ito, mga prinsipyo at pagtatrabaho sa isang branch

Ano ang Trunk-Based Development?

Trunk-Based Development (TBD) — isang pamamaraan ng pamamahala ng bersyon kung saan isinasama ng lahat ng developer ang kanilang mga pagbabago sa iisang pangunahing branch (trunk, main o master) nang ilang beses sa isang araw. Hindi tulad ng Git Flow kasama ang matagal na feature-branch nito, pinapaliit ng TBD ang habang-buhay ng branch sa ilang oras, bihira sa 1–2 araw. Ang pangunahing layunin ay iwasan ang "impyerno ng merge" (merge hell), kapag ang isang malaking feature ay pinagsama sa trunk pagkatapos ng mga linggo ng pag-develop.

Ayon sa Google Cloud DevOps, 2024, ang Trunk-Based Development ay isa sa mga pangunahing kasanayan ng mataas na pagganap na DevOps team. Ipinakita ng pananaliksik ng State of DevOps Report (Puppet, 2023) na ang mga team na gumagamit ng TBD ay 30% mas mabilis na gumagaling mula sa mga pagkabigo at 50% mas madalas na nakakaranas ng kritikal na depekto sa produksyon. Ang TBD ay sapilitan para sa Continuous Deployment.

Trunk-Based Development ay hindi nangangahulugan na ang mga developer ay direktang nagco-commit sa trunk nang walang pagpapatunay. Sa TBD, ginagamit ang mga panandaliang feature-branch na pagkatapos ng paggawa ng MR at mabilis na code review (sa loob ng ilang oras) ay pinagsama sa trunk. Kung ang review ay tumagal nang higit sa isang araw — nangangahulugan ito na ang feature ay kailangang hatiin sa mas maliliit na bahagi.

State of DevOps Report: datos tungkol sa TBD

Ang taunang State of DevOps Report (Puppet/DORA) ay sumusubaybay sa mga kasanayan ng mataas na pagganap na mga team. Mula noong 2015, ang TBD ay nasa top 3 na kasanayan na nauugnay sa mataas na dalas ng paghahatid (deploy frequency) at mababang oras ng pagbawi (MTTR). Ang mga team na nagpapatupad ng TBD ay nagde-deploy ng code 2–3 beses nang mas madalas at gumagaling mula sa mga pagkabigo nang 30% mas mabilis (DORA, 2023).

Feature Toggles: pamamahala ng hindi tapos na code nang walang branch

Feature Toggles (mga flag ng feature, feature flags) — mekanismo ng pag-activate at pag-deactivate ng functionality nang hindi binabago ang code. Sa TBD, pinapalitan ng feature toggles ang feature-branch: nagco-commit ang developer ng hindi tapos na code sa trunk ngunit itinatago ito sa likod ng isang conditional flag. Kapag handa nang ipakita ang feature, ang flag ay inililipat sa configuration nang walang muling pag-deploy.

Ayon sa Martin Fowler, 2024, ang feature toggles ay nahahati sa apat na uri: release toggles (pamamahala ng visibility ng feature), experiment toggles (A/B testing), ops toggles (pamamahala ng operational na parameter) at permission toggles (access batay sa tungkulin). Sa mga mobile project, ang release toggles ay lalong kapaki-pakinabang: ang bagong functionality ay nakatago hanggang sa petsa ng release, ngunit ang code ay nasa trunk na at dumadaan sa CI/CD.

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

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

// Paggamit sa code
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD sa Trunk-Based Development: mga sapilitang kasanayan

Continuous Integration (CI) — ang pinakamahalagang bahagi ng TBD. Bawat push sa trunk (o sa pansamantalang branch bago ang MR) ay nag-uumpisa ng kumpletong pipeline: build, unit test, integration test, linters, static analysis, pagsusuri ng code coverage. Kung kahit isang yugto ay bumagsak — inaayos ng may-akda ng pagbabago ang code bago ang susunod na commit. "Sira ang trunk — hinto ang pag-develop" ang pangunahing patakaran ng TBD.

Ayon sa Jez Humble, Continuous Delivery, 2024, ang Trunk-Based Development ay nangangailangan ng CI pipeline na naisasagawa sa 10–15 minuto. Kung mas matagal ang build — mas madalas mag-commit ang mga developer, na sumisira sa kahulugan ng TBD. Sa mga mobile project na Android at iOS, ang build ay maaaring tumagal ng 20–30 minuto, na ginagawang hindi gaanong maginhawa ang TBD. Sa ganitong mga kaso, ang mga team ay gumagamit ng Short-Lived Feature Branches (1 araw na branch) na may agarang CI.

# GitHub Actions para sa 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

Mga panandaliang branch: mga patakaran ng trabaho sa TBD

Mga panandaliang branch (short-lived branches) — kompromiso sa pagitan ng purong TBD (direktang commit sa trunk) at Git Flow. Ang branch ay nabubuhay nang hindi hihigit sa 1–2 araw, naglalaman ng mga pagbabago para sa 1–3 commit at pagkatapos ng review (hindi hihigit sa 4 na oras na paghihintay) ay pinagsama sa trunk. Kung ang feature ay nangangailangan ng mas maraming oras — ito ay hinahati sa mga subtask, bawat isa ay may sariling panandaliang branch.

Ayon sa TBD Documentation, 2024, mga patakaran ng panandaliang branch: ang branch ay ginawa mula sa sariwang trunk (hindi luma sa 1 oras), hindi naka-sync sa trunk sa pamamagitan ng merge/rebase (kung higit sa 4 na oras ang lumipas — gumawa ng bagong branch), ang MR/PR ay ginawa kaagad pagkatapos ng unang commit (kahit hindi pa tapos ang trabaho — bilang Draft).

Pre-tested commits: mga commit na may garantiya

Para sa Trunk-Based Development mahalaga ang pamamaraan ng pre-tested commits: ang developer bago mag-commit ay nagpapatakbo ng CI pipeline sa kanyang sariling branch, at pagkatapos lamang ng berdeng status ang commit ay papasok sa trunk. Sa GitLab ito ay naisasagawa sa pamamagitan ng Merge Request pipelines na may opsyon na "Merge when pipeline succeeds". Sa GitHub — sa pamamagitan ng branch protection rules na may Required status checks. Ginagarantiyahan nito na ang trunk ay hindi kailanman naglalaman ng sirang code.

• 1–2 araw — maximum na habang-buhay ng short-lived branch
• 1–3 commit — pinakamainam na sukat ng mga pagbabago
• 4 na oras — maximum na oras ng paghihintay para sa code review
• Gumawa ng MR kaagad pagkatapos ng unang commit, kahit sa Draft status

Branch by Abstraction: pagpapalit ng code nang walang pagsasanga

Branch by Abstraction — pamamaraan na nagpapahintulot na palitan o baguhin nang malaki ang isang bahagi ng system nang hindi gumagawa ng matagal na feature-branch. Sa halip na sumanga sa Git, gumawa ang developer ng abstraction (interface) kung saan gumagana ang luma at bagong implementasyon. Unti-unti, lahat ng consumer ay inililipat sa bagong implementasyon, pagkatapos ay tinatanggal ang luma.

Ayon sa Branch by Abstraction, 2024, mga yugto ng Branch by Abstraction: 1) gumawa ng abstraction para sa bahaging papalitan, 2) i-implement ang bagong bersyon sa ilalim ng abstraction, 3) ilipat ang mga consumer sa bagong implementasyon sa pamamagitan ng configuration, 4) tanggalin ang lumang implementasyon. Lahat ng hakbang ay naka-commit sa trunk sa maliliit na bahagi, wala sa mga ito ang sumisira sa CI/CD.

TBD vs Git Flow: paghahambing ng mga pamamaraan

Trunk-Based Development at Git Flow — dalawang magkasalungat na pamamaraan ng pamamahala ng branch. Ang Git Flow ay gumagamit ng matagal na branch at mahigpit na hierarchy, ang TBD — isang branch at maikling cycle ng integrasyon. Ang pagpili sa pagitan ng mga ito ay depende sa laki ng team, dalas ng release at antas ng CI/CD automation.

Mga karaniwang pagkakamali sa pagpapatupad ng Trunk-Based Development

Mga pagkakamali sa TBD ay kadalasang nauugnay sa hindi sapat na CI/CD o mahinang disiplina sa commit. Ang unang pagkakamali — pagpapatupad ng TBD nang walang CI, na nasisira sa unang hindi matagumpay na commit. Kung ang trunk ay hindi maaaring ayusin sa loob ng 15 minuto — nawawalan ng tiwala ang team sa proseso at bumabalik sa mahabang branch. Pangalawa — pagpayag sa matagal na branch "eksklusibo para sa feature na ito", na sumisira sa buong konsepto.

Ayon sa Paul Hammant, 2023, ang pangatlong pagkakamali — mahinang modularity ng code. Trunk-Based Development ay nangangailangan na ang code ay nahahati sa mga independiyenteng module. Kung ang pagbabago sa isang klase ay sumisira sa tatlong iba pang module — hindi makakapag-commit ang mga developer sa maliliit na bahagi. Pang-apat — pagbalewala sa feature toggles: ang pagtatangkang mag-commit ng hindi tapos na code nang walang flag ay humahantong sa pagkasira ng trunk para sa buong team.

Trunk-Based Development sa mobile development

Trunk-Based Development sa mga mobile project ay may mga partikularidad dahil sa mahabang oras ng build (20–30 minuto para sa Android at iOS) at mahigpit na mga kinakailangan sa kalidad. Ang Google at Spotify ay gumagamit ng TBD sa mobile development, na naglalapat ng short-lived branches na may sapilitang pagpasa ng CI bago ang merge. Ang feature toggles ay pinamamahalaan sa pamamagitan ng Firebase Remote Config o LaunchDarkly.

Ayon sa LaunchDarkly Docs, 2024, sa mobile development ay nagbibigay ng kalamangan ang TBD: ang mga feature ay sinusubok sa trunk kasama ng natitirang code bago ang petsa ng release, na nagbabawas ng panganib ng mga problema sa integrasyon. Kung ang CI pipeline ay tumatagal ng higit sa 15 minuto — ang short-lived branches ng 1 araw na may awtomatikong CI sa bawat push ay pinakamainam. Para sa Apple App Store at Google Play, ang TBD ay nangangailangan ng pag-configure ng staged rollouts sa pamamagitan ng feature toggles.

Feature Flags bilang serbisyo: LaunchDarkly at Firebase

Para sa pamamahala ng feature toggles sa TBD, ginagamit ang mga platform: LaunchDarkly (enterprise, buong functionality), Firebase Remote Config (libre para sa maliliit na project), Split.io (open-source). Nagbibigay sila ng: naka-target na pag-activate ng feature batay sa porsyento ng user, A/B testing, pagsubaybay sa paggamit at awtomatikong pag-deactivate sa mga error. Sa mga mobile project, ang Firebase Remote Config ang pinakasikat na pagpipilian dahil sa integrasyon nito sa Firebase at libreng hangganan hanggang 1000 user.