Pindah Deploy ke Vercel: Kuncinya di Luar Kode

Sore ini saya membuka git show untuk commit dokumentasi terbaru di repo company profile egperkasa. Satu baris di CLAUDE.md berganti: deploy bukan lagi Cloudflare Workers, sekarang Vercel, auto-deploy tiap push. Sementara itu, catatan memori .serena di commit sebelumnya masih saja menyimpan petunjuk lama soal Wrangler.

Dugaan pertama saya lazim saja: pasti ada perubahan berat di wrangler.json. Adapter dibuang, skrip build dirombak, semacam itu. Saya gulir diff ke atas dan ke bawah. Hasilnya nol. Yang berubah cuma teks dokumentasi.

Di titik itu saya sadar dugaan saya salah total. Migrasi deploy kayak gini emang nggak meninggalkan jejak berarti di dalam repo, karena kabelnya dipasang di luar Git: di dashboard Vercel dan di halaman settings GitHub. Repo cuma mencatat hasil akhirnya, kayak orang nulis “kunci rumah udah diganti” di buku catatan, padahal serah terima kuncinya terjadi di notaris.

Production Branch Itu Hasil Pemilihan

Kebiasaan lama bilang branch main itu otomatis jadi production. Di Vercel posisi itu emang biasa disandang main, tapi bukan karena namanya. Saat project baru diimpor, Vercel memilih production branch dengan urutan: main dulu, kalo nggak ada baru master, dan kalo dua-duanya nggak ada baru default branch repo [1]. Khusus Bitbucket ada satu langkah ekstra sebelum urutan jatuh ke default branch, tapi itu di luar kasus saya.

Setelah project jalan, posisi itu masih bisa dipindah lewat Project Settings > Environments > Branch Tracking [1]. Konsekuensinya jelas: branch lain di luar production branch cuma dapat preview deployment [1], lengkap dengan URL unik buat dicek sebelum merge.

Jadi default branch GitHub itu bukan gelar keagungan. Dia cuma salah satu kandidat di urutan pemilihan, dan itu pun cuma ditanya saat impor.

Kenapa stag Jadi Default di Dua Remote

Di GitHub, default branch adalah base buat pull request dan commit kode [2]. Mengubahnya butuh akses admin, dan repo harus punya lebih dari satu branch [2]. Detail kecil yang saya alami sendiri: percobaan ganti default branch di remote kedua lewat API ditolak karena PAT yang saya pakai nggak punya scope admin. Akhirnya saya buka web UI dan ganti manual.

Hasil akhirnya mekanis dan membosankan, dan itu memang tujuannya. Orang yang baru clone repo bakal mendarat di stag. Pull request baru default-nya menunjuk stag. Branch yang paling sering jadi sasaran push adalah branch yang cuma memicu preview, bukan yang nge-flip production. Salah sasaran pun, yang terbakar cuma environment preview.

Satu nuansa yang perlu dipegang: mengubah default branch GitHub itu nggak otomatis mengubah production branch di Vercel untuk project yang udah jalan. Urutan pemilihan tadi cuma kejadian saat impor; sisanya diatur lewat Branch Tracking. Dua sakelar ini berdiri sendiri, jadi saya kunci keduanya secara eksplisit: default branch stag, production branch main.

Dua Remote, Satu Aturan

Repo ini sekarang punya dua remote: origin yang terhubung ke Vercel, dan github-old yang murni mirror cadangan. Pemisahan ini bukan selera pribadi, tapi patuh pada aturan resmi Git: push URL dan fetch URL, walaupun bisa diatur beda, tetap harus merujuk ke tempat yang sama; kalo maksudnya push ke tempat lain daripada tempat fetch, pakai dua remote terpisah [4].

Saya sempat tergoda bikin trik push URL ganda di satu remote. Batal, karena dokumentasinya sendiri bilang itu bukan jalannya. Dua remote dengan tanggung jawab jelas jauh lebih gampang diaudit: push ke origin berarti keputusan deploy, push ke github-old cuma backup.

Yang Berubah dari Dunia Workers

Dulu di Cloudflare Workers, kode Worker dan aset statis dideploy sebagai satu operasi dari assets directory di config Wrangler [3]. Satu perintah, satu paket, selesai. Pindah ke Vercel, beberapa hal yang dulu nempel di satu config itu terpecah ke tempat masing-masing.

Environment variables contoh paling nyata. Vercel memisahkan variabel per target: production, preview, development, sampai override per-branch buat preview, dan dikelola lewat vercel env ls atau vercel env add [5]. Nggak ada yang ikut pindah sendiri; yang dulu tersimpan rapi di config Cloudflare harus didaftarkan ulang satu-satu.

Rollback juga beda model. Vercel menyebut instant rollback dengan memindahkan domain ke deployment lain [1], bukan sekadar git revert. Model mentalnya lebih dekat ke “tunjuk versi yang bener” daripada “gulung balik kode”.

Alur Git-nya sendiri? Nggak berubah sama sekali: feature ke stag, rilis lewat merge ke main dengan tag. Yang ganti cuma jawaban atas pertanyaan “push ini memicu apa”.

Kommit dokumentasi itu akhirnya terasa bukan sebagai sisa kerjaan admin, tapi sebagai satu-satunya tempat wajar buat mencatat migrasi begini. Kuncinya emang bukan barang yang bisa di-commit; yang bisa di-commit cuma catatan siapa pegang kuncinya.

Sumber:

[1] Vercel: Deploying Git Repositories

[2] GitHub Docs: Changing the default branch

[3] Cloudflare Docs: Workers Static Assets

[4] git-scm: git-remote

[5] Vercel: Managing environment variables across environments