Merge queue adalah mekanisme untuk memastikan pull request tidak langsung masuk ke branch utama hanya karena lulus CI pada commit yang sudah tidak relevan. Untuk tim yang sering melihat branch utama merah setelah beberapa PR digabung hampir bersamaan, merge queue memaksa validasi dilakukan terhadap urutan merge yang benar sehingga main tetap hijau lebih konsisten.

Masalah yang diselesaikan bukan sekadar "antrian merge", melainkan validasi terhadap state yang akan benar-benar masuk ke branch utama. Ini penting ketika ada race condition antar PR, hasil check yang basi karena base branch berubah, atau rerun CI yang lulus pada kombinasi kode yang tidak pernah benar-benar ada di main.

Masalah yang Diselesaikan Merge Queue

1. Race condition antar PR

Contoh umum: PR A dan PR B sama-sama lulus CI saat masih berbasis pada commit main yang sama. Keduanya aman jika diuji sendiri-sendiri. Namun ketika A digabung lebih dulu, B sebenarnya perlu diuji ulang terhadap state baru dari main. Jika B tetap digabung berdasarkan hasil check lama, branch utama bisa langsung merah.

Masalah ini makin sering muncul bila:

  • Tim menggabungkan banyak PR per hari.
  • Durasi CI cukup lama sehingga beberapa PR menumpuk.
  • Ada test integrasi, migrasi database, kontrak API, atau dependency yang saling memengaruhi.
  • Developer sering menekan tombol rerun tanpa memastikan hasil test masih relevan terhadap base branch terbaru.

2. Status check basi

Status check pada PR bisa berstatus hijau, tetapi sebenarnya hijau untuk commit yang sudah tertinggal dari branch utama. Branch protection yang hanya mensyaratkan "semua check lulus" tanpa memastikan check tersebut dijalankan pada base branch terbaru sering memberi rasa aman palsu.

3. Rerun CI yang tidak merepresentasikan merge akhir

Ketika CI gagal flakey lalu di-rerun sampai lulus, hasil akhir bisa terlihat hijau. Namun jika rerun dilakukan pada snapshot commit yang sudah tidak lagi sesuai dengan state branch utama, hasil itu tidak menjamin merge akan aman.

4. Branch utama menjadi tempat eksperimen integrasi

Tanpa merge queue, main sering menjadi titik pertama di mana kombinasi beberapa PR benar-benar diuji. Ini membalik tujuan CI. Seharusnya validasi integrasi utama terjadi sebelum merge, bukan sesudah branch utama terlanjur rusak.

Bagaimana Alur Kerja Merge Queue

Secara umum, merge queue bekerja dengan cara menempatkan PR yang siap digabung ke dalam antrian. Sistem lalu membuat representasi merge sementara terhadap branch utama terbaru, menjalankan required checks, dan hanya menggabungkan PR jika validasi untuk urutan tersebut lulus.

Alur dasar

  1. Developer membuka PR dan menyelesaikan review.
  2. PR memenuhi syarat awal: approval cukup, branch up-to-date sesuai kebijakan, dan required checks dasar lulus.
  3. PR dimasukkan ke merge queue.
  4. Sistem membuat commit uji atau branch sementara yang merepresentasikan PR di atas main terbaru, atau beberapa PR sekaligus jika menggunakan batching.
  5. CI dijalankan pada state sintetis tersebut.
  6. Jika lulus, PR digabung sesuai urutan queue.
  7. Jika gagal, PR atau batch dikeluarkan dari queue, lalu perlu diperbaiki atau diantrekan ulang.

Inti dari pendekatan ini adalah: yang diuji adalah kandidat merge sebenarnya, bukan hanya head commit PR yang bisa jadi sudah basi.

Serial merge vs batching

Ada dua pola utama:

  • Serial merge: satu PR diuji dan digabung per giliran.
  • Batching: beberapa PR diuji dalam satu batch, lalu digabung bersama jika lulus.

Serial merge lebih sederhana, lebih mudah didiagnosis, dan cocok saat test integration sensitif. Batching meningkatkan throughput ketika CI mahal dan probabilitas konflik antar PR relatif rendah. Namun saat batch gagal, perlu strategi untuk menemukan PR penyebabnya.

Kapan Merge Queue Cocok Dipakai

Merge queue tidak wajib untuk semua tim. Ia paling berguna ketika biaya branch utama merah lebih tinggi daripada tambahan waktu tunggu merge.

Situasi yang cocok

  • Branch utama harus selalu dapat di-deploy.
  • Tim memiliki banyak PR paralel.
  • CI memakan waktu cukup lama dan sering overlap.
  • Ada banyak test integrasi atau end-to-end yang sensitif terhadap perubahan berurutan.
  • Sering terjadi "PR lulus sendiri, gagal setelah merge".
  • Tim mengandalkan auto-merge dan branch protection ketat.

Situasi yang mungkin belum perlu

  • Repositori kecil dengan sedikit PR per hari.
  • CI sangat cepat dan test suite mayoritas deterministik.
  • Tim masih sering melakukan push langsung ke branch utama.
  • Biaya operasional queue lebih tinggi daripada manfaatnya.

Jika masalah utama Anda adalah test flakey, merge queue membantu membatasi kerusakan pada branch utama, tetapi tidak menyembuhkan akar masalah. Test yang tidak stabil tetap harus diperbaiki.

Integrasi dengan GitHub atau Platform Serupa

Pada GitHub dan platform serupa, implementasi praktis merge queue biasanya bergantung pada kombinasi branch protection, required status checks, dan fitur queue bawaan atau otomasi setara. Prinsip operasionalnya serupa meski nama fiturnya bisa berbeda.

Aturan branch protection yang perlu dipikirkan

  • Wajibkan pull request sebelum merge ke branch utama.
  • Wajibkan approval review sesuai kebutuhan tim.
  • Wajibkan status checks tertentu sebagai required checks.
  • Pertimbangkan kewajiban branch harus up-to-date atau serahkan sinkronisasi ini ke merge queue.
  • Nonaktifkan push langsung ke branch utama kecuali untuk akun automasi yang terkontrol.
  • Batasi siapa yang boleh bypass aturan, khususnya untuk hotfix.

Contoh kebijakan yang masuk akal untuk branch utama:

Branch utama: main
Aturan:
- Pull request wajib
- Minimal 1-2 approval
- Required checks:
  - build
  - unit-tests
  - integration-tests
  - lint
  - security-scan ringan
- Push langsung dilarang
- Merge dilakukan lewat merge queue atau auto-merge yang terintegrasi
- Admin bypass dibatasi untuk insiden produksi

Memilih required checks dengan hati-hati

Kesalahan umum adalah menjadikan terlalu banyak job mahal sebagai required checks untuk queue. Akibatnya antrian menjadi lambat, feedback loop memburuk, dan developer mulai mencari jalan pintas. Pisahkan check menjadi dua lapisan:

  • Required untuk merge queue: build, unit test utama, integration test penting, lint, dan validasi yang benar-benar mencegah branch utama merah.
  • Non-blocking atau post-merge: benchmark berat, scan penuh yang memakan waktu lama, atau test kompatibilitas luas yang tidak perlu memblokir setiap merge.

Tujuannya bukan mengurangi kualitas, melainkan menempatkan validasi di tahap yang tepat. Check yang memblokir merge sebaiknya benar-benar memiliki sinyal tinggi dan waktu jalan yang masuk akal.

Desain Pipeline yang Efisien untuk Merge Queue

Merge queue akan memperlihatkan kualitas desain CI Anda. Jika pipeline boros atau tidak deterministik, queue hanya memperbesar masalah. Karena itu, desain pipeline perlu disesuaikan.

Pisahkan fast path dan full path

Gunakan dua jalur utama:

  • PR checks cepat untuk memberi umpan balik awal ke developer.
  • Queue checks untuk memvalidasi kandidat merge yang lebih dekat ke kondisi produksi.

Contoh pembagian:

  • PR checks cepat: lint, type check, unit test cepat, build dasar.
  • Queue checks: integration test kritis, smoke test aplikasi, migrasi database uji, kontrak API inti.
  • Post-merge atau jadwal terpisah: e2e penuh lintas browser, scan keamanan mendalam, uji beban.

Pastikan hasil test deterministik

Queue sangat sensitif terhadap test flakey. Beberapa langkah praktis:

  • Isolasi data test; jangan berbagi state antar job.
  • Gunakan seed tetap untuk test acak bila memungkinkan.
  • Jangan bergantung pada urutan eksekusi test.
  • Pastikan service dependency lokal atau ephemeral environment dapat diprediksi.
  • Bedakan retry untuk kegagalan infrastruktur dan retry untuk kegagalan test logika.

Optimalkan waktu eksekusi

  • Gunakan cache dependency dan build artifact jika aman.
  • Jalankan test paralel pada level job atau shard test suite.
  • Kurangi provisioning environment yang tidak perlu.
  • Gunakan image CI yang konsisten agar startup cepat dan reproduktif.
  • Hilangkan duplikasi job antara PR pipeline dan queue pipeline bila hasilnya bisa dipakai ulang secara aman.

Perlu hati-hati dengan reuse hasil. Jika artifact dihasilkan dari commit PR tanpa konteks merge terbaru, artifact itu belum tentu valid untuk kandidat merge di queue.

Contoh desain alur CI

Pull Request:
1. lint
2. unit-tests
3. build
4. quick-integration

Masuk Merge Queue:
1. checkout kandidat merge terhadap main terbaru
2. build bersih atau reuse artifact yang valid terhadap kandidat merge
3. integration-tests kritis
4. migration-smoke-test
5. deploy preview opsional
6. final status: queue-ready

Batching vs Serial Merge: Memilih Strategi yang Tepat

Kapan memilih serial merge

  • Suite test sering menangkap interaksi halus antar PR.
  • Biaya gagal merge tinggi, misalnya branch utama harus selalu deployable.
  • Tim sedang awal mengadopsi merge queue.
  • Repositori monolit besar dengan banyak coupling.

Kelebihan: diagnosis mudah, risiko lebih rendah, perilaku lebih dapat diprediksi.

Kekurangan: throughput merge lebih rendah karena setiap PR menunggu giliran penuh.

Kapan memilih batching

  • PR relatif kecil dan independen.
  • CI mahal sehingga biaya per merge perlu ditekan.
  • Tim sudah punya data bahwa kegagalan lintas PR jarang.

Kelebihan: throughput lebih tinggi, utilisasi CI lebih efisien.

Kekurangan: ketika batch gagal, akar masalah tidak langsung jelas. Perlu strategi seperti mengurangi ukuran batch, membelah batch, atau mengembalikan ke serial untuk investigasi.

Pendekatan praktis

Mulai dari serial merge. Setelah metrik stabil, uji batching kecil untuk kategori perubahan tertentu, misalnya dokumentasi, perubahan UI ringan, atau service dengan cakupan test tinggi dan coupling rendah. Hindari batching besar sejak awal.

Prioritas Hotfix Tanpa Merusak Disiplin Branch Utama

Hotfix produksi sering membutuhkan jalur cepat. Namun bypass queue terlalu sering akan menghilangkan manfaat utama merge queue. Solusi yang lebih sehat adalah membuat aturan prioritas yang eksplisit.

Pola yang umum dipakai

  • Priority lane: hotfix bisa naik ke depan queue setelah memenuhi review minimum dan check kritis minimum.
  • Reduced check set: hanya untuk insiden tertentu, misalnya build, smoke test, dan subset integration test yang paling relevan.
  • Controlled bypass: hanya akun atau peran tertentu yang boleh bypass, dengan kewajiban membuat catatan insiden.

Kuncinya adalah auditability. Tim harus tahu kapan queue dibypass, oleh siapa, dan apa dampaknya. Bypass tanpa jejak biasanya berubah menjadi kebiasaan.

Aturan operasional hotfix

  1. Tentukan definisi hotfix yang sempit: insiden produksi, gangguan keamanan, atau bug yang memblokir bisnis.
  2. Batasi siapa yang bisa memberi label prioritas.
  3. Tetapkan check minimal yang tetap wajib.
  4. Lakukan verifikasi pasca-merge lebih ketat, misalnya smoke test tambahan atau monitoring sementara.
  5. Tinjau semua bypass dalam retrospektif operasional.

Dampak Merge Queue pada Feedback Loop Developer

Trade-off terbesar merge queue adalah stabilitas branch utama ditukar dengan tambahan waktu tunggu merge. Ini bukan kelemahan tersembunyi; ini memang biaya yang harus dikelola.

Dampak positif

  • Branch utama lebih jarang merah.
  • Lebih sedikit pekerjaan reaktif untuk memperbaiki build setelah merge.
  • Deploy pipeline lebih bisa dipercaya.
  • Developer tidak perlu menebak apakah check PR masih relevan.

Dampak negatif

  • Waktu dari approval ke merge bertambah.
  • Developer bisa merasa menunggu terlalu lama jika queue padat.
  • Kegagalan CI pada queue terjadi lebih dekat ke tahap akhir, sehingga terasa lebih mahal.

Cara menjaga feedback loop tetap sehat

  • Pastikan PR checks awal cepat, idealnya memberi sinyal dalam hitungan menit.
  • Kurangi ukuran PR agar antrean bergerak lebih lancar.
  • Gunakan auto-merge bersama queue agar developer tidak perlu menunggu manual.
  • Jadwalkan kapasitas runner CI sesuai jam sibuk merge.
  • Kurangi check blocking yang bernilai rendah.

Jika setelah mengadopsi merge queue produktivitas terasa turun tajam, biasanya masalahnya bukan di konsep queue itu sendiri, melainkan di pipeline yang terlalu berat, test flakey, atau aturan required checks yang belum dipilah dengan baik.

Metrik yang Perlu Dipantau

Tanpa metrik, Anda sulit tahu apakah merge queue benar-benar memperbaiki kualitas atau hanya memindahkan bottleneck.

Metrik inti

  • Queue wait time: waktu dari PR siap merge sampai mulai diproses.
  • Queue cycle time: waktu dari masuk queue sampai merge atau gagal.
  • Main branch failure rate: seberapa sering branch utama merah setelah merge.
  • False green rate: PR yang lulus checks awal tetapi gagal saat diproses di queue.
  • Flake rate: persentase job yang gagal lalu lulus saat diulang tanpa perubahan kode.
  • Throughput merge: jumlah PR yang berhasil digabung per periode.
  • Hotfix bypass count: frekuensi bypass atau prioritas darurat.

Metrik pendukung

  • Durasi rata-rata job required checks.
  • Persentase kegagalan per jenis test.
  • Ukuran batch dan tingkat kegagalan batch.
  • Proporsi kegagalan karena infrastruktur dibanding kegagalan aplikasi.

Metrik ini membantu mengambil keputusan praktis: menambah runner, memecah test suite, mengurangi check blocking, atau kembali dari batching ke serial.

Kesalahan Umum Saat Menerapkan Merge Queue

  • Menganggap queue sebagai pengganti kualitas test. Jika test flakey, queue akan sering macet.
  • Memblokir merge dengan semua check yang ada. Hanya check bernilai tinggi yang seharusnya required.
  • Tidak membedakan kegagalan infrastruktur dan kegagalan kode. Keduanya butuh respons berbeda.
  • Tidak menyiapkan kapasitas runner. Queue akan terlihat buruk bila CI kekurangan resource.
  • Mengaktifkan batching terlalu cepat. Diagnosis menjadi sulit sebelum baseline stabil.
  • Bypass terlalu longgar. Akhirnya tim kembali ke pola merge manual tanpa validasi yang konsisten.

Langkah Rollout Bertahap yang Aman

Penerapan merge queue sebaiknya dilakukan bertahap, bukan langsung pada semua repositori dan semua jenis perubahan.

Fase 1: Rapikan fondasi CI

  • Identifikasi test flakey dan job yang paling sering gagal.
  • Tentukan required checks minimum yang benar-benar melindungi branch utama.
  • Pastikan branch protection sudah konsisten.
  • Larangan push langsung ke branch utama kecuali automasi yang sah.

Fase 2: Aktifkan untuk repositori atau branch paling kritis

  • Mulai dari main yang paling sering dideploy.
  • Gunakan serial merge lebih dulu.
  • Pantau queue wait time, cycle time, dan failure rate.

Fase 3: Tuning pipeline

  • Pindahkan check bernilai rendah keluar dari jalur blocking.
  • Percepat job termahal.
  • Perjelas retry policy untuk kegagalan infrastruktur.

Fase 4: Tambahkan fitur operasional

  • Priority lane untuk hotfix.
  • Auto-merge setelah approval dan checks awal lengkap.
  • Notifikasi queue failure ke kanal tim.

Fase 5: Evaluasi batching terbatas

  • Uji batch kecil pada area kode dengan risiko integrasi rendah.
  • Bandingkan throughput dan failure rate terhadap serial merge.
  • Jika diagnosis batch terlalu mahal, kembali ke serial.

Contoh Kebijakan Operasional yang Realistis

Tujuan:
- main selalu dalam kondisi layak deploy
- tidak ada merge manual langsung setelah CI PR hijau

Aturan:
- semua perubahan masuk lewat pull request
- minimal 1 approval untuk perubahan biasa, 2 untuk area sensitif
- required checks sebelum masuk queue:
  - lint
  - build
  - unit-tests
- required checks di merge queue:
  - integration-tests-kritis
  - migration-smoke-test
  - package-security-check ringan
- mode awal: serial merge
- hotfix boleh prioritas jika diberi label incident-hotfix oleh on-call
- bypass hanya oleh release manager atau incident commander
- semua bypass ditinjau mingguan

Metrik mingguan:
- waktu tunggu median di queue
- rasio kegagalan queue
- jumlah main merah
- jumlah bypass hotfix
- 5 job CI paling lambat

Debugging Saat Queue Sering Gagal

Jika banyak PR gagal hanya saat di queue

  • Periksa apakah ada dependency pada state branch utama terbaru yang tidak tercakup di PR checks awal.
  • Cek kompatibilitas migrasi database yang berjalan berurutan.
  • Lihat apakah artifact build dari tahap sebelumnya dipakai pada commit yang salah.

Jika queue lambat sekali

  • Audit required checks yang sebenarnya tidak perlu blocking.
  • Periksa antrean runner CI dan tingkat utilisasinya.
  • Tinjau ukuran PR; PR besar memperlambat seluruh sistem.

Jika hotfix sering bypass queue

  • Evaluasi apakah SLA queue terlalu lambat untuk kebutuhan operasional.
  • Buat lane prioritas resmi daripada bypass manual berulang.
  • Ukur jenis insiden yang paling sering memicu bypass; mungkin ada area test yang perlu dipercepat.

Penutup

Strategi merge queue agar CI stabil dan branch utama tetap hijau pada dasarnya adalah disiplin untuk menguji urutan merge yang benar, bukan sekadar menambah antrian. Pendekatan ini paling efektif ketika dipadukan dengan branch protection yang ketat, required checks yang dipilih dengan hati-hati, pipeline yang efisien, dan aturan operasional yang jelas untuk hotfix.

Jika tim Anda sering mengalami branch utama merah karena race condition antar PR, hasil check basi, atau rerun CI yang menyesatkan, merge queue adalah solusi praktis. Namun keberhasilannya sangat ditentukan oleh kualitas test, desain pipeline, dan kebiasaan operasional tim. Mulailah dari serial merge, ukur dampaknya, lalu optimalkan secara bertahap.