Apa Itu Trunk Based Development: Panduan Developer

Apa itu trunk based development? Ini adalah metode di mana semua developer dalam tim mengkomit kode ke satu branch bersama yang disebut trunk -- biasanya bernama main -- setidaknya sekali sehari. Tidak ada feature branch yang hidup berminggu-minggu. Tidak ada nama file seperti hotfix-v2-backup-final yang terbengkalai tiga minggu. Branch pendek, cepat di-merge, dan langsung dihapus. Codebase selalu siap rilis. Google menjalankan 35.000 developer dengan cara ini. Begini cara kerjanya, kapan masuk akal digunakan, dan kapan tidak.

Masalah klasik nama file berganda -- tapi versi kode

Jika pernah membuka shared folder dan menemukan tiga file berbeda -- report_v1.xlsx, report_v2_FINAL.xlsx, dan report_GUNAKAN_INI.xlsx -- berdampingan, kamu sudah mengerti persis rasa sakit yang ingin diselesaikan trunk-based development.

Situasi ini terjadi di codebase ketika tim menggunakan long-lived feature branch. Seseorang mulai mengerjakan fitur di minggu pertama. Tim lain terus mengirim kode. Di minggu ketiga, branch tersebut sudah puluhan commit tertinggal dari main. Merge-nya jadi proyek akhir pekan yang tidak ada yang mau tanggung. Konflik menumpuk. Developer yang menulis kode sudah lupa kenapa separuh kodenya ada. Ini adalah "merge hell."

Gitflow -- alternatif yang paling banyak diajarkan -- mencoba menyelesaikan ini dengan struktur formal: branch terpisah untuk fitur, rilis, dan hotfix, masing-masing dengan masa hidup yang ditentukan. Strukturnya terlihat rapi di atas kertas. Dalam praktiknya, branch menumpuk seperti versi spreadsheet di shared drive, dan hari integrasi berubah menjadi minggu integrasi.

Trunk-based development mengambil sikap sebaliknya: hentikan penumpukan integration debt. Commit ke main. Hari ini.

Semua orang commit ke main, setiap hari -- itulah seluruh modelnya

Aturan intinya sederhana: semua developer mendorong perubahan ke trunk bersama setidaknya sekali setiap 24 jam. Tidak ada pengecualian untuk "saya belum selesai" -- kamu commit apa yang ada, dan pastikan apa yang ada tidak merusak build.

Kedengarannya mengkhawatirkan sampai kamu memahami mekanisme yang membuatnya aman:

• Branch pendek: Kamu masih bisa menggunakan branch, tapi hanya hidup dalam jam, bukan minggu. Branch yang bertahan lebih dari dua hari adalah tanda peringatan yang perlu diperiksa segera.

• Automated testing pada setiap commit: Pipeline CI menjalankan test suite segera setelah commit masuk. Jika ada yang rusak, kamu tahu dalam hitungan menit, bukan di akhir sprint ketika semuanya sudah rumit.

• Feature flags: Fitur yang setengah jadi tersembunyi di balik toggle sampai siap dikirim. Pengguna tidak pernah melihat pekerjaan yang belum selesai, meskipun sudah ada di kode produksi.

Hasilnya adalah codebase yang selalu bisa dirilis -- bukan "bisa dirilis setelah kita merge feature branch dan jalankan QA selama seminggu," tapi bisa dirilis sekarang jika diperlukan. Itulah janji fundamentalnya.

Branch pendek: ukurnya dalam jam, bukan minggu

Dalam trunk-based development, kamu tidak dilarang menggunakan branch. Yang dilarang adalah membuat branch berumur panjang.

Branch yang dibuka pukul 9 pagi, dikerjakan sepanjang pagi, mendapat code review setelah makan siang, dan di-merge ke main sebelum pukul 5 sore adalah jenis yang tepat. Rekan kerja mendapat kesempatan meninjau pekerjaan sebelum masuk ke trunk. Cukup kecil untuk dipahami dalam satu bacaan. Konflik, jika ada, selesai dalam hitungan menit.

Branch yang hidup tiga minggu sementara satu developer membangun seluruh sistem autentikasi secara terisolasi adalah masalahnya. Ketika saatnya merge tiba, tim menghabiskan lebih banyak waktu menyelesaikan konflik daripada waktu yang dihabiskan untuk membangun fitur tersebut.

Ambang batas praktis yang digunakan sebagian besar tim trunk-based: jika branch belum di-merge dalam dua hari, ada sesuatu yang perlu diubah. Entah fiturnya terlalu besar dan perlu dipecah menjadi bagian lebih kecil, atau butuh feature flag agar sebagian pekerjaan bisa masuk ke trunk dengan aman.

Memecah pekerjaan menjadi bagian lebih kecil adalah disiplin inti yang sebenarnya dikembangkan dalam trunk-based development. Alih-alih "bangun seluruh dashboard," kamu kirim "tambahkan data layer," lalu "tambahkan chart pertama," lalu "sambungkan filter." Setiap bagian merge ke trunk, diuji, dan dikirim secara mandiri. Fitur lengkap muncul secara bertahap selama beberapa commit.

Ini terdengar lebih lambat. Dalam praktiknya lebih cepat, karena kamu menemukan masalah saat konteksnya masih segar dan luas permukaannya masih kecil.

Feature flags: cara mengirim kode belum selesai tanpa merusak apapun

Feature flags -- disebut juga feature toggles -- adalah mekanisme yang membuat trunk-based development praktis ketika sebuah fitur tidak bisa diselesaikan dalam satu short-lived branch.

Idenya sederhana: bungkus fungsionalitas baru dalam kondisional yang hanya aktif ketika flag tertentu dinyalakan.

if (featureFlags.newReportingDashboard) {
  renderNewDashboard();
} else {
  renderOldDashboard();
}

Kode baru di-deploy ke produksi. Hanya saja tidak berjalan untuk pengguna sampai kamu mengaktifkan toggle. Ini berarti:

• Developer bisa commit pekerjaan yang sedang berjalan ke trunk tanpa memengaruhi siapapun

• QA bisa menguji fitur di produksi dengan mengaktifkan flag untuk pengguna atau environment tertentu

• Peluncuran menjadi perubahan konfigurasi, bukan event deployment yang penuh risiko

• Jika ada yang rusak, kamu matikan flag tanpa perlu rollback atau membuat branch hotfix baru

Infrastruktur feature flag berkisar dari variabel environment sederhana yang diperiksa saat startup hingga platform feature flag khusus yang lengkap. Untuk tim yang baru memulai, file config atau variabel per-environment sudah cukup memadai. Yang penting adalah kemampuannya, bukan kompleksitas toolingnya.

Kapan trunk-based development bukan pilihan yang tepat

Perlu dikatakan langsung: trunk-based development tidak selalu menjadi pilihan terbaik. Ada konteks tertentu yang membuatnya tidak cocok.

Pertimbangkan untuk tidak menggunakannya jika:

Pipeline CI/CD belum siap. Trunk-based development tanpa automated test pada setiap commit bukan strategi branching yang baik -- ini adalah codebase yang rusak dan menumpuk dengan cepat. Infrastruktur testing harus sudah ada terlebih dahulu sebelum model branching ini bisa bekerja.

Tim tidak bisa commit secara rutin karena sifat pekerjaannya. Tim terdistribusi di mana kontributor bekerja secara asinkron lintas zona waktu, atau proyek open-source di mana kontributor mengirimkan batch tidak teratur, akan kesulitan mengikuti ritme commit harian.

Lingkungan kerja memiliki regulasi ketat dengan jendela rilis wajib. Beberapa industri memerlukan persetujuan eksternal, siklus QA panjang, dan audit trail formal per release branch. Branch rilis terstruktur Gitflow lebih cocok untuk jenis workflow seperti ini.

Disiplin tim belum cukup matang. Trunk-based development mengharuskan setiap commit ke main lulus semua test atau langsung diperbaiki. Jika tim kamu mentoleransi build yang rusak, trunk bersama akan cepat menjadi masalah bersama semua orang.

Gitflow tetap menjadi pilihan yang masuk akal untuk tim dengan jadwal rilis triwulanan, beberapa fitur yang dikerjakan secara bersamaan oleh squad terpisah, atau persyaratan kepatuhan yang memerlukan isolasi di level branch. Pertanyaannya adalah kesesuaian yang jujur dengan kondisi tim, bukan pendekatan mana yang menang secara teori.

Cara beralih dari Gitflow ke trunk-based development tanpa krisis

Jika tim kamu saat ini menggunakan Gitflow dan ingin mencoba trunk-based development, migrasi tidak harus dilakukan sekaligus dalam satu langkah besar.

Mulailah dengan menghentikan pembuatan long-lived branch baru. Fitur yang dimulai setelah keputusan ini menggunakan short-lived branch dengan model baru. Fitur yang sudah dalam proses pada long branch diselesaikan dengan model lama. Kedua pendekatan bisa berdampingan sementara waktu.

Sebelum mengkomit pekerjaan yang belum selesai ke trunk, kamu harus memiliki feature flags terlebih dahulu. Menyiapkan sistem feature flag dasar sekalipun adalah prasyarat mutlak. Tanpanya, trunk-based development berarti mengirim UI yang belum selesai ke pengguna produksi.

Kemudian terapkan CI wajib pada branch main: automated test berjalan pada setiap push, test yang gagal memblokir merge, dan tidak ada yang merge tanpa build yang lulus. Ini adalah bagian yang tidak bisa dikompromikan.

Terakhir, definisikan aturan dua hari secara eksplisit: setiap branch yang lebih dari dua hari mendapat diskusi tentang apa yang harus dilakukan. Pecah fiturnya menjadi lebih kecil, tambahkan flag, atau kirim apa yang sudah selesai. Buat aturan ini terlihat jelas dalam proses pull request tim kamu.

Penyesuaian yang tidak nyaman yang dihadapi sebagian besar tim: menerima bahwa "sebagian selesai" adalah hal yang valid untuk di-commit, selama tersembunyi di balik flag dan tidak merusak test yang sudah ada sebelumnya.

Apa kata laporan DORA tentang kecepatan pengiriman

DevOps Research and Assessment (DORA) adalah penelitian empiris skala besar paling mendekati yang ada untuk praktik tim pengembangan software. Laporan DORA 2021 menemukan bahwa tim dengan performa elite 2,3 kali lebih mungkin menggunakan trunk-based development dibanding tim dengan performa lebih rendah.

Performer elite dalam framework DORA melakukan deployment beberapa kali per hari, dengan lead time dari commit ke produksi diukur dalam jam, bukan minggu. Trunk-based development berkorelasi secara konsisten dengan hasil-hasil tersebut.

Catatan penting: korelasi bukan kausalitas. Tim yang berprestasi tinggi mengadopsi trunk-based development karena mereka sudah berinvestasi dalam disiplin yang mendasarinya -- automated testing yang solid, infrastruktur CI/CD yang matang, dan engineer yang terbiasa menulis perubahan kecil dan terfokus. Fondasi tersebut harus ada lebih dulu. Trunk-based development adalah model branching yang cocok untuk konteks itu, bukan yang menciptakannya dari nol.

Biscuit langsung paham cara kerja ini: retriever yang baik tidak mencoba membawa tiga bola sekaligus. Satu commit, satu review, satu merge. Good boy.

Apakah trunk-based development layak untuk dicoba?

Jika tim kamu menghabiskan waktu sprint yang berarti untuk mengatasi konflik merge, menunda rilis karena "feature branch belum siap," atau memiliki branch yang terbuka begitu lama sampai tidak ada yang ingat untuk apa branch itu dibuat -- trunk-based development layak dievaluasi secara serius.

Ritme commit harian memang menuntut perubahan kebiasaan yang tidak sedikit. Infrastruktur feature flag membutuhkan waktu untuk disiapkan dengan baik. Pergeseran budaya tim membutuhkan beberapa minggu agar terasa natural bagi semua orang. Tapi hasilnya -- codebase yang selalu bisa dirilis, konflik merge yang diukur dalam baris bukan file, dan rilis yang rutin bukan krisis -- adalah peningkatan nyata dalam cara tim bekerja sehari-hari.

Mulai dari kecil: satu tim, satu sprint, CI berjalan pada setiap push, feature flags tersedia. Lihat apa yang berubah dalam empat minggu pertama.