Trunk-Based Development #

Trunk-Based Development (TBD) adalah kebalikan filosofis dari Gitflow — alih-alih memisahkan pekerjaan ke banyak branch yang hidup berhari-hari atau berminggu-minggu, semua developer melakukan commit langsung ke satu branch utama (trunk) atau ke short-lived branch yang tidak lebih dari satu hari. Ini terdengar berbahaya bagi siapapun yang terbiasa dengan Gitflow. Bagaimana bisa semua orang commit ke satu tempat tanpa merusak satu sama lain? Jawabannya ada pada disiplin yang berbeda: commit kecil dan sering, CI yang sangat ketat dan cepat, feature flags untuk menyembunyikan fitur yang belum selesai, dan kultur engineering yang memprioritaskan integrasi terus-menerus atas isolasi panjang. Artikel ini membahas TBD dari prinsip intinya, cara kerjanya dalam praktik, feature flags sebagai pilar utamanya, dan kapan TBD adalah pilihan yang tepat versus Gitflow.

Masalah yang Dipecahkan TBD #

Untuk memahami mengapa TBD ada, perlu dipahami masalah yang sering muncul dengan long-lived branches seperti di Gitflow:

Masalah dengan long-lived branches:

1. Merge Hell
   Feature branch hidup 2 minggu → develop sudah berubah drastis
   → Merge conflict yang memakan waktu berjam-jam atau berhari-hari
   → Integration testing yang lambat
   → Developer takut merge → branch makin lama → masalah makin besar

2. Delayed Integration
   Fitur dikerjakan secara terpisah → bug integrasi baru ketahuan
   saat merge di akhir sprint
   → Late discovery of integration issues
   → Sulit menemukan root cause ketika banyak perubahan sekaligus

3. Divergence yang Makin Besar
   Setiap hari branch tidak di-merge = satu hari divergence lebih besar
   → Semakin lama = semakin susah di-merge
   → Tim kadang menghindari merge "nanti saja" → semakin menumpuk

4. Context Switching yang Mahal
   Review PR yang besar (500+ baris perubahan) = cognitive load tinggi
   → Reviewer sering tidak benar-benar teliti
   → Bug yang seharusnya tertangkap di review lolos ke production

TBD mengatasi ini dengan filosofi yang berlawanan: integrate lebih sering, bukan lebih jarang. Masalah integrasi yang dideteksi di menit terakhir sprint jauh lebih mahal dari masalah yang sama dideteksi 5 menit setelah dicommit.

Prinsip Core Trunk-Based Development #

flowchart TD
    subgraph TBD["Trunk-Based Development"]
        Dev1["Developer A"]
        Dev2["Developer B"]
        Dev3["Developer C"]
        Trunk["main / trunk\n(selalu deployable)"]
        CI["CI Pipeline\n(berjalan per commit)"]
        Prod["Production"]

        Dev1 -->|"commit kecil setiap\nbeberapa jam"| Trunk
        Dev2 -->|"commit kecil setiap\nbeberapa jam"| Trunk
        Dev3 -->|"commit kecil setiap\nbeberapa jam"| Trunk
        Trunk --> CI
        CI -->|"hijau → deploy\n(bisa multiple kali sehari)"| Prod
    end

    style Trunk fill:#27AE60,color:#fff
    style CI fill:#E67E22,color:#fff

Prinsip 1: Satu Branch yang Selalu Deployable #

Trunk (biasanya main) selalu dalam kondisi bisa di-deploy ke production kapan saja. Ini bukan aspirasi — ini adalah constraint yang memaksa tim untuk menjaga kualitas di setiap commit.

Apa artinya "selalu deployable":
  → Semua test harus lulus setiap commit
  → Build harus sukses setiap commit
  → Tidak ada broken dependencies
  → Tidak ada fitur setengah jadi yang aktif (pakai feature flag)

Cara menjaganya:
  → CI yang cepat (idealnya < 10 menit untuk feedback awal)
  → Test coverage yang bermakna
  → Developer tidak boleh push jika CI merah
  → Feature flags untuk kode yang belum siap dipublish ke user

Prinsip 2: Commit Kecil dan Sering #

Ukuran commit ideal di TBD:
  → Setiap commit mengubah maksimal 1 hal yang logis
  → Setiap commit meninggalkan codebase dalam kondisi lebih baik (atau sama)
  → Developer commit minimal 1–2 kali per hari, idealnya lebih sering
  → Review codebase lebih mudah: perubahan kecil = lebih mudah dipahami

Perbandingan dengan Gitflow:
  Gitflow: PR berisi 200–500 baris perubahan setelah beberapa hari kerja
  TBD:     Commit berisi 20–50 baris perubahan setelah beberapa jam kerja

  Reviewer lebih mudah memahami 50 baris → review lebih teliti
  Bug lebih mudah dilacak → setiap commit kecil dan bermakna
  Rollback lebih mudah → setiap commit bisa di-revert tanpa dampak besar

Prinsip 3: Integrasi Terus-Menerus #

"Continuous" di Continuous Integration berarti benar-benar terus-menerus,
bukan hanya "sekali sehari" atau "saat buat PR":

Target CI di TBD:
  → Setiap push ke trunk memicu CI pipeline
  → CI pipeline harus selesai < 10 menit (idealnya < 5 menit)
  → Developer mendapat feedback sebelum pindah ke pekerjaan lain
  → Jika CI merah: ini adalah BLOCKING priority — diperbaiki sekarang

Mengapa CI harus cepat:
  Developer commit → tunggu 30 menit → CI merah → sudah lupa konteks
  → Slow CI = developer mulai bypass CI = CI kehilangan nilainya

  Developer commit → tunggu 5 menit → CI merah → masih ingat apa yang diubah
  → Fast CI = developer selalu dalam loop yang ketat dengan kualitas kode

Short-Lived Feature Branches — Kompromi yang Pragmatis #

TBD murni berarti semua commit langsung ke trunk. Tapi ada variasi yang lebih pragmatis yang banyak digunakan — short-lived feature branches yang tidak hidup lebih dari satu hari kerja.

flowchart LR
    subgraph Gitflow["Gitflow — Long-Lived"]
        GF["feature/checkout\n(hidup 2 minggu)"]
        GD["develop"]
        GF -->|"merge setelah\n2 minggu"| GD
    end

    subgraph TBDPure["TBD Murni"]
        TC1["commit A (Dev A)"]
        TC2["commit B (Dev B)"]
        TC3["commit C (Dev A)"]
        TT["trunk/main"]
        TC1 --> TT
        TC2 --> TT
        TC3 --> TT
    end

    subgraph TBDShort["TBD dengan Short-Lived Branch"]
        SF["feature/add-button\n(hidup < 1 hari)"]
        ST["trunk/main"]
        SF -->|"merge dalam\nhitungan jam"| ST
    end

    style GF fill:#E74C3C,color:#fff
    style TT fill:#27AE60,color:#fff
    style ST fill:#27AE60,color:#fff

Aturan short-lived branches di TBD:

Batasan waktu:
  → Branch tidak boleh hidup lebih dari 1 hari kerja (ideally < 4 jam)
  → Jika lebih lama: break down pekerjaan menjadi lebih kecil
  → Tidak ada "tapi fiturnya belum selesai" — gunakan feature flag

Batasan ukuran:
  → Branch berisi maksimal 1 unit perubahan logis yang kecil
  → Tidak ada "sekali jalan implement semuanya"

Merge ke trunk:
  → Tidak ada review panjang — reviewer harus bisa review dalam < 30 menit
  → Jika review butuh > 30 menit: PR terlalu besar, break down

Satu ciri TBD yang baik:
  Trunk memiliki puluhan commit per hari dari banyak developer
  (bukan 1–2 commit besar per minggu per developer)

Feature Flags — Pilar Utama TBD #

Ini adalah mekanisme yang membuat TBD memungkinkan untuk fitur-fitur yang tidak bisa selesai dalam satu hari. Feature flag memungkinkan kode yang sudah di-merge ke trunk untuk tersembunyi dari user sampai siap dipublish.

// Feature flag paling sederhana — environment variable
function CheckoutButton({ cart }) {
  const showNewCheckout = process.env.FEATURE_NEW_CHECKOUT === 'true'

  if (showNewCheckout) {
    return <NewCheckoutFlow cart={cart} />  // belum aktif di production
  }
  return <OldCheckoutFlow cart={cart} />   // default untuk semua user
}

// Feature flag yang lebih canggih — gradual rollout
function CheckoutButton({ cart, userId }) {
  const isInExperiment = featureFlags.isEnabled('new_checkout', {
    userId,
    rolloutPercentage: 10,  // aktif hanya untuk 10% user
  })

  if (isInExperiment) {
    return <NewCheckoutFlow cart={cart} />
  }
  return <OldCheckoutFlow cart={cart} />
}

Tipe feature flag berdasarkan tujuan:

1. Release Flags (paling umum di TBD)
   Menyembunyikan fitur yang belum selesai atau belum siap untuk semua user
   Contoh: fitur baru yang masih dalam development
   Lifecycle: dibuat → diaktifkan saat siap → DIHAPUS dari kode

2. Experiment Flags (A/B Testing)
   Mengaktifkan variasi berbeda untuk subset user
   Contoh: tampilan baru untuk 50% user, tampilan lama untuk 50% lainnya
   Lifecycle: dibuat → dieksperimen → pemenang dipilih → flag dihapus

3. Ops Flags (Operational/Kill Switch)
   Mematikan fitur tertentu saat ada masalah di production
   Contoh: matikan fitur rekomendasi AI jika service-nya down
   Lifecycle: permanen (tapi jarang di-toggle)

4. Permission Flags
   Mengaktifkan fitur hanya untuk segmen user tertentu
   Contoh: fitur premium hanya untuk subscriber berbayar
   Lifecycle: semi-permanen

Feature flag adalah hutang teknikal yang harus dibayar. Setiap flag yang tidak dihapus setelah fitur diluncurkan adalah kode mati yang membuat codebase lebih sulit dipahami. Buat kebijakan tim: setiap release flag harus dihapus dalam 1–2 sprint setelah fitur aktif 100%. Gunakan tools untuk tracking flag yang sudah tidak aktif.

CI Pipeline yang Benar untuk TBD #

CI adalah gatekeeper utama di TBD. Ia harus cukup cepat untuk memberikan feedback bermakna sebelum developer pindah ke hal lain.

# GitHub Actions — CI untuk TBD yang dioptimasi untuk kecepatan
name: CI

on:
  push:
    branches: [main]        # setiap push ke trunk
  pull_request:
    branches: [main]        # setiap PR ke trunk

jobs:
  # Stage 1: Feedback cepat (< 2 menit)
  quick-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lint
        run: make lint          # ~30 detik
      - name: Type check
        run: make typecheck     # ~30 detik
      - name: Unit tests
        run: make test-unit     # ~60 detik

  # Stage 2: Feedback lebih lengkap (< 10 menit)
  full-check:
    runs-on: ubuntu-latest
    needs: quick-check
    steps:
      - uses: actions/checkout@v4
      - name: Integration tests
        run: make test-integration   # ~3 menit
      - name: Build
        run: make build              # ~2 menit
      - name: Security scan
        run: make security-scan      # ~1 menit

  # Stage 3: Deployment ke staging (jika main)
  deploy-staging:
    runs-on: ubuntu-latest
    needs: full-check
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Deploy to staging
        run: make deploy-staging

Strategi menjaga CI tetap cepat:

1. Parallelisasi test:
   Jalankan test suite di multiple goroutine/process secara paralel
   100 test x 100ms = 10 detik sequential
   100 test x 100ms / 10 parallel = 1 detik

2. Test caching:
   Hanya jalankan ulang test yang terdampak oleh perubahan
   Tools: Nx (JavaScript), Bazel, Buck2

3. Pisahkan unit dan integration test:
   Unit test: cepat (< 2 menit), jalankan setiap commit
   Integration test: lebih lambat (< 10 menit), jalankan setiap PR
   E2E test: paling lambat, jalankan sebelum release

4. Fail fast:
   Jika lint atau type check gagal, jangan jalankan test
   Hemat waktu untuk masalah yang sudah jelas lebih dulu

Teknik Menjaga Kualitas di TBD #

Tanpa code review yang panjang seperti di Gitflow, TBD mengandalkan teknik lain untuk menjaga kualitas.

Pair Programming #

Pair Programming di TBD:
  → Driver menulis kode, navigator mereview secara real-time
  → "Review" terjadi saat kode ditulis, bukan setelah PR dibuat
  → Tidak ada PR review yang lambat — code sudah di-review saat dibuat
  → Knowledge sharing otomatis terjadi

Kapan pair programming paling efektif:
  → Fitur yang kompleks atau berisiko tinggi
  → Developer baru yang sedang onboarding
  → Ketika domain knowledge perlu disebarkan
  → Debugging yang sulit

Ship / Show / Ask Framework #

Ini adalah framework yang populer di TBD untuk memutuskan apakah setiap perubahan perlu review atau tidak.

Ship — Langsung push ke trunk tanpa review:
  Cocok untuk perubahan yang:
  → Sangat kecil dan jelas (fix typo, update dependency minor)
  → Kamu yakin 100% dan memiliki test yang cover-nya
  → Tidak mengubah behavior yang user-facing
  → Bisa dengan mudah di-revert jika ada masalah

Show — Push ke trunk dan notifikasi tim (async):
  Cocok untuk perubahan yang:
  → Cukup kecil tapi ada keputusan teknis yang dibuat
  → Refactoring yang mempengaruhi beberapa file
  → Kamu yakin tapi ingin orang lain tahu tentang perubahan ini
  Caranya: push langsung, lalu post di Slack "hey saya baru saja
  merge X, FYI" — tidak perlu approval, hanya informasi

Ask — Buat PR dan minta review sebelum merge:
  Cocok untuk perubahan yang:
  → Ada keputusan design atau arsitektur yang perlu diskusi
  → Perubahan yang mempengaruhi banyak bagian sistem
  → Kamu tidak yakin apakah pendekatan ini benar
  → Perubahan berisiko tinggi (payment, security, dll)

Trunk Health Monitoring #

Metric yang perlu dipantau untuk menjaga kesehatan trunk:

1. Build success rate
   Target: > 99% build sukses
   Jika sering merah: CI mungkin flaky atau ada disiplin yang kurang

2. Time to green
   Waktu dari commit ke CI hijau
   Target: < 10 menit
   Jika > 10 menit: CI perlu dioptimasi

3. Time to revert
   Berapa lama dari "trunk rusak" ke "trunk sehat lagi"
   Target: < 15 menit
   Ini mengukur seberapa cepat tim merespons broken builds

4. Commit frequency
   Berapa commit per developer per hari
   Target: 2–5 commit per developer per hari
   Jika terlalu rendah: mungkin ada blocker atau branch yang terlalu panjang

Perbedaan TBD vs Gitflow vs GitHub Flow #

                    TBD             GitHub Flow      Gitflow
─────────────────────────────────────────────────────────────────
Branch utama        1 (trunk)       1 (main)         2 (main+develop)
Branch lain         short-lived     feature branches  feature/release/hotfix
Umur branch         < 1 hari        beberapa hari     hari–minggu
Deployment          bisa setiap     saat merge PR     dari tag versi
                    commit          ke main

Feature isolation   Feature Flags   Branch isolation  Branch isolation
Review process      Ship/Show/Ask   PR review wajib   PR review wajib
CI requirement      Sangat ketat    Ketat             Sedang
Tim yang cocok      Mature, kecil   Sedang            Besar, enterprise
                    atau besar
Rilis versioned     Kurang cocok    Kurang cocok      Sangat cocok
Hotfix emergency    Langsung ke     Feature branch    Hotfix branch
                    trunk           pendek

Kapan TBD Tepat dan Kapan Tidak #

TBD sangat cocok untuk:
  ✓ Tim yang sudah mature secara engineering — semua developer memahami
    risiko commit ke trunk dan memiliki disiplin untuk tidak merge kode
    yang merusak
  ✓ Tim yang menginginkan deployment very frequently (beberapa kali sehari)
  ✓ Produk yang tidak memerlukan versioned releases (SaaS web app)
  ✓ Tim yang sudah memiliki test coverage yang baik dan CI yang cepat
  ✓ Tim kecil–menengah yang kolaborasinya erat dan komunikasi mudah

TBD kurang cocok untuk:
  ✗ Tim yang baru terbentuk atau developer yang masih junior —
    risiko "merusak trunk" terlalu tinggi
  ✗ Produk yang memerlukan multiple version support
    (SDK, library, enterprise software dengan long-term support)
  ✗ Tim yang terdistribusi di banyak timezone tanpa overlap yang cukup
  ✗ Regulasi yang mewajibkan formal approval sebelum perubahan ke production
  ✗ Tim yang belum memiliki test coverage yang memadai —
    TBD tanpa test hanyalah chaos yang terstruktur

Google, Facebook, dan Microsoft adalah contoh perusahaan yang menggunakan Trunk-Based Development di skala besar. Google menggunakan satu monorepo besar dengan TBD untuk ribuan engineer. Yang memungkinkan ini adalah investasi besar di tooling: CI yang sangat cepat, code search yang powerful, dan budaya engineering yang sangat disiplin. Jangan adopsi TBD hanya karena “Google melakukannya” — pastikan fondasi (test, CI, engineering culture) sudah siap.

Migrasi dari Gitflow ke TBD #

Berpindah dari Gitflow ke TBD adalah perubahan budaya, bukan hanya perubahan teknikal. Ini membutuhkan pendekatan bertahap.

flowchart LR
    G["Gitflow\n(long-lived branches)"]
    GH["GitHub Flow\n(feature branches, PR)"]
    TBDS["TBD dengan\nshort-lived branches"]
    TBDP["TBD Murni\n(direct to trunk)"]

    G -->|"Step 1:\nPerpendek\nlife of branch"| GH
    GH -->|"Step 2:\nPerketat\nbatas waktu branch"| TBDS
    TBDS -->|"Step 3:\n(opsional)\nEliminasi\nbranch"| TBDP

    style G fill:#E74C3C,color:#fff
    style GH fill:#E67E22,color:#fff
    style TBDS fill:#F39C12,color:#fff
    style TBDP fill:#27AE60,color:#fff

Langkah migrasi yang pragmatis:

Step 1 — Dari Gitflow ke GitHub Flow (1–2 bulan):
  → Hapus develop branch, gunakan main saja
  → Feature branch langsung merge ke main setelah review
  → Deploy dari main setiap merge
  → CI harus wajib hijau sebelum merge
  → Mulai tulis feature flags untuk fitur yang panjang

Step 2 — Dari GitHub Flow ke TBD dengan short-lived branches (2–3 bulan):
  → Batasi umur branch maksimal 1 hari
  → Break down PR: maksimal 200 baris perubahan
  → Investasi di test coverage — target: > 70% unit test coverage
  → Optimasi CI: target < 10 menit

Step 3 — TBD murni (opsional, 3–6 bulan):
  → Mulai praktek pair programming untuk shared context
  → Ship/Show/Ask framework untuk memutuskan kapan perlu review
  → Invest di feature flag management yang proper

Hal yang harus ada sebelum mulai migrasi:
  □ CI pipeline yang reliable (success rate > 95%)
  □ Test coverage yang memadai
  □ Team alignment — semua developer mengerti dan setuju
  □ Feature flag infrastructure yang siap (bisa dimulai sederhana)
  □ Monitoring production yang baik

Anti-Pattern TBD yang Harus Dihindari #

Commit Langsung ke Trunk Tanpa Test yang Cukup #

// ✗ Anti-pattern: "commit dulu, test nanti"
git add .
git commit -m "WIP: tambah fitur payment"
git push origin main
// trunk sekarang rusak sampai test selesai ditulis

// ✓ TBD yang benar: code dan test dibuat bersamaan
// Jika fitur belum selesai → pakai feature flag, bukan WIP commit
git add src/payment.go src/payment_test.go  // code + test sekaligus
git commit -m "Add payment gateway integration (behind feature flag)"
git push origin main
// trunk tetap hijau karena fitur tersembunyi di balik flag

Membiarkan Trunk Rusak Terlalu Lama #

// ✗ Anti-pattern: trunk rusak, developer melanjutkan pekerjaan
Developer A push → CI merah → Developer A tidak perhatikan
Developer B, C, D pull dari trunk yang rusak → semua kode mereka di atas kode rusak

// ✓ Aturan TBD: trunk rusak = BLOCKING priority untuk seluruh tim
Saat CI merah:
  1. Developer yang merusak langsung perbaiki — ini lebih penting dari pekerjaan lain
  2. Jika tidak bisa diperbaiki dalam 10 menit → revert commit
  3. Tim TIDAK boleh merge apapun ke trunk yang merah
  4. Trunk yang merah lebih dari 15 menit = incident yang perlu dibahas

Feature Flag yang Tidak Pernah Dihapus #

// ✗ Anti-pattern: flag graveyard
if (featureFlags.isEnabled('new_checkout_v1')) { ... }       // aktif sejak 2021
if (featureFlags.isEnabled('redesign_checkout_v2')) { ... }  // aktif sejak 2022
if (featureFlags.isEnabled('checkout_optimization')) { ... } // aktif sejak 2023
if (featureFlags.isEnabled('new_checkout_final')) { ... }    // aktif sejak 2024

// Semua flag sudah 100% aktif tapi tidak pernah dihapus dari kode
// Codebase penuh conditional yang tidak berguna

// ✓ Kebijakan: setiap flag harus ada issue/ticket untuk cleanup
// Setelah fitur rollout 100% → hapus flag dalam sprint berikutnya
// Gunakan lint rule untuk detect flag yang sudah expired

TBD Tanpa Test Coverage yang Memadai #

// ✗ Anti-pattern: TBD tanpa safety net
Tim memutuskan pakai TBD
Developer commit langsung ke trunk
Tidak ada test yang cukup
→ Bug masuk production lebih cepat dari sebelumnya!

// TBD tanpa test bukan TBD — itu adalah chaos

// ✓ Prerequisite sebelum TBD:
Unit test coverage: > 70%
Integration test untuk happy path: ada
CI pipeline: < 10 menit, reliable
Production monitoring: ada (bisa rollback cepat jika bug lolos)

Checklist Trunk-Based Development #

FONDASI (wajib ada sebelum mulai TBD):
  □ CI pipeline yang reliable (> 95% green, < 10 menit)
  □ Unit test coverage yang memadai (> 70% untuk core business logic)
  □ Feature flag infrastructure (bisa dimulai sederhana dengan env var)
  □ Production monitoring dan alerting (bisa rollback dalam < 15 menit)
  □ Team alignment — semua developer paham dan setuju dengan TBD

COMMIT HYGIENE:
  □ Setiap commit berisi satu perubahan logis yang kecil
  □ Semua developer commit ke trunk minimal sekali per hari
  □ Commit message yang jelas: apa yang diubah dan mengapa
  □ CI harus hijau sebelum push ke trunk (atau segera diperbaiki)
  □ Branch (jika ada) tidak hidup lebih dari 1 hari

FEATURE FLAGS:
  □ Semua fitur yang belum siap production dibalik feature flag
  □ Setiap flag terdaftar dengan owner dan rencana cleanup
  □ Flag yang sudah 100% aktif dihapus dalam 1–2 sprint
  □ Flag tidak bersarang (flag di dalam flag) — terlalu kompleks

CI/CD:
  □ Setiap commit ke trunk memicu CI pipeline
  □ CI failure adalah blocking — tidak ada merge selama trunk merah
  □ Deployment ke production bisa dilakukan kapan saja (branch selalu ready)
  □ Rollback procedure terdefinisi dan bisa dilakukan dalam < 15 menit

KUALITAS:
  □ Ship/Show/Ask framework digunakan dan dipahami tim
  □ Pair programming untuk fitur yang kompleks atau berisiko
  □ Trunk health metric dipantau (build rate, time to green, commit frequency)
  □ Post-mortem jika trunk rusak lebih dari 15 menit

Ringkasan #

• TBD adalah tentang integrasi yang lebih sering, bukan menghilangkan isolation — masalah integrasi yang ditemukan setelah commit 30 menit jauh lebih murah dari masalah yang sama ditemukan setelah 2 minggu branch divergence.
• Feature flags adalah pengganti branch isolation — kode yang sudah di-merge tapi belum siap untuk user disembunyikan di balik flag. Ini memungkinkan integrate early tanpa expose incomplete features.
• CI harus cepat untuk TBD berhasil — CI yang lebih dari 10 menit membuat developer bypass atau mengabaikannya. Investasi di CI speed adalah investasi di kualitas kode.
• Trunk rusak = blocking priority untuk seluruh tim — tidak ada yang boleh merge selama trunk merah. Ini adalah aturan yang paling penting dan paling sering dilanggar saat awal adopsi TBD.
• Ship/Show/Ask framework menggantikan “semua harus PR review” — tidak semua perubahan butuh review formal. Perubahan kecil dan obvious bisa langsung push; perubahan yang ada keputusan arsitektur butuh diskusi.
• Test coverage adalah prerequisite, bukan bonus — TBD tanpa test adalah chaos yang terstruktur. Pastikan coverage bermakna ada sebelum mulai TBD.
• Migrasi dari Gitflow ke TBD harus bertahap — Gitflow → GitHub Flow → TBD short-lived branches → TBD murni. Lompat langsung ke TBD murni dari Gitflow hampir selalu gagal.
• Feature flags yang tidak dihapus menjadi technical debt — setiap flag adalah conditional yang membuat kode lebih sulit dipahami. Hapus flag dalam 1–2 sprint setelah fitur rollout 100%.
• TBD membutuhkan engineering culture yang mature — ini bukan soal tooling, tapi soal kepercayaan, disiplin, dan komunikasi dalam tim. Tim yang belum siap budayanya akan struggle dengan TBD.
• TBD dan Gitflow tidak selalu berlawanan — banyak tim besar menggunakan TBD di level team (commit ke branch tim setiap hari), tapi Gitflow untuk koordinasi antar tim dan versioned releases. Pilih yang sesuai dengan konteks, bukan yang terdengar paling keren.

← Sebelumnya: Gitflow   Berikutnya: Pull Request Fundamental →