Menutup auto-deploy Vercel untuk branch stag

Pagi hari pas migrasi deploy, fokus saya kepencet ke satu hal: branch mana yang dianggap Vercel sebagai production. Padahal ada masalah lain yang nggak kalah mengganggu. Tiap push ke stag terus memproduksi deployment preview yang nggak diminta siapa-siapa.

Konteksnya gini. Repo website kantor deploy ke Vercel dengan main sebagai production branch, sementara stag jadi staging branch yang nanti dimerge ke main. Cara Vercel memilih production branch saat import sendiri pernah saya bedah di artikel sebelumnya; kali ini urusannya beda, soal deploy yang datang dari branch tertentu. Default Vercel: semua branch yang di-push otomatis di-deploy. Dengan dua branch jangka panjang, separuh deployment itu cuma preview dari commit yang sudah saya review di staging. Build minutes kebuang, dashboard rame, dan makin gampang ketukar mana URL yang mana. Saya semula yakin solusinya berarti utak-atik setting dashboard atau nulis script build-skip. Dua-duanya kelihatan kebanyakan buat yang namanya cuma preferensi routing.

Solusi aslinya muat delapan baris JSON. File vercel.json baru di root repo:

{
  "git": {
    "deploymentEnabled": {
      "main": true,
      "stag": false
    }
  }
}

Itu isi lengkap filenya. Key git.deploymentEnabled menerima peta nama branch ke boolean; commit di branch yang diset false nggak memicu deployment, dan semua branch yang nggak disebut default-nya true [4]. Jadi stag: false membungkam push staging, sementara main tetap deploy production tiap merge.

Baris redundan yang sengaja saya biarkan

main: true yang eksplisit itu secara teknis redundan, karena branch yang nggak disebut sudah default true. Tetap saya biarkan. File itu sekarang menyatakan niat untuk dua branch dalam sekali lihat, dan nggak ada yang perlu nebak default implisit pas debugging jam 1 pagi. File config bisa jadi dokumentasi, asalkan bagian yang jelas banget pun diucapkan.

Satu perilaku penting sebelum main-main dengan pattern: kalau satu branch cocok dengan beberapa rule dan salah satunya true, deployment tetap jalan [4]. Setting ini mendukung glob pattern kayak internal-*: false, tapi resolusinya any-true-wins, bukan last-match-wins. Susun rule supaya nggak saling tumpang tindih, kalau nggak branch yang mau dibungkam diam-diam tetap deploy.

Kenapa nggak pakai Ignored Build Step

Sempat saya pertimbangkan Ignored Build Step, dan untung nggak jadi mulai dari sana. Mekanismenya beda: script buatan sendiri yang kalau return 0 build di-skip, dan kode 1 ke atas memicu build baru [5]. Persis kebalikan konvensi exit code Unix, dan panduan troubleshooting resmi Vercel menyebut script ber-logika terbalik sebagai alasan klasik commit tiba-tiba berhenti nge-deploy. Flag JSON deklaratif nggak bisa salah exit, dan nggak bisa membusuk kayak potongan shell saat seseorang refactor CI di sekitarnya.

Ada satu jebakan dari arah sebaliknya, dan itu tercatat di panduan yang sama: pas commit berhenti memicu deployment dan nggak ada yang ingat kenapa, ngecek git.deploymentEnabled yang bernilai false masuk checklist diagnosa resmi [5]. Gating yang dipasang sekali terus dilupakan bakal jadi misteri buat yang debugging berikutnya, dan orang itu biasanya diri kita di masa depan. vercel.json kami tinggal di repo, direview kayak kode, dan pesan commitnya menjelaskan persis apa fungsinya dan kenapa.

Sebagai konteks: property lama github.enabled yang masih dibawa sebagian repo sudah deprecated, digantikan key ini [4]. Kalau repo Anda masih lebih tua dari penggantian nama itu, migrasinya cuma diff dua baris dan nggak ada alasan buat ditunda.

Dua branch jangka panjang sekarang berperilaku kayak dua environment, bukan empat target deploy. Kadang config yang tepat adalah yang cukup kecil buat dibaca tuntas di dalam diff commit.

Sources

[4] https://vercel.com/docs/project-configuration/git-configuration
[5] https://vercel.com/kb/guide/why-aren-t-commits-triggering-deployments-on-vercel