Trunk-Based Development — apa itu, prinsip dan bekerja dalam satu cabang

Apa itu Trunk-Based Development?

Trunk-Based Development (TBD) — metodologi manajemen versi di mana semua pengembang mengintegrasikan perubahan mereka ke dalam satu cabang utama (trunk, main atau master) beberapa kali sehari. Berbeda dengan Git Flow dengan cabang fiturnya yang berumur panjang, TBD meminimalkan masa pakai cabang hingga beberapa jam, jarang hingga 1–2 hari. Tujuan utamanya adalah menghindari "neraka merge" (merge hell), ketika fitur besar digabungkan dengan trunk setelah berminggu-minggu pengembangan.

Menurut Google Cloud DevOps, 2024, Trunk-Based Development adalah salah satu praktik kunci tim DevOps berkinerja tinggi. Penelitian State of DevOps Report (Puppet, 2023) menunjukkan bahwa tim yang menggunakan TBD pulih 30% lebih cepat dari kegagalan dan 50% lebih jarang mengalami cacat kritis di produksi. TBD wajib untuk Continuous Deployment.

Trunk-Based Development tidak berarti pengembang melakukan commit langsung ke trunk tanpa verifikasi. Dalam TBD, digunakan cabang fitur berumur pendek yang setelah pembuatan MR dan review kode cepat (dalam beberapa jam) digabungkan ke trunk. Jika review memakan waktu lebih dari satu hari — berarti fitur tersebut harus dipecah menjadi bagian yang lebih kecil.

State of DevOps Report: data tentang TBD

Laporan tahunan State of DevOps Report (Puppet/DORA) melacak praktik tim berkinerja tinggi. Sejak 2015, TBD berada di 3 praktik teratas yang berkorelasi dengan frekuensi pengiriman tinggi (deploy frequency) dan waktu pemulihan rendah (MTTR). Tim yang menerapkan TBD menggunakan kode 2–3 kali lebih sering dan pulih 30% lebih cepat dari kegagalan (DORA, 2023).

Feature Toggles: mengelola kode yang belum selesai tanpa cabang

Feature Toggles (bendera fitur, feature flags) — mekanisme untuk mengaktifkan dan menonaktifkan fungsionalitas tanpa mengubah kode. Dalam TBD, feature toggles menggantikan cabang fitur: pengembang melakukan commit kode yang belum selesai ke trunk tetapi menyembunyikannya di balik bendera bersyarat. Ketika fitur siap ditampilkan, bendera dialihkan dalam konfigurasi tanpa penerapan ulang.

Menurut Martin Fowler, 2024, feature toggles dibagi menjadi empat jenis: release toggles (mengelola visibilitas fitur), experiment toggles (pengujian A/B), ops toggles (mengelola parameter operasional), dan permission toggles (akses berdasarkan peran). Dalam proyek mobile, release toggles sangat berguna: fungsionalitas baru disembunyikan hingga tanggal rilis, tetapi kode sudah ada di trunk dan melalui CI/CD.

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

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

// Penggunaan dalam kode
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD dalam Trunk-Based Development: praktik wajib

Continuous Integration (CI) — komponen terpenting TBD. Setiap push ke trunk (atau ke cabang sementara sebelum MR) memulai pipeline lengkap: build, pengujian unit, pengujian integrasi, linter, analisis statis, pemeriksaan cakupan kode. Jika setidaknya satu tahap gagal — penulis perubahan memperbaiki kode sebelum commit berikutnya. "Trunk rusak — pengembangan berhenti" adalah aturan utama TBD.

Menurut Jez Humble, Continuous Delivery, 2024, Trunk-Based Development membutuhkan pipeline CI yang dieksekusi dalam 10–15 menit. Jika build lebih lama — pengembang lebih jarang melakukan commit, yang menghilangkan makna TBD. Dalam proyek mobile Android dan iOS, build bisa memakan waktu 20–30 menit, membuat TBD kurang nyaman. Dalam kasus seperti itu, tim menggunakan Short-Lived Feature Branches (cabang 1 hari) dengan CI segera.

# GitHub Actions untuk 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

Cabang berumur pendek: aturan kerja di TBD

Cabang berumur pendek (short-lived branches) — kompromi antara TBD murni (commit langsung ke trunk) dan Git Flow. Cabang hidup tidak lebih dari 1–2 hari, berisi perubahan untuk 1–3 commit, dan setelah review (tidak lebih dari 4 jam menunggu) digabungkan ke trunk. Jika fitur membutuhkan lebih banyak waktu — dibagi menjadi subtugas, masing-masing dengan cabang berumur pendeknya sendiri.

Menurut TBD Documentation, 2024, aturan cabang berumur pendek: cabang dibuat dari trunk segar (tidak lebih dari 1 jam), tidak disinkronkan dengan trunk melalui merge/rebase (jika lebih dari 4 jam telah berlalu — dibuat cabang baru), MR/PR dibuat segera setelah commit pertama (bahkan jika pekerjaan belum selesai — sebagai Draft).

Pre-tested commits: commit dengan jaminan

Untuk Trunk-Based Development, teknik pre-tested commits penting: pengembang sebelum commit menjalankan pipeline CI di cabangnya sendiri, dan hanya setelah status hijau commit masuk ke trunk. Di GitLab, ini diimplementasikan melalui Merge Request pipelines dengan opsi "Merge when pipeline succeeds". Di GitHub — melalui branch protection rules dengan Required status checks. Ini menjamin bahwa trunk tidak pernah mengandung kode rusak.

• 1–2 hari — masa pakai maksimum short-lived branch
• 1–3 commit — ukuran perubahan optimal
• 4 jam — waktu tunggu maksimum untuk review kode
• Buat MR segera setelah commit pertama, bahkan dalam status Draft

Branch by Abstraction: mengganti kode tanpa percabangan

Branch by Abstraction — teknik yang memungkinkan mengganti atau mengubah secara signifikan bagian dari sistem tanpa membuat cabang fitur yang berumur panjang. Alih-alih bercabang di Git, pengembang membuat abstraksi (antarmuka) di mana implementasi lama dan baru bekerja. Secara bertahap, semua konsumen dipindahkan ke implementasi baru, setelah itu implementasi lama dihapus.

Menurut Branch by Abstraction, 2024, tahapan Branch by Abstraction: 1) buat abstraksi untuk komponen yang akan diganti, 2) implementasikan versi baru di bawah abstraksi, 3) pindahkan konsumen ke implementasi baru melalui konfigurasi, 4) hapus implementasi lama. Semua langkah di-commit ke trunk dalam porsi kecil, tidak ada satupun yang merusak CI/CD.

TBD vs Git Flow: perbandingan pendekatan

Trunk-Based Development dan Git Flow — dua pendekatan yang berlawanan dalam mengelola cabang. Git Flow menggunakan cabang berumur panjang dan hierarki yang ketat, TBD — satu cabang dan siklus integrasi pendek. Pilihan di antara keduanya tergantung pada ukuran tim, frekuensi rilis, dan tingkat otomatisasi CI/CD.

Kesalahan umum saat menerapkan Trunk-Based Development

Kesalahan TBD paling sering terkait dengan CI/CD yang tidak memadai atau disiplin commit yang lemah. Kesalahan pertama — menerapkan TBD tanpa CI, yang rusak pada commit pertama yang gagal. Jika trunk tidak dapat diperbaiki dalam 15 menit — tim kehilangan kepercayaan pada proses dan kembali ke cabang panjang. Kedua — mengizinkan cabang berumur panjang "khusus untuk fitur ini", yang menghancurkan seluruh konsep.

Menurut Paul Hammant, 2023, kesalahan ketiga — modularitas kode yang buruk. Trunk-Based Development membutuhkan kode yang dibagi menjadi modul independen. Jika perubahan dalam satu kelas merusak tiga modul lain — pengembang tidak dapat melakukan commit dalam porsi kecil. Keempat — mengabaikan feature toggles: upaya melakukan commit kode yang belum selesai tanpa bendera menyebabkan kerusakan trunk untuk seluruh tim.

Trunk-Based Development dalam pengembangan mobile

Trunk-Based Development dalam proyek mobile memiliki kekhasan karena waktu build yang lama (20–30 menit untuk Android dan iOS) dan persyaratan kualitas yang ketat. Google dan Spotify menggunakan TBD dalam pengembangan mobile, menerapkan short-lived branches dengan kewajiban melewati CI sebelum merge. Feature toggles dikelola melalui Firebase Remote Config atau LaunchDarkly.

Menurut LaunchDarkly Docs, 2024, dalam pengembangan mobile TBD memberikan keuntungan: fitur diuji di trunk bersama kode lainnya sebelum tanggal rilis, yang mengurangi risiko masalah integrasi. Jika pipeline CI memakan waktu lebih dari 15 menit — short-lived branches 1 hari dengan CI otomatis di setiap push adalah optimal. Untuk Apple App Store dan Google Play, TBD memerlukan pengaturan staged rollouts melalui feature toggles.

Feature Flags sebagai layanan: LaunchDarkly dan Firebase

Untuk mengelola feature toggles dalam TBD, digunakan platform: LaunchDarkly (enterprise, fungsionalitas penuh), Firebase Remote Config (gratis untuk proyek kecil), Split.io (open-source). Mereka menyediakan: aktivasi fitur yang ditargetkan berdasarkan persentase pengguna, pengujian A/B, pemantauan penggunaan, dan penonaktifan otomatis saat terjadi kesalahan. Dalam proyek mobile, Firebase Remote Config adalah pilihan paling populer karena integrasinya dengan Firebase dan batas gratis hingga 1000 pengguna.