Feature branch yang hidup selama berminggu-minggu sering terasa aman karena developer bisa bekerja tanpa mengganggu kode utama.
Masalahnya muncul ketika waktunya merge. Konflik bertumpuk, perubahan developer lain sudah jauh berbeda, dan proses integrasi berubah menjadi pekerjaan besar.
Menggunakan Trunk-Based Development menawarkan pola berbeda. Developer mengintegrasikan perubahan kecil ke satu branch utama secara rutin, biasanya setiap hari atau bahkan beberapa kali sehari.
Dengan jarak antara kode lokal dan kode bersama yang semakin kecil, integration problem dapat ditemukan lebih cepat dan proses software delivery menjadi lebih ringan.
Apa Itu Trunk-Based Development?
Trunk-Based Development adalah branching model ketika sebagian besar pekerjaan developer bergerak menuju satu branch utama, biasanya disebut main, master, atau trunk.
TrunkBasedDevelopment.com mendefinisikannya sebagai model ketika developer berkolaborasi pada satu trunk dan menghindari long-lived development branch. Branch pendek masih dapat digunakan, tetapi perubahan harus segera diintegrasikan kembali.
Artinya, pendekatan ini bukan berarti semua developer harus melakukan commit langsung ke main tanpa review.
Tim kecil mungkin memang bekerja langsung pada trunk. Tim yang lebih besar bisa menggunakan pull request dengan short-lived branch.
Yang terpenting adalah branch tersebut tidak hidup berminggu-minggu.
DORA merekomendasikan integrasi ke trunk setidaknya sekali sehari dan menghindari integration phase serta code freeze yang biasanya muncul akibat terlalu banyak long-lived branch.
Kenapa Long-Lived Branch Memperlambat Delivery?
Branch menciptakan jarak antara perubahan developer dan kondisi codebase terbaru.
Semakin lama branch hidup, semakin besar kemungkinan developer lain mengubah file, API, schema, atau komponen yang sama.
Bayangkan dua tim mengembangkan fitur selama tiga minggu.
Tim pertama mengubah model Customer, sedangkan tim kedua membuat sistem loyalty berdasarkan model lama.
Ketika keduanya digabungkan, Git mungkin hanya menunjukkan beberapa conflict. Namun semantic conflict bisa jauh lebih besar karena kedua fitur dibangun berdasarkan asumsi berbeda.
DORA menjelaskan bahwa long-lived branch menghasilkan merge event yang lebih besar dan kompleks. Akibatnya, organisasi sering membutuhkan stabilisation period atau code freeze sebelum release.
Dengan trunk-based workflow, perubahan lebih kecil dan frekuensi integrasi meningkat.
Konflik yang ditemukan hari ini biasanya jauh lebih mudah diperbaiki dibanding konflik yang baru ditemukan tiga minggu kemudian.
Pecah Pekerjaan Menjadi Batch Kecil
Trunk-Based Development sulit bekerja jika setiap ticket membutuhkan dua minggu sebelum dapat diintegrasikan.
Tim perlu belajar memecah pekerjaan menjadi perubahan kecil.
Misalnya perusahaan ingin membangun fitur wishlist.
Daripada membuat satu pull request berisi database schema, API, UI, notification, analytics, dan recommendation sekaligus, pecah menjadi beberapa perubahan.
Hari pertama tambahkan model data.
Hari berikutnya tambahkan API internal.
Kemudian integrasikan UI yang masih tersembunyi.
Setiap langkah dapat masuk trunk tanpa harus langsung menjadi fitur lengkap bagi pengguna.
Pendekatan ini membuat review lebih mudah.
Pull request 150 baris biasanya lebih gampang dipahami daripada perubahan 5.000 baris.
Risiko konflik juga mengecil karena developer tidak mempertahankan perubahan lokal terlalu lama.
Namun perubahan kecil bukan berarti commit sembarangan. Setiap integrasi harus tetap menjaga trunk dalam kondisi sehat dan dapat dibangun.
Jadikan Automated Testing sebagai Safety Net
Integrasi sering hanya aman jika feedback tersedia dengan cepat.
Setiap perubahan menuju trunk sebaiknya melewati build dan automated test.
Martin Fowler menjelaskan Continuous Integration sebagai praktik ketika developer mengintegrasikan perubahan secara sering, minimal setiap hari, sehingga integration error dapat ditemukan dan diperbaiki dengan cepat.
Ia juga menekankan bahwa pekerjaan developer seharusnya hanya berjarak beberapa jam dari shared project state.
Idealnya pipeline awal tidak membutuhkan waktu terlalu lama.
Unit test, compilation, linting, dan basic integration checks harus memberikan feedback secepat mungkin.
Fowler bahkan pernah menyarankan commit build selesai sekitar sepuluh menit atau kurang agar broken build dapat segera diperbaiki atau dikembalikan ke kondisi hijau.
Kalau pipeline membutuhkan satu jam, developer cenderung mengumpulkan perubahan lebih banyak sebelum merge.
Akibatnya batch kembali membesar.
Pipeline cepat dan branch pendek sebenarnya saling mendukung.
Gunakan Feature Flags untuk Fitur yang Belum Selesai
Pertanyaan yang sering muncul adalah, “Bagaimana memasukkan kode setiap hari kalau fiturnya belum selesai?”
Salah satu jawabannya adalah feature flags.
Microsoft menjelaskan bahwa feature flags memungkinkan kode fitur masuk production tetapi aksesnya tetap dinonaktifkan atau dibatasi. Deployment kode dapat dipisahkan dari keputusan kapan fitur tersedia bagi pengguna.
Misalnya tim sedang membuat checkout baru yang membutuhkan lima hari.
Kode dapat masuk trunk sedikit demi sedikit tetapi diletakkan di balik flag newCheckout.
Pengguna tetap memakai checkout lama sampai implementasi baru siap.
Setelah testing selesai, flag dapat diaktifkan untuk internal user, kemudian sebagian pelanggan, lalu seluruh pengguna.
Cara ini menghindari branch yang harus bertahan selama fitur dikembangkan.
Namun flag tetap harus dikelola.
Feature flag sementara yang sudah selesai sebaiknya dihapus agar tidak berubah menjadi technical debt dan menambah komplekistas logika aplikasi.
Jaga Code Review Tetap Ringan dan Cepat
Trunk-Based Development masih dapat menggunakan pull request.
Masalah muncul ketika review membutuhkan berhari-hari.
DORA menyebut heavyweight code review sebagai salah satu hambatan penerapan trunk-based development. Ketika developer harus menunggu terlalu lama, mereka cenderung mengumpulkan perubahan menjadi batch besar, yang kemudian membuat review semakin sulit.
Ciptakan feedback loop pendek.
Pull request kecil sebaiknya mendapat perhatian lebih cepat daripada perubahan besar yang dikirim sekali seminggu.
Batasi reviewer sesuai tingkat risiko.
Perubahan dokumentasi mungkin cukup satu reviewer, sedangkan sistem pembayaran bisa membutuhkan pemeriksaan lebih ketat.
Automated formatting, linting, unit test, dan static analysis juga membantu.
Jangan membuat manusia menghabiskan waktu untuk masalah yang bisa diperiksa mesin secara konsisten.
Code review akhirnya dapat fokus pada desain, risiko, dan logika bisnis.
Jangan Biarkan Broken Trunk Menjadi Normal
Satu kekhawatiran terbesar terhadap trunk-based workflow adalah kode utama mudah rusak.
Kekhawatiran itu valid jika tim tidak mempunyai disiplin.
Trunk sebaiknya diperlakukan sebagai shared asset yang harus selalu berada dalam kondisi sehat.
Jika perubahan membuat build gagal, prioritas tim adalah memperbaikinya atau melakukan revert, bukan melanjutkan pekerjaan lain seolah tidak terjadi apa-apa.
TrunkBasedDevelopment.com menekankan konsep don’t break the build serta pre-integration build sebagai bagian penting dari praktik ini.
Automated checks dapat menjadi merge gate.
Jika unit test gagal, perubahan tidak masuk.
Untuk area kritis, tambahkan integration atau contract testing secukupnya.
Tujuannya bukan menciptakan pipeline sepanjang dua jam, tetapi memperoleh confidence minimum sebelum perubahan bergabung dengan pekerjaan semua orang.
Trunk yang sering merah akan membuat developer kehilangan kepercayaan dan akhirnya mulai kembali membuat branch panjang sebagai perlindungan.
Gunakan Branch Pendek jika Direct Commit Tidak Cocok
Trunk-Based Development tidak memaksa semua organisasi menggunakan pola identik.
Tim yang membutuhkan mandatory review tetap dapat memakai branch.
Bedanya, branch harus memiliki umur pendek.
TrunkBasedDevelopment.com menyebut short-lived feature branch sebagai salah satu gaya yang tetap sejalan dengan pendekatan trunk-based, terutama ketika tim menggunakan pull request atau patch-review system.
Target praktisnya adalah merge pada hari yang sama atau sesegera mungkin.
Hindari branch bernama feature/new-platform-v2 yang terus berkembang selama dua bulan.
Untuk perubahan besar, gunakan teknik seperti branch by abstraction.
Implementasi baru dapat dibangun di balik interface sambil kode lama tetap berfungsi.
Setiap bagian kemudian diintegrasikan sedikit demi sedikit tanpa menciptakan satu merge raksasa.
Pendekatan tersebut membuat perubahan besar menjadi serangkaian perubahan kecil yang dapat diverifikasi.
Ukur Dampaknya terhadap Delivery
Jangan menerapkan branching strategy hanya karena dianggap best practice.
Ukur hasilnya.
Pantau waktu dari coding sampai merge, umur pull request, ukuran perubahan, frekuensi merge conflict, build failure, dan lead time menuju production.
DORA menyatakan praktik seperti memiliki sedikit active branch, merge setidaknya sekali sehari, dan menghindari integration phase berkaitan dengan tingkat software delivery serta operational performance yang lebih tinggi berdasarkan analisis data mereka.
Namun setiap organisasi tetap perlu melihat kondisi sendiri.
Jika setelah migrasi branch menjadi lebih pendek tetapi pipeline terus gagal, masalah berikutnya mungkin kualitas testing.
Jika review menjadi bottleneck, perbaiki proses review.
Trunk-Based Development bukan satu teknik tunggal. Ia membutuhkan integrasi antara workflow Git, automated test, CI, desain fitur, dan kebiasaan tim.
Menggunakan Trunk-Based Development dapat mempercepat delivery dengan mengurangi long-lived branch, memperkecil batch perubahan, dan menemukan integration problem lebih awal.
Kombinasikan short-lived branch, automated testing, review cepat, serta feature flags agar trunk tetap sehat. Mulailah dengan mengukur usia branch saat ini, lalu dorong tim mengintegrasikan perubahan kecil setidaknya setiap hari.