Pengembangan berbasis trunk vs GitFlow untuk pengiriman mingguan

Mengapa pengiriman mingguan bisa kacau dengan model branching yang salah

Pengiriman mingguan terdengar sederhana sampai minggu ketika Anda kehilangannya. Build "hampir siap" pada hari Kamis, QA menemukan masalah Jumat sore, dan Senin berubah menjadi pembersihan bukannya awal yang bersih.

Salah satu penyebab utama adalah model branching Anda. Ia menentukan kapan perubahan bertemu, di mana integrasi terjadi, dan seberapa cepat Anda bisa pulih saat sesuatu rusak. Jika integrasi ditunda hingga akhir minggu, Anda membayarnya dengan konflik merge, bug kejutan, dan lingkungan pengujian yang goyah.

Saat alur kerja bekerja melawan Anda, biasanya terasa seperti ini:

• Merge memakan waktu lebih lama daripada pekerjaan fitur yang menyebabkannya.
• QA menguji campuran perubahan yang salah karena cabang menyimpang.
• Rilis menjadi negosiasi daripada rutinitas.
• Hotfix memicu kepanikan karena tidak ada yang yakin apa lagi yang akan dikirim.
• Orang berhenti mempercayai QA dan mulai meminta pengecualian.

Branching juga membentuk stabilitas QA. Jika QA terus bolak-balik antara jalur kode yang setengah-terintegrasi, ia menjadi target yang bergerak. Bahkan tester yang kuat pun tidak bisa memberi jawaban jelas ketika sistem yang diuji berubah setiap beberapa jam, atau merge terlambat diam-diam menggantikan apa yang mereka uji kemarin.

Itulah mengapa tim sering membandingkan pengembangan berbasis trunk dan GitFlow saat beralih ke ritme rilis mingguan. Pertanyaan yang berguna bukanlah mana yang populer. Melainkan mana yang mengurangi rasa sakit merge, menjaga rilis dapat diprediksi, membuat hotfix aman dan cepat, serta menjaga QA tetap bermakna.

Asumsikan tim kecil hingga menengah, satu repo bersama, CI berjalan pada setiap push. Mungkin Anda mengirim web app dan API. Atau bagian tim membangun secara visual di platform seperti AppMaster sambil tetap mengelola kode yang dihasilkan dan deployment seperti tim produk lain.

Jika proses Anda saat ini menghasilkan merge besar di akhir minggu, cadence mingguan Anda akan terus tertunda. Jika ia mendorong integrasi kecil dan sering, rilis mingguan mulai terasa membosankan (dalam arti terbaik).

Pengembangan berbasis trunk dan GitFlow dalam bahasa sederhana

Kedua pendekatan hanyalah aturan tentang bagaimana Anda menggunakan cabang supaya pekerjaan bisa dari "sedang dikerjakan" menjadi "dirilis" tanpa kekacauan. Perbedaan nyata adalah berapa banyak cabang berumur panjang yang Anda pertahankan, dan berapa lama pekerjaan tetap terpisah sebelum bertemu kode orang lain.

• Trunk-based menjaga hampir semua tetap dekat dengan main.
• GitFlow menjaga jalur terpisah untuk pekerjaan yang sedang berjalan dan stabilisasi rilis.

Pengembangan berbasis trunk (dalam istilah sederhana)

Pengembangan berbasis trunk memperlakukan main (trunk) sebagai pusat. Orang bekerja di cabang berumur pendek (beberapa jam sampai sehari dua), sering melakukan merge kembali, dan menjaga main dalam keadaan dapat dirilis.

Jika sesuatu belum siap, Anda membuatnya cukup kecil untuk diselesaikan cepat, atau menyembunyikannya di balik feature flag sehingga bisa dikirim dengan aman tanpa terlihat.

GitFlow (dalam istilah sederhana)

GitFlow biasanya menggunakan cabang develop yang berumur panjang tempat fitur mendarat dulu, plus cabang fitur dari develop. Menjelang rilis, Anda memotong cabang release/* untuk stabilisasi dan pengujian. Jika produksi bermasalah, Anda memotong cabang hotfix/* (sering dari main) dan menggabungkannya kembali.

Model ini mengoptimalkan pemisahan: pekerjaan yang sedang berjalan bisa lanjut di develop sementara cabang rilis diuji dan diperbaiki.

Banyak rasa sakit muncul dari kesalahpahaman umum:

• Menganggap trunk-based berarti "tanpa cabang" (sebenarnya masih menggunakan cabang, tapi berumur pendek).
• Menggunakan GitFlow tapi tidak pernah membuat cabang rilis yang nyata, sehingga develop menjadi area staging yang tidak stabil.
• Membiarkan cabang fitur hidup berminggu-minggu, yang mengubah model apa pun menjadi masalah merge.
• Membingungkan "bisa dirilis" dengan "semua sudah selesai" alih-alih "aman untuk dideploy."

Gesekan merge: apa yang sebenarnya menyebabkannya

Konflik merge biasanya datang dari dua sumber: cabang yang hidup terlalu lama, dan banyak orang mengubah area yang sama tanpa koordinasi.

Perbedaan praktis terbesar antara trunk-based dan GitFlow adalah berapa lama pekerjaan tetap terpisah sebelum bertemu pekerjaan lain.

Dengan pengembangan berbasis trunk, perubahan sering mengenai garis utama. Pull request lebih kecil, diff lebih sedikit, dan konflik muncul lebih awal saat konteksnya masih segar. Konflik masih terjadi, tetapi biasanya lebih mudah diselesaikan karena Anda merekonsiliasi beberapa baris, bukan dua minggu penyimpangan. Tradeoff-nya adalah disiplin: jaga build tetap hijau, buat perubahan bertahap, dan perlakukan main seperti produk.

Dengan GitFlow, pekerjaan fitur bisa bertahan lebih lama tanpa memengaruhi pengembang lain sehari-hari. Biayanya terlihat kemudian sebagai event merge yang lebih besar: fitur ke develop, develop ke release/*, dan release/* ke main. Setiap merge adalah pertemuan perubahan yang lebih besar, jadi konflik lebih mungkin dan lebih sulit diurai. Untuk pengiriman mingguan, merge besar itu cenderung terjadi saat tim ingin melakukan pengujian.

Beban review kode juga bergeser. Trunk-based biasanya berarti lebih banyak review, tetapi masing-masing lebih cepat dipahami. GitFlow sering berarti review lebih sedikit tapi berat, plus waktu review ekstra saat merge rilis ketika semua orang lelah.

Untuk mengurangi gesekan merge di kedua model:

• Buat PR kecil dan terfokus (satu tujuan per PR).
• Sepakati kepemilikan area berisiko (migrasi, konfigurasi bersama, UI inti).
• Tarik perubahan upstream setiap hari agar Anda tidak menyimpang.
• Jika sebuah file terus-menerus "panas," kerjakan secara berpasangan daripada saling berlomba.

Jika konflik terasa konstan, biasanya itu tanda Anda mengintegrasikan terlambat, bukan Git yang bermasalah.

Prediktabilitas rilis untuk cadence mingguan

Prediktabilitas berarti tiga hal: Anda tahu kapan rilis keluar, Anda tahu apa yang ada di dalamnya, dan Anda tahu pemeriksaan apa yang harus lulus sebelum dikirim. Tim biasanya melewatkan rilis mingguan karena mencampur keputusan cakupan dengan perbaikan menit-menit terakhir.

Dalam pengembangan berbasis trunk, rilis mingguan tetap dapat diprediksi ketika main tetap hijau. Anda menggabungkan perubahan kecil sering dan mengendalikan cakupan dengan feature flag alih-alih cabang berumur panjang. Itu menjaga kereta rilis mingguan tetap berjalan bahkan jika sebuah fitur belum selesai. Kode bisa mendarat, tapi perilaku yang terlihat pengguna tetap mati sampai siap.

Gerbang kualitas seringkali lebih sederhana karena ada satu tempat untuk memvalidasi:

• Tes otomatis harus lulus di main.
• QA menguji kandidat build yang stabil, bukan apa pun yang mendarat jam lalu.
• Langkah rollout dan rollback tertulis.
• Ada batas waktu rilis yang jelas (meskipun commit terus mendarat).

Di GitFlow, prediktabilitas datang dari cabang rilis yang berfungsi seperti zona beku. Anda memilih cutoff, membuat release/*, dan hanya mengizinkan perubahan yang diperlukan untuk dikirim. Batas itu membantu, tetapi menambah koordinasi karena perbaikan biasanya harus diterapkan di lebih dari satu tempat (release dan develop).

Pekerjaan yang belum selesai ditangani berbeda:

• Trunk-based: gabungkan bagian yang aman dan simpan sisanya di balik flag.
• GitFlow: biarkan pekerjaan belum selesai di develop dan kecualikan dari cabang rilis.

Contoh: jika perbaikan checkout setengah jadi pada Rabu, trunk-based bisa menggabungkan refaktor aman dan menyembunyikan UI baru. GitFlow biasanya menyimpannya di develop, mengirim tanpa itu, dan menyelesaikannya untuk rilis mingguan berikutnya.

Alur hotfix: jalur tercepat dan aman ke produksi

Hotfix bukan pekerjaan normal. Ia butuh kecepatan, risiko rendah, dan jalur yang membawa perubahan kembali ke tempat tim bekerja agar Anda tidak memperbaiki bug yang sama dua kali.

Mulailah dengan satu pertanyaan: kode apa yang persis berjalan di produksi sekarang? Jika Anda tidak bisa menjawab itu dalam hitungan detik, hotfix berubah menjadi tebak-tebakan.

Hotfix dengan pengembangan berbasis trunk

Hotfix trunk-based bisa terasa lebih sederhana karena main diperlakukan sebagai sumber kebenaran.

Alur umum:

• Buat cabang berumur pendek dari commit produksi (sering main).
• Lakukan perbaikan sekecil mungkin (tambahkan tes jika bisa).
• Merge kembali ke main dengan cepat.
• Deploy dari main dan beri tag rilis.

Karena tim sering mengintegrasi ke main, hotfix secara alami menjadi bagian dari rilis mingguan berikutnya. Risiko utamanya adalah melanggar aturan "main harus bisa dirilis" dengan membiarkan pekerjaan setengah jadi berada di main. Feature flag membantu, tapi matikan secara default dan verifikasi hotfix tanpa mengaktifkan fitur yang tidak terkait.

Hotfix dengan GitFlow

Di GitFlow, hotfix biasanya dimulai dari main (produksi), lalu harus di-merge kembali ke develop agar perbaikan tidak hilang.

Alur aman:

• Cabang hotfix/* dari main pada tag produksi.
• Perbaiki dan rilis (baik dari cabang hotfix atau setelah merge ke main).
• Merge hotfix ke main dan juga ke develop.
• Jika ada cabang release/*, merge ke sana juga.

Kegagalan paling umum adalah lupa salah satu merge itu. Seminggu kemudian, bug "kembali" karena develop tidak pernah mendapat patch.

Aturan sederhana mencegah sebagian besar ini: hotfix belum selesai sampai di-merge ke setiap cabang jangka panjang yang akan dikirim lagi.

Cara menjaga lingkungan QA stabil (tanpa menghambat tim)

Pengiriman mingguan runtuh ketika "QA" berarti "apa saja yang dideploy sekarang." Namai lingkungan Anda dan beri setiap lingkungan satu tugas: dev untuk umpan balik cepat, QA untuk pengujian tim, staging untuk pengecekan rilis, prod untuk pelanggan. Jika Anda tidak bisa menjelaskan tujuan lingkungan dalam satu kalimat, orang akan menggunakannya secara salah.

Aturan yang mencegah target yang bergerak

QA yang stabil lebih tentang apa yang Anda deploy daripada model branching Anda.

Dalam kerja trunk-based, jangan deploy commit acak ke QA. Deploy kandidat yang dipin (build yang ditandai, nomor build, atau cabang release-candidate sementara) yang lulus pemeriksaan yang sama setiap kali. QA mendapat sesuatu yang tetap untuk diuji, sementara pengembangan berlanjut di main.

Di GitFlow, QA biasanya mengikuti cabang rilis. Jeratnya adalah membiarkan cabang rilis terus berubah setelah QA mulai. Setelah QA dimulai, perlakukan cabang rilis seperti kontrak: terima hanya perbaikan yang disetujui, dan hanya melalui proses yang jelas.

Sekumpulan aturan kecil menjaga kedua pendekatan tetap dapat diprediksi:

• Deploy ke QA hanya dari build yang lulus.
• Pin versi yang dideploy (tag, nomor build, atau head cabang rilis) dan umumkan.
• Batasi perubahan QA pada perbaikan bug, bukan fitur baru.
• Reset data uji secara terjadwal dan dokumentasikan apa yang dihapus.
• Simpan konfigurasi sebagai kode (variabel dan template) untuk mengurangi perbedaan lingkungan.

Jika tim Anda menggunakan AppMaster untuk sebagian build, pegang prinsip yang sama: regenerasi dan deploy build tertentu untuk QA, bukan rangkaian edit yang terus berubah.

Saat beberapa tim berbagi QA

Satu lingkungan QA bersama menjadi hambatan saat dua tim membutuhkan versi berbeda. Jika Anda tidak mampu lingkungan QA terpisah, tambahkan aturan reservasi ringan: satu tim menguasai QA untuk jendela waktu, dan yang lain menggunakan dev atau staging. Feature flag juga membantu karena pekerjaan yang belum selesai dapat dideploy tanpa terlihat oleh tester.

Contoh: Tim A memvalidasi kandidat rilis mingguan, jadi QA dipin ke build 1842 sampai tanda tangan. Tim B bisa terus menggabungkan perbaikan, tetapi perubahan itu menunggu kandidat berikutnya alih-alih mengubah apa yang diuji QA di tengah siklus.

Langkah demi langkah: pilih alur kerja yang bisa tim Anda ikuti setiap minggu

Tuliskan apa arti "pengiriman mingguan" bagi Anda. Pilih hari dan jam rilis, tentukan tingkat risiko yang dapat diterima (misalnya, "tidak ada bug P1 yang diketahui"), dan catat ukuran tim serta zona waktu. Ini mencegah perdebatan cabang berubah menjadi argumen prioritas.

Pilih satu model dasar dan patuhi selama sebulan. Jangan campur model di hari pertama. Pencampuran biasanya menambah aturan tanpa mengurangi kejutan.

Alur kerja mingguan sederhana yang bisa Anda sesuaikan:

• Jaga umur cabang pendek (beberapa jam hingga 1-2 hari) dan merge setidaknya setiap hari.
• Tambahkan pengaman: CI cepat, review singkat yang diwajibkan, dan seperangkat tes otomatis kecil yang menangkap kerusakan nyata.
• Putuskan bagaimana mengontrol cakupan: feature flag, cabang rilis pendek di dekat akhir minggu, atau tag untuk commit rilis yang tepat.
• Definisikan langkah hotfix: siapa yang bisa memicunya, pemeriksaan apa yang diperlukan, dan bagaimana perbaikan kembali ke garis utama.
• Jaga QA stabil: tentukan apa yang diikuti QA (cabang rilis atau kandidat yang dipin) dan jangan ubahnya di tengah tes kecuali Anda memulai ulang siklus.

Tuliskan alur kerja minimum di satu halaman. Harus cukup singkat sehingga rekan baru bisa mengikutinya tanpa pertemuan. Ini lebih penting lagi jika sebagian tim bekerja secara visual (misalnya, di AppMaster) dan sebagian bekerja di kode, karena serah terima gagal saat aturan hanya hidup di kepala seseorang.

Contoh: rilis mingguan yang realistis di kedua model

Bayangkan tim produk 6 orang yang mengirim setiap Jumat. Dua tester QA berbagi satu lingkungan staging, jadi jika staging tidak stabil, pengujian berhenti untuk semua orang.

Minggu sibuk dengan GitFlow

Senin: tiga pengembang menyelesaikan fitur dan membuka pull request ke develop. QA mulai menguji staging yang dibangun dari develop.

Rabu: tim memotong release/1.8 untuk melindungi pengiriman Jumat. Pekerjaan baru terus mendarat di develop, tetapi QA sekarang fokus pada build rilis.

Kamis sore: bug terlambat muncul. Perbaikan masuk ke release/1.8 dulu agar QA bisa retest cepat. Lalu seseorang menggabungkan perbaikan itu kembali ke develop, yang sering menjadi sumber kesalahan.

Ritme tipikal:

• Senin-Selasa: fitur merge ke develop, staging berubah sering.
• Rabu: buat release/1.8, staging beralih ke build rilis.
• Kamis: perbaikan di release/1.8, lalu merge kembali ke develop.
• Jumat: merge release/1.8 ke main, tag dan deploy.

Minggu yang sama dengan pengembangan berbasis trunk

Minggu dibentuk oleh merge kecil dan sering ke main. Fitur dikirim di balik flag sehingga pekerjaan yang belum selesai bisa digabung tanpa memengaruhi pengguna.

Senin sampai Kamis: pengembang menggabungkan perubahan kecil setiap hari. QA menguji kandidat build yang dipin.

Selasa: isu produksi muncul. Hotfix adalah cabang pendek dari main, segera di-merge setelah review, lalu dipromosikan ke produksi. Karena main adalah sumber kebenaran, tidak ada langkah merge balik ekstra.

Bagaimanapun, tim membutuhkan aturan promosi yang jelas:

• Staging menjalankan kandidat build yang dipin, bukan setiap commit baru.
• QA meminta kandidat baru saat siap, bukan otomatis.
• Hanya perbaikan untuk rilis Jumat yang dapat mengubah kandidat.
• Segala hal lain menunggu di balik flag atau tetap keluar dari kandidat.

Kesalahan umum yang menciptakan churn dan QA tidak stabil

Kebanyakan tim tidak gagal karena memilih model yang "salah." Mereka gagal karena kebiasaan sehari-hari tidak sesuai dengan model, sehingga QA menjadi bising dan rilis terasa acak.

Masalah umum adalah membiarkan cabang hidup berhari-hari karena "belum siap." Kode menyimpang dari main, konflik menumpuk, dan QA akhirnya menguji campuran pekerjaan lama dan baru yang tak ada yang bisa mereproduksinya.

Lainnya adalah menggunakan GitFlow tanpa pembekuan nyata. Cabang rilis seharusnya menstabilkan, tetapi tim terus menyelipkan "satu perubahan lagi." Itu mengubah cabang rilis menjadi garis utama kedua, dan tak ada yang tahu apa yang QA setujui.

QA juga menjadi tidak stabil ketika diperlakukan seperti tempat pembuangan build setengah jadi. Jika setiap commit pergi ke QA tanpa aturan, tester menghabiskan waktu mengejar target yang selalu bergerak daripada memvalidasi rilis.

Kesalahan yang menciptakan paling banyak churn:

• Cabang fitur berumur panjang yang merge terlambat dan memecah kerja tak terkait.
• Cabang rilis yang masih menerima fitur baru.
• Tidak ada jalur promosi yang jelas, sehingga build yang diuji QA bukan build yang dikirim.
• Hotfix dilakukan terburu-buru, lalu tidak di-merge kembali ke semua tempat.
• Lingkungan tanpa pemilik, tanpa tujuan, dan tanpa rencana reset.

Jaga seperangkat aturan yang bisa diulang semua orang:

• QA hanya menguji kandidat yang dipin.
• Anda mempromosikan artefak yang sama dari QA ke produksi.
• Setiap lingkungan punya pemilik dan jadwal reset.
• Hotfix kembali ke garis utama pada hari yang sama.

Daftar periksa cepat untuk pengiriman mingguan tanpa kejutan

Pengiriman mingguan berhasil ketika tim Anda bisa menjawab beberapa pertanyaan membosankan dengan percaya diri. Jika Anda menjawab "tidak" pada dua atau lebih, harapkan perbaikan terlambat dan QA jadi tersiram.

• Apakah ada satu cabang yang bisa Anda deploy dengan aman hari ini? Harusnya bisa dibangun, lulus smoke test, dan menghindari perubahan setengah jadi.
• Apakah pull request tetap kecil dan mendarat dalam satu atau dua hari? PR berumur panjang biasanya berarti umpan balik basi dan konflik lebih besar.
• Apakah QA menguji build tetap, bukan target yang bergerak? QA harus memvalidasi nomor build tertentu atau kandidat rilis.
• Bisakah Anda menjaga pekerjaan belum selesai keluar dari rilis tanpa drama? Feature flag, toggle konfigurasi, atau aturan pemotongan cakupan yang jelas.
• Bisakah seseorang menjalankan hotfix dan rollback tanpa menebak-nebak? Runbook singkat mengalahkan pengetahuan suku.

Jika Anda mau satu tujuan terukur: pin QA ke kandidat rilis dan jangan ubah kandidat itu kecuali untuk perbaikan yang disengaja.

Langkah selanjutnya: pilih satu perubahan untuk dicoba minggu depan

Jika tim Anda terjebak berdebat trunk-based vs GitFlow, jangan desain ulang semuanya sekaligus. Pilih satu masalah yang paling banyak menghabiskan waktu dan jalankan eksperimen kecil untuk rilis berikutnya.

Jika konflik merge adalah masalah terbesar, singkatkan umur cabang segera. Targetkan mendarat setiap hari (atau setiap dua hari), gunakan feature flag bila perlu.

Jika ketidakstabilan QA adalah masalah terbesar, mulailah dengan mempin apa yang diuji QA dan mendefinisikan langkah promosi sederhana.

Pilot ringan:

• Pilih satu repo dan satu tim.
• Tetapkan batas usia cabang (misalnya, tidak ada cabang lebih tua dari 2 hari).
• Pin QA ke satu build dan ubahnya hanya melalui promosi eksplisit.
• Lacak tiga angka: waktu penyelesaian merge, jam kerja rework QA, dan waktu hotfix ke produksi.
• Tinjau setelah 2–4 minggu dan sesuaikan.

Jika Anda ingin mengurangi tekanan rilis untuk alat internal atau portal pelanggan, platform no-code seperti AppMaster (appmaster.io) juga bisa membantu dengan menghasilkan backend, web, dan aplikasi mobile produksi dari desain visual. Ia tetap mendapat manfaat dari kebiasaan yang sama di atas: perubahan kecil, kandidat QA yang dipin, dan jalur promosi yang jelas.