Apa Itu Deploy Preview

Deploy preview adalah salinan situsmu yang dibangun dari satu branch atau pull request, dengan alamatnya sendiri. Ia hidup berdampingan dengan situs produksi, tidak menggantikannya, dan biasanya dibuat otomatis begitu kamu membuka pull request.

Kedengarannya sepele. Dalam praktiknya, ini fitur yang paling mengubah cara orang bekerja dari semua yang ditawarkan platform deploy modern.

Masalah yang diselesaikannya

Sebelum ada deploy preview, meninjau perubahan tampilan situs berarti salah satu dari ini:

• Membaca diff kode dan membayangkan hasilnya. Berhasil untuk perubahan logika, hampir tidak berguna untuk perubahan tampilan.
• Meminta orang lain menjalankan project di laptopnya. Clone repo, install dependensi, pindah branch, jalankan server. Untuk desainer atau penulis konten yang tidak menulis kode, ini penghalang yang cukup untuk membuat mereka menyerah.
• Punya server staging tunggal yang harus diantre. Satu orang mendorong perubahannya ke sana, semua orang menunggu giliran.

Deploy preview menghapus ketiganya. Kamu buka pull request, satu-dua menit kemudian muncul tautan, dan siapa pun bisa mengkliknya — dari laptop, dari ponsel, dari mana saja.

Cara kerjanya

1. Kamu push sebuah branch dan membuka pull request.
2. Platform mendeteksi itu, lalu menjalankan build persis seperti untuk produksi — dengan kode dari branch tersebut.
3. Hasilnya diterbitkan ke URL unik, biasanya berpola seperti deploy-preview-42--nama-situs.netlify.app.
4. Tautannya muncul otomatis sebagai komentar atau status check di pull request.
5. Tiap kali kamu push lagi ke branch itu, preview-nya diperbarui.
6. Setelah PR di-merge atau ditutup, preview-nya dibersihkan.

Yang penting: build-nya memakai proses yang sama dengan produksi. Jadi kalau ada yang rusak saat build, kamu tahu sebelum kode itu masuk ke branch utama.

Kenapa ini lebih dari sekadar kenyamanan

Orang non-teknis bisa ikut meninjau

Ini manfaat terbesarnya, dan yang paling sering diremehkan. Penulis konten bisa memeriksa artikelnya sendiri. Desainer bisa melihat implementasi rancangannya di browser sungguhan. Klien bisa menyetujui perubahan tanpa pernah menyentuh terminal.

Semuanya cukup dengan satu tautan.

Kamu bisa mengujinya di perangkat asli

Membuka localhost dari ponsel itu merepotkan. Membuka URL preview dari ponsel itu sama saja dengan membuka situs biasa. Masalah tampilan di layar kecil ketahuan sebelum masuk produksi, bukan sesudahnya.

Build yang gagal ketahuan lebih awal

Kalau build preview merah, kamu tahu branch itu akan merusak produksi kalau di-merge. Ini pengaman yang bekerja tanpa kamu memikirkannya.

Dua versi bisa dibandingkan berdampingan

Buka produksi di satu tab, preview di tab lain. Untuk keputusan desain — mana yang lebih enak dibaca, mana yang lebih cepat — ini jauh lebih meyakinkan daripada berdebat lewat tangkapan layar.

Cara mengaktifkannya

Kabar baiknya: di hampir semua platform modern, ini sudah aktif secara bawaan. Kamu tidak perlu melakukan apa pun kecuali menghubungkan repositori.

Baris terakhir itu salah satu alasan utama orang meninggalkan GitHub Pages begitu mulai bekerja bertim.

Environment variable di preview

Ini bagian yang perlu kamu urus sendiri, dan yang paling sering salah.

Preview memakai environment variable juga — dan kalau kamu tidak memisahkannya, preview-mu akan menulis ke database produksi. Seseorang menguji form pendaftaran di preview, dan datanya masuk ke data pengguna sungguhan.

Vercel dan Netlify sama-sama membolehkan nilai berbeda per lingkungan:

Luangkan sepuluh menit untuk menyetel ini di awal. Jauh lebih murah daripada membersihkan data uji dari produksi nanti.

Preview bisa diindeks Google — dan itu masalah

URL preview bersifat publik. Kalau ada yang menautkannya dari tempat yang bisa di-crawl, Google bisa mengindeksnya — dan kamu berakhir dengan salinan situsmu yang bersaing dengan situs aslinya di hasil pencarian.

Netlify dan Vercel sudah mengirim header X-Robots-Tag: noindex untuk URL preview secara bawaan, jadi umumnya kamu aman. Tapi kalau kamu memakai custom domain untuk preview, atau membangun sendiri alur preview-nya, pastikan header itu ada.

curl -sSI https://deploy-preview-42--situs.netlify.app/ | grep -i robots

Kalau keluarannya kosong, tambahkan sendiri lewat konfigurasi platformmu.

Kebiasaan yang membuatnya berguna

• Selalu buka pull request, walau kamu bekerja sendiri. Push langsung ke branch utama melewatkan preview sepenuhnya — dan kamu kehilangan kesempatan melihat perubahanmu sebelum jadi produksi.
• Tempelkan tautan preview di deskripsi PR. Biasanya otomatis, tapi kalau tidak, lakukan manual.
• Buka dari ponsel, bukan cuma laptop. Sebagian besar pengunjungmu datang dari ponsel.
• Jangan pakai preview sebagai staging permanen. Preview terikat pada pull request dan hilang setelah ditutup. Kalau kamu butuh lingkungan uji yang menetap, buat branch khusus dengan situsnya sendiri.

Ringkasan

Deploy preview adalah salinan situsmu per pull request, dengan URL sendiri, dibangun dengan proses yang sama seperti produksi. Ia aktif otomatis di Netlify, Vercel, dan Cloudflare — dan tidak ada di GitHub Pages.

Satu hal yang perlu kamu atur sendiri: pisahkan environment variable preview dari produksi, supaya pengujian tidak menyentuh data sungguhan.

Deploy preview adalah bagian dari alur kerja yang lebih besar — lihat continuous deployment untuk frontend untuk gambaran utuhnya, atau panduan lengkap deploy website kalau kamu baru mulai.