Banyak tim merasa sudah menjalankan Continuous Integration karena setiap feature branch memiliki pipeline otomatis.
Padahal jika branch tersebut baru digabungkan setelah dua minggu, integration problem tetap ditunda sampai mendekati akhir pekerjaan. Menggunakan Trunk-Based Development mengubah pola tersebut dengan membuat integrasi sebagai aktivitas harian.
Developer menjaga perubahan tetap kecil dan terus menyelaraskannya dengan trunk. Pendekatan ini dapat mengurangi merge conflict sekaligus membuat proses menuju production lebih lancar.
Namun keberhasilannya membutuhkan lebih dari aturan Git: testing cepat, desain fitur bertahap, dan budaya menjaga branch utama tetap sehat juga sangat penting.
CI Tool Belum Tentu Berarti Continuous Integration
Memiliki Jenkins, GitHub Actions, atau platform CI lain belum otomatis berarti sebuah tim melakukan Continuous Integration.
Tool hanya menjalankan automation.
Martin Fowler menjelaskan bahwa banyak organisasi menjalankan automated build pada feature branch, tetapi developer sebenarnya belum mengintegrasikan pekerjaannya ke shared mainline secara rutin.
Ia menghubungkan Continuous Integration dengan integrasi yang dilakukan setidaknya setiap hari.
TrunkBasedDevelopment.com memberikan pandangan serupa: individu melakukan Trunk-Based Development, sementara tim menjalankan praktik Continuous Integration ketika perubahan berkumpul pada integration point yang sama secara rutin.
Perbedaannya terasa kecil, tetapi efeknya besar.
Pipeline pada branch hanya menjawab, “Apakah perubahan saya bekerja sendiri?”
Integrasi ke trunk menjawab, “Apakah perubahan saya bekerja bersama perubahan orang lain?”
Pertanyaan kedua jauh lebih penting untuk software yang akhirnya akan dirilis sebagai satu sistem.
Kurangi Jarak antara Developer dan Trunk
Bayangkan developer A membuat branch hari Senin.
Developer B, C, dan D melakukan puluhan perubahan ke main selama minggu tersebut.
Jika developer A baru merge Jumat sore, branch-nya sudah membawa asumsi dari kondisi codebase empat hari lalu.
TrunkBasedDevelopment.com menggambarkan branch sebagai jarak dari integration point. Semakin besar jaraknya, semakin banyak konflik atau incompatibility yang berpotensi baru terlihat saat merge.
Solusinya bukan melakukan merge lebih pintar.
Kurangi jaraknya.
Integrasikan perubahan lebih cepat.
DORA menyebut small and frequent merges sebagai salah satu manfaat utama trunk-based approach karena jumlah development line lebih sedikit dan merge event menjadi lebih sederhana.
Ketika branch hanya hidup beberapa jam, kemungkinan codebase berubah drastis jauh lebih kecil.
Merge kemudian menjadi aktivitas biasa, bukan mini-project.
Desain Fitur agar Bisa Diintegrasikan Sebelum Selesai
Hambatan terbesar biasanya bukan Git, tetapi ukuran pekerjaan.
Developer berkata, “Fitur ini belum bisa di-merge karena belum selesai.”
Masalahnya mungkin fitur tersebut terlalu besar sebagai satu unit integrasi.
Pecah berdasarkan perubahan teknis yang masih menjaga aplikasi tetap berfungsi.
Misalnya migrasi search engine dapat dimulai dengan membuat abstraction baru.
Tahap berikutnya menambahkan implementation baru.
Setelah itu lakukan shadow request untuk membandingkan hasil.
Baru kemudian traffic dipindahkan.
Setiap langkah dapat masuk trunk tanpa menunggu migrasi selesai total.
Teknik semacam branch by abstraction berguna untuk perubahan besar karena memungkinkan implementasi lama dan baru hidup berdampingan selama periode transisi.
Trunk-based guidance juga memasukkan abstraction dan feature flags sebagai teknik penting untuk perubahan yang tidak dapat diselesaikan dalam satu batch kecil.
Dengan demikian, arsitektur kode ikut menentukan seberapa cepat tim bisa berintegrasi.
Gunakan Feature Flags untuk Memisahkan Merge dan Release
Tidak semua kode yang masuk trunk harus langsung digunakan pelanggan.
Feature flags memisahkan integrasi kode dari exposure fitur.
Microsoft menjelaskan bahwa feature flag dapat membuat fungsi baru sudah berada dalam production environment tetapi hanya tersedia untuk kelompok tertentu atau masih sepenuhnya dinonaktifkan.
Pendekatan ini juga mendukung trunk-based development karena mengurangi kebutuhan long-running feature branch.
Misalnya tim mengembangkan dashboard baru.
Kode hari pertama bisa masuk trunk tetapi newDashboard=false.
Setelah beberapa hari dan automated test makin lengkap, flag diaktifkan untuk tim internal.
Kemudian rollout diperluas ke 5%, 20%, dan akhirnya seluruh pengguna.
Developer tetap melakukan integrasi setiap hari tanpa memaksa feature release setiap hari.
Ini adalah perbedaan penting antara deployment dan release.
Namun jangan menjadikan feature flags tempat menyembunyikan kode setengah jadi selamanya.
Catat owner, tujuan, dan waktu penghapusan flag agar tidak menambah konfigruasi permanen yang sulit dilacak.
Buat Main Branch Selalu dalam Kondisi Releasable
Trunk-Based Development sangat bergantung pada satu asumsi: trunk sehat.
Jika branch utama sering rusak selama berjam-jam, developer lain tidak memiliki integration point yang dapat dipercaya.
Karena itu, quality gate menjadi penting.
Sebelum perubahan masuk, jalankan compilation, unit testing, linting, dan test penting lain yang cukup cepat.
TrunkBasedDevelopment.com menjelaskan bahwa pre-integration build dapat mencakup compile, unit test, service test, dan functional test yang relevan sebelum perubahan tersedia untuk anggota tim lainnya.
Namun jangan membuat gate terlalu berat.
Pipeline empat puluh menit akan mendorong developer mengirim perubahan lebih jarang dan lebih besar.
Cari minimum test set yang memberikan confidence cepat, kemudian jalankan test berat di tahap pipeline lain.
Jika trunk rusak, prioritaskan fix atau revert.
Kultur “biarkan merah dulu, besok diperbaiki” akan menghancurkan kepercayaan terhadap shared branch dan akhirnya membuat developer kembali membuat cabang proteksi masing-masing.
Optimalkan Code Review untuk Batch Kecil
Pull request tetap bisa digunakan dalam Trunk-Based Development.
Namun cara review-nya perlu menyesuaikan.
DORA menyoroti heavy code-review process sebagai pitfall karena waktu tunggu berjam-jam atau berhari-hari mendorong developer membuat batch lebih besar. Review besar kemudian membutuhkan waktu lebih lama, menciptakan siklus yang semakin buruk.
Targetkan perubahan kecil yang mudah direview.
Misalnya 100–300 baris perubahan fokus biasanya lebih mudah dipahami daripada pull request 4.000 baris dengan lima tujuan sekaligus.
Tidak ada angka universal, tetapi prinsipnya jelas: semakin kecil scope, semakin mudah reviewer memahami konsekuensinya.
Automasi hal mekanis.
Formatting, linting, dependency scanning, dan basic tests tidak perlu menunggu komentar manusia.
Reviewer sebaiknya fokus pada logic, architecture, security, serta maintainability.
Dengan feedback lebih cepat, branch tidak perlu bertahan lama hanya karena antrean review.
Gunakan Release Branch Hanya jika Memang Dibutuhkan
Tidak semua produk dapat deploy langsung dari trunk.
Mobile application, embedded software, atau produk dengan beberapa versi yang masih didukung mungkin tetap membutuhkan release branch.
Trunk-based approach tidak melarangnya.
DORA menjelaskan release branch dapat berupa snapshot dari trunk ketika software siap dirilis. Bug fix pada release tertentu kemudian tetap digabungkan kembali menuju trunk agar codebase utama tidak kehilangan perubahan.
Namun jangan mengubah release branch menjadi jalur development kedua.
Fitur baru tetap berkembang di trunk.
Release branch hanya digunakan untuk maintenance versi yang memang masih perlu didukung.
Pada tim yang melakukan release beberapa kali sehari, DORA bahkan mencatat release branch mungkin tidak diperlukan sama sekali karena perubahan dapat langsung dikirim dari trunk.
Semakin sedikit active development line, semakin sedikit pula koordinasi merge yang harus dipelihara.
Terapkan Secara Bertahap, Bukan Mendadak
Tim yang terbiasa branch sebulan penuh tidak perlu langsung memaksa semua developer commit ke trunk besok pagi.
Mulailah dengan memperpendek branch.
Jika rata-rata branch hidup tujuh hari, coba turunkan menjadi dua atau tiga hari.
Kemudian targetkan satu hari.
Pada saat bersamaan, perbaiki pipeline dan pola slicing pekerjaan.
Cari bagian yang membuat developer sulit melakukan merge kecil.
Mungkin automated testing lambat, code review menumpuk, atau aplikasi terlalu coupled sehingga perubahan kecil mustahil dilakukan.
Trunk-Based Development sering mengungkap problem engineering yang sebelumnya tersembunyi oleh branch.
Jangan menganggap itu kegagalan.
Gunakan hambatan tersebut sebagai daftar perbaikan.
DORA menekankan indikator seperti tiga atau lebih sedikit active branches, merge harian, serta tidak adanya code freeze dan integration phase sebagai karakteristik praktik trunk-based yang lebih matang.
Perubahan kebiasaan biasanya lebih penting daripada mengganti tool Git.
Hubungkan dengan Continuous Delivery
Nilai akhirnya bukan sekadar repository lebih rapi.
Tujuannya adalah memperpendek jarak dari perubahan kode menuju pengguna.
TrunkBasedDevelopment.com menyebut Trunk-Based Development sebagai enabler penting Continuous Integration dan, pada akhirnya, Continuous Delivery karena codebase bersama terus diperbarui dan dapat dipertahankan dalam kondisi siap dirilis.
Ketika perubahan kecil terus masuk trunk, pipeline dapat menguji dan men-deploy batch yang lebih kecil.
Jika terjadi masalah, perubahan yang perlu diperiksa juga lebih sedikit.
Rollback menjadi lebih jelas.
Feedback production datang lebih cepat.
Tim akhirnya mengganti pola “develop lama, integrate lama, release besar” menjadi “develop kecil, integrate cepat, validasi, release ketika siap”.
Di sinilah keuntungan delivery sesungguhnya muncul.
Bukan karena branch utama memiliki nama main, tetapi karena integration risk diproses terus-menerus daripada dikumpulkan sampai akhir.
Menggunakan Trunk-Based Development membantu tim memperpendek jarak antara coding, integrasi, dan delivery melalui branch singkat serta perubahan kecil.
Keberhasilannya membutuhkan CI cepat, feature flags, review ringan, dan trunk yang selalu sehat. Mulailah secara bertahap: ukur umur branch dan waktu review saat ini, lalu jadikan integrasi harian sebagai target pertama tim.