Escrow build vs release candidate bukan sekadar perbedaan istilah. Jika tim menyamakan keduanya, proses verifikasi rilis mudah menjadi kabur: build yang seharusnya stabil masih menerima perubahan, test matrix tidak terkunci, sign-off tidak jelas, dan regresi lolos ke produksi. Solusi praktisnya adalah memisahkan dengan tegas build yang sedang dikandidatkan dari build yang sudah ditahan untuk verifikasi final.

Dalam konteks historis, istilah escrow build dikenal dari praktik internal Microsoft dan dibahas dalam konteks engineering di The Old New Thing: idenya adalah ada build yang “disimpan” atau “dipegang” sementara tim melakukan verifikasi tambahan sebelum memutuskan apakah build itu layak dirilis. Di praktik modern CI/CD, konsep ini tetap relevan. Walaupun tooling berubah, masalah dasarnya sama: bagaimana memastikan build yang sudah lolos pipeline tetap identik dengan artefak yang benar-benar dirilis, serta bagaimana mencegah perubahan kecil memicu regresi menjelang rilis.

Apa itu escrow build, dan apa bedanya dengan release candidate?

Release candidate

Release candidate (RC) adalah build yang dianggap cukup stabil untuk menjadi calon rilis. Artinya, secara fungsional ia sudah mendekati final, tetapi masih bisa diganti bila ditemukan bug signifikan, kegagalan compliance, isu performa, atau masalah operasional. RC adalah kandidat, bukan komitmen final.

Escrow build

Escrow build adalah build yang dibekukan untuk verifikasi tertentu dan ditahan tanpa perubahan selama periode evaluasi. Fokusnya bukan hanya “ini mungkin jadi rilis”, tetapi “artefak ini harus tetap identik selama proses validasi final berlangsung”. Jika selama validasi ditemukan masalah dan perlu perbaikan, hasil perbaikannya biasanya menjadi build baru, bukan mengganti isi build escrow yang sedang diverifikasi.

Perbedaan kerja yang penting

  • RC berorientasi kandidat: build calon rilis yang masih dapat diganti.
  • Escrow build berorientasi integritas artefak: build tertentu ditahan apa adanya untuk memastikan yang diuji adalah yang akan dirilis.
  • RC menjawab: “apakah build ini cukup baik untuk dipertimbangkan?”
  • Escrow build menjawab: “apakah artefak final yang persis ini aman untuk diluncurkan?”

Dalam banyak tim modern, satu build bisa berstatus RC sekaligus masuk ke fase escrow. Yang berbahaya bukan kombinasi istilahnya, melainkan ketika tim tidak mendefinisikan gate dan konsekuensinya dengan jelas.

Mengapa escrow build membantu mencegah regresi rilis?

Regresi menjelang rilis sering terjadi bukan karena tim tidak punya test, melainkan karena objek yang diuji berubah atau kriteria lulus berubah di tengah jalan. Escrow build memaksa disiplin pada dua hal itu.

1. Menjamin artefak yang diuji sama dengan artefak yang dirilis

Tanpa escrow, tim bisa menjalankan smoke test pada commit A, lalu membangun ulang dari branch yang sama beberapa jam kemudian untuk rilis produksi. Walaupun source tampak sama, hasil akhirnya belum tentu identik jika ada dependency yang tidak dipin, build environment berubah, atau pipeline menghasilkan artefak berbeda.

Escrow build mendorong penggunaan artefak yang immutable: image, bundle, package, atau binary yang diberi identifier tetap, hash, dan metadata build yang dapat ditelusuri.

2. Mengurangi “fix cepat” yang membuka regresi baru

Menjelang rilis, bug kecil sering memancing patch cepat. Masalahnya, patch terakhir justru sering memicu efek samping di area lain. Dengan model escrow, perubahan setelah freeze harus melewati aturan jelas: apakah cukup ditunda, apakah perlu hotfix terpisah, atau apakah build harus dibatalkan dan dibuat ulang sebagai kandidat baru.

3. Memperjelas akuntabilitas sign-off

Jika QA, engineering, SRE, dan product menandatangani build yang berbeda-beda secara implisit, maka sign-off menjadi semu. Escrow build mengharuskan semua pihak meninjau build yang sama, dengan acceptance criteria yang sama.

Kapan escrow build dipakai?

Escrow build paling berguna saat biaya regresi tinggi atau verifikasi final memerlukan waktu lebih lama daripada pipeline biasa. Contohnya:

  • Rilis backend yang menyentuh autentikasi, billing, permission, atau migrasi data.
  • Rilis frontend/web dengan perubahan alur checkout, login, atau eksperimen yang memengaruhi banyak browser/device.
  • Rilis yang perlu sign-off lintas fungsi: security, compliance, SRE, support.
  • Rilis ke banyak region, tenant, atau lingkungan pelanggan yang berbeda.
  • Rilis yang butuh validasi performa, failover, rollback, atau observability sebelum go-live.

Untuk perubahan kecil berisiko rendah, escrow build bisa terasa berat. Dalam kasus seperti itu, cukup gunakan pipeline standar dengan progressive delivery, canary, feature flag, dan rollback otomatis. Escrow build cocok ketika stabilitas artefak lebih penting daripada kecepatan perubahan menit terakhir.

Risiko jika istilah dan gate verifikasi kabur

RC yang terus berubah

Tim menyebut build sebagai RC, tetapi commit masih masuk ke branch yang sama tanpa cut build baru yang eksplisit. Akibatnya, hasil test tidak lagi merepresentasikan build yang akan dirilis.

Freeze yang hanya nama

Secara formal ada code freeze, tetapi dependency masih bisa naik otomatis, asset dibangun ulang tanpa pinning, atau konfigurasi lingkungan berubah diam-diam. Freeze yang efektif harus mencakup source, dependency, pipeline, dan konfigurasi rilis.

Bug triage tanpa aturan severity

Tanpa definisi bug blocker vs non-blocker, setiap temuan bisa memicu perdebatan baru. Ini memperlambat rilis dan sering berujung pada keputusan emosional, bukan terukur.

Flaky test dianggap sama dengan bug produk

Flaky test memang masalah serius, tetapi sifatnya berbeda. Jika tidak dipisahkan, tim bisa menahan rilis karena noise test, atau lebih buruk, mengabaikan kegagalan yang sebenarnya valid karena menganggap semuanya flaky.

Workflow CI/CD yang jelas: RC, escrow, sign-off, dan rollback

Berikut pola workflow yang bisa diterapkan tanpa bergantung pada tool tertentu.

1. Cut release branch atau tandai commit kandidat

Pilih satu commit yang menjadi kandidat rilis. Idealnya, commit ini punya metadata yang jelas: nomor versi, changelog, referensi issue, dan daftar migrasi atau perubahan operasional.

2. Build artefak immutable sekali

Buat artefak dari commit kandidat satu kali, lalu simpan di registry atau artifact store. Jangan rebuild untuk produksi bila tidak ada perubahan. Gunakan digest, checksum, atau build ID agar verifikasi dan deployment mengacu ke artefak yang sama.

# Contoh alur generik, bukan perintah tool tertentu yang baku
build_id=2026.08.11-rc1
commit_sha=abc1234
artifact=registry.example.com/app:${build_id}

echo "Build commit ${commit_sha} menjadi ${artifact}"
echo "Simpan checksum, metadata, dan hasil test ke release manifest"

3. Jalankan gate RC

Di tahap ini, tujuannya memastikan kandidat cukup layak masuk escrow. Biasanya mencakup:

  • Unit test, integration test, contract test.
  • Static analysis dan security scan dasar.
  • Build reproducibility dan validasi dependency lockfile.
  • Smoke test pada environment staging.

Jika gagal di sini, jangan masuk escrow. Perbaiki, cut kandidat baru, dan ulangi.

4. Masuk fase escrow

Ketika RC lolos gate awal, tetapkan artefak tersebut sebagai escrow build. Pada fase ini:

  • Tidak ada perubahan isi artefak.
  • Semua verifikasi final mengacu ke build ID yang sama.
  • Bug baru tidak diperbaiki di tempat; jika benar-benar blocker, build escrow ditolak dan tim membuat build baru.

5. Jalankan test matrix final

Test matrix final sebaiknya lebih sempit dari seluruh test universe, tetapi lebih fokus pada area berisiko tinggi. Tujuannya bukan mengetes semuanya lagi tanpa prioritas, melainkan memverifikasi jalur rilis yang paling rentan terhadap regresi.

6. Triage temuan dengan aturan eksplisit

Setiap temuan diberi kategori jelas:

  • Blocker: membatalkan rilis.
  • Must-fix before GA: harus diperbaiki di build baru sebelum rilis umum.
  • Acceptable known issue: didokumentasikan, ada mitigasi, dan disetujui pemilik risiko.
  • Test issue: masalah pada automation atau lingkungan test, bukan pada produk.

7. Sign-off lintas peran

Sign-off minimal biasanya melibatkan engineering owner, QA/release manager, dan operator produksi seperti SRE atau DevOps. Untuk domain sensitif, tambahkan security atau compliance. Kuncinya: mereka menandatangani build ID yang sama dan acceptance criteria yang sudah tertulis sejak awal.

8. Rollback readiness sebelum go-live

Rilis belum siap hanya karena test lulus. Tim juga harus siap membatalkan dampak rilis bila masalah muncul setelah deploy. Untuk itu, verifikasi:

  • Versi sebelumnya masih tersedia untuk redeploy.
  • Migrasi database punya strategi rollback atau roll-forward yang aman.
  • Feature flag bisa mematikan fitur berisiko tanpa rebuild.
  • Alarm, dashboard, dan log untuk perubahan ini sudah dipantau.

Menyusun acceptance criteria yang tidak ambigu

Acceptance criteria yang kabur membuat diskusi rilis berulang. Tulis kriteria dalam bentuk yang dapat diverifikasi.

Contoh acceptance criteria yang baik

  • Semua test mandatory di pipeline RC harus hijau.
  • Tidak ada bug severity blocker atau critical yang belum ditangani.
  • Latency endpoint inti tidak menunjukkan degradasi yang tidak dapat dijelaskan pada smoke/perf check yang disepakati.
  • Migrasi database telah diuji di staging dengan snapshot data representatif.
  • Dashboard, alert, dan runbook rollback untuk komponen yang berubah telah diverifikasi.
  • Sign-off engineering, QA, dan SRE sudah tercatat pada build ID yang sama.

Contoh acceptance criteria yang buruk

  • “Aplikasi terasa stabil.”
  • “Mayoritas test aman.”
  • “Kalau ada bug kecil nanti diperbaiki setelah rilis.”

Kriteria seperti itu membuka ruang interpretasi dan mendorong keputusan berbasis intuisi, bukan bukti.

Test matrix: fokus pada area yang paling sering bocor

Test matrix untuk escrow build tidak harus selalu besar, tetapi harus sengaja disusun. Prinsipnya adalah memadukan cakupan risiko dan waktu verifikasi.

Komponen test matrix yang umum

  • Jalur kritis bisnis: login, checkout, pembayaran, pembuatan order, write-path penting.
  • Kompatibilitas: browser utama, device penting, variasi API client, region/tenant tertentu.
  • Operasional: start-up, health check, deployment, scaling, failover ringan.
  • Data: migrasi, backward compatibility schema, idempotensi job.
  • Security basics: kontrol akses, secret/config sanity, header penting, auth flow.

Kesalahan umum saat menyusun test matrix

  • Menguji terlalu banyak hal bernilai rendah, tetapi melewatkan jalur bisnis inti.
  • Tidak membedakan test wajib dan test informasional.
  • Tidak punya data uji yang cukup mirip produksi.
  • Tidak mencatat cakupan environment mana yang benar-benar diuji.

Freeze policy yang realistis

Freeze policy harus menjelaskan apa yang dibekukan, siapa yang boleh membuat pengecualian, dan apa konsekuensinya.

Minimal isi freeze policy

  • Waktu mulai dan akhir freeze.
  • Branch atau commit mana yang dibekukan.
  • Apakah dependency update otomatis dimatikan.
  • Aturan untuk config change, schema change, dan migration.
  • Definisi emergency fix dan siapa approver-nya.
  • Aturan apakah emergency fix membatalkan escrow build dan mewajibkan build baru.

Catatan praktis: freeze policy yang baik tidak selalu berarti “tidak boleh ada perubahan sama sekali”. Yang penting adalah perubahan punya jalur persetujuan yang jelas dan tidak diam-diam mengubah artefak yang sedang diverifikasi.

Bug triage dan flaky test handling

Bug triage: pisahkan severity, priority, dan release impact

Severity menjelaskan dampak teknis atau bisnis. Priority menjelaskan urutan pengerjaan. Release impact menjelaskan apakah build boleh lanjut. Tiga hal ini sering tercampur.

Contoh: bug severity sedang bisa menjadi blocker bila menyentuh jalur pembayaran; sebaliknya bug severity tinggi bisa bukan blocker bila hanya muncul di fitur admin internal yang tidak ikut dirilis.

Flaky test handling: jangan diabaikan, jangan juga memveto rilis tanpa analisis

Strategi yang lebih sehat:

  • Tandai test yang diketahui flaky dan keluarkan dari gate mandatory hanya dengan persetujuan jelas.
  • Buat daftar pemilik per test suite.
  • Simpan riwayat rerun agar pola flakiness terlihat.
  • Bedakan kegagalan karena environment, data race, timeout, dan regresi riil.

Bila sebuah test flaky menyentuh jalur kritis, solusi yang benar biasanya bukan menghapus gate, tetapi memperbaiki test atau mengganti metode verifikasinya dengan sinyal yang lebih andal.

Checklist rilis untuk tim backend/web

Checklist berikut bisa dipakai sebagai baseline dan disesuaikan dengan sistem Anda.

Checklist sebelum menetapkan escrow build

  • Commit kandidat telah ditentukan dan ditag.
  • Versi, changelog, dan owner rilis tercatat.
  • Artefak immutable sudah dibangun dan tersimpan.
  • Dependency kritis dipin, lockfile tervalidasi.
  • Pipeline RC mandatory lulus.
  • Daftar perubahan berisiko tinggi sudah ditandai.

Checklist verifikasi escrow build

  • Build ID yang diuji sama dengan build ID untuk deploy.
  • Smoke test staging lulus.
  • Test matrix jalur kritis lulus.
  • Migrasi database diuji dengan data representatif.
  • Contract test dengan service dependensi lulus.
  • Observability siap: log, metric, trace, dashboard, alert.
  • Feature flag/default config telah diverifikasi.
  • Tidak ada blocker yang terbuka.
  • Known issue terdokumentasi dan disetujui.

Checklist kesiapan produksi dan rollback

  • Runbook deploy dan rollback tersedia.
  • Versi sebelumnya siap redeploy.
  • Backup/snapshot yang diperlukan sudah tersedia.
  • Strategi rollback schema jelas: rollback atau roll-forward.
  • On-call engineer mengetahui jadwal dan ruang lingkup rilis.
  • Parameter monitoring pasca-rilis sudah ditentukan.

Checklist sign-off

  • Engineering owner menyetujui build ID.
  • QA/release manager menyetujui hasil verifikasi.
  • SRE/DevOps menyetujui kesiapan operasional.
  • Security/compliance menyetujui jika ruang lingkup mengharuskan.
  • Waktu rilis, rencana komunikasi, dan rollback trigger disepakati.

Contoh dokumen gate rilis yang sederhana

Release: 2026.08.11
Build ID: app-2026.08.11-rc1
Commit: abc1234
Status: ESCROW

Mandatory gates:
- Unit/integration tests: PASS
- Smoke staging: PASS
- DB migration rehearsal: PASS
- Critical path web checks: PASS
- Observability checks: PASS

Open issues:
- KNOWN-142: typo pada halaman admin internal (accepted)
- TEST-77: flaky e2e non-critical, dikeluarkan dari gate mandatory sementara

Blockers:
- none

Approvals:
- Engineering owner: approved
- QA/Release manager: approved
- SRE: approved

Rollback plan:
- Redeploy previous artifact: app-2026.08.04
- Feature flag checkout-v2: OFF if error rate rises
- Migration strategy: roll-forward only, backward-compatible schema verified

Dokumen seperti ini tidak harus rumit. Nilai utamanya adalah membuat keputusan rilis dapat diaudit dan dipahami semua pihak.

Kapan memilih RC saja, kapan memakai escrow build?

Pilih RC saja bila:

  • Risiko perubahan rendah.
  • Pipeline sudah sangat andal dan cepat.
  • Deployment bersifat bertahap dengan canary/feature flag yang kuat.
  • Rollback murah dan sederhana.

Gunakan escrow build bila:

  • Butuh verifikasi final yang harus mengacu pada artefak tetap.
  • Biaya regresi tinggi.
  • Perubahan melibatkan data, security, billing, atau jalur kritis.
  • Sign-off lintas tim diperlukan sebelum rilis.
  • Rebuild atau perubahan menit terakhir berpotensi memperkenalkan ketidakpastian.

Praktiknya, banyak tim memakai keduanya: RC untuk menyeleksi kandidat, lalu escrow build untuk mengunci artefak final selama verifikasi terakhir.

Penutup

Inti dari escrow build vs release candidate adalah kejelasan proses, bukan jargon. RC membantu tim memilih kandidat terbaik. Escrow build memastikan kandidat yang sedang diverifikasi tidak berubah di tengah jalan. Bila istilah, gate, dan acceptance criteria didefinisikan dengan tegas, tim lebih mudah mencegah regresi rilis, mempercepat triage, dan menjaga bahwa artefak yang diuji benar-benar sama dengan yang akan masuk produksi.

Jika ingin menerapkannya besok pagi, mulai dari tiga hal: freeze artefak secara immutable, pisahkan gate RC dan gate escrow, dan tulis sign-off serta rollback plan pada build ID yang sama. Tiga langkah ini saja sudah menghilangkan banyak sumber kebingungan yang sering menyebabkan regresi menjelang rilis.