Cek "Tembakan Kosong" Sebelum Menyerahkan Deploy Produksi ke Claude Code

Jumat sore, saya minta Claude Code, “Tolong rilis perbaikan artikel ini ke produksi.” Yang kembali cuma satu kalimat, “Sudah dipublikasikan,” ditambah centang hijau. Saya pulang dengan tenang. Esok paginya, halaman depan situs kosong melompong, putih total.

Penyebabnya konyol. Tidak ada satu orang pun yang membuka preview. Claude Code hanya melihat log build yang lolos lalu menyimpulkan “berhasil.” Padahal halaman aslinya memuat template artikel lain, dan isinya kosong. Karena HTTP tetap mengembalikan 200, secara mekanis itu terlihat seperti “publish sukses.”

Saat itu saya benar-benar sadar: cepat dan aman itu dua hal berbeda. Kalau deploy diserahkan utuh, prosesnya seolah selesai dalam sekejap. Tapi kalau tidak ada catatan apa yang sudah diperiksa, begitu terjatuh kita tidak tahu apa yang harus dikembalikan. Hari ini saya tulis penangkalnya: cara mengumpulkan bukti lewat “tembakan kosong” (dry run) sebelum menyerahkan akses produksi.

Poin penting

Sebagian besar kecelakaan saat menyerahkan deploy ke Claude Code terjadi karena pengecekan sebelum menyentuh produksi dilewati.
Sebelum memberi akses produksi, lakukan dry run untuk lima hal: build, diff, preview URL, pemilik rollback, dan area yang tidak disentuh.
Memisahkan “verifikasi yang bisa dinilai mesin” dari “penilaian yang dilihat mata manusia” mengurangi kecelakaan tengah malam.
Saya sertakan template prompt siap salin dan kode untuk mengecek hasil verifikasi secara mekanis.
Anda tidak butuh aturan operasional yang sempurna dari awal. Coba pada satu perbaikan, lalu tambahkan titik tempat Anda tersandung ke dalam checklist.

Kecelakaan deploy terjadi bukan karena “kurang pintar”, tapi karena kurang verifikasi

Claude Code itu pintar. Tapi pintar dan bisa bergerak aman di produksi adalah cerita yang berbeda.

Sama seperti murid yang nilai ujiannya sempurna tetapi merusak mesin kasir di hari pertama kerja paruh waktu, ini bukan soal kemampuan, melainkan soal pijakan. Untuk urusan deploy, “pijakan” berarti apa yang Anda periksa sebelum menyentuh produksi.

Khususnya deploy situs statis, kegagalannya berjalan diam-diam. Begitu build lolos dan HTTP mengembalikan 200, secara kasat mata semuanya tampak berhasil. Padahal isinya bisa kosong, atau tertukar dengan halaman lain. Kalau Anda hanya melihat kode status, Anda tidak akan menyadarinya. Karena itu, bukan “apakah kodenya jalan”, tetapi “apakah halaman yang benar muncul dengan benar” yang harus dilihat sekali oleh mata manusia.

Lima langkah dry run sebelum menyentuh produksi

Prosedur yang saya pakai sekarang cuma ini. Urutannya penting, jadi saya susun dari atas ke bawah.

Luluskan build di lokal dulu. Kalau di sini saja gagal, urusan produksi masih jauh. Pisahkan dulu apakah ini masalah kode atau masalah lingkungan, sebelum menyentuh produksi.
Baca diff-nya. Periksa dengan mata apakah ada informasi rahasia (API key, token) atau perubahan terkait penagihan yang ikut tercampur.
Buka preview URL. Pastikan di layar nyata bahwa judul (h1), URL kanonik (canonical), dan tujuan tombol pendaftaran sudah sesuai harapan.
Tentukan pemilik rollback dan cara mengembalikan. Saat gagal, siapa yang dengan command apa mengembalikan ke kondisi sebelumnya. Kalau ini tidak ditetapkan lebih dulu, Anda akan membeku begitu kecelakaan terjadi.
Minta akses produksi hanya setelah bukti lengkap. Baru setelah hasil langkah 1 sampai 4 keluar, mintalah Claude Code menjalankan deploy produksi.

Cukup dengan mematuhi urutan ini, kecelakaan “halaman depan putih” seperti di pembuka hampir tidak akan terjadi. Sebab di langkah 3 Anda pasti membuka preview.

Batas yang diserahkan ke AI dan yang diputuskan manusia

Bukan menyerahkan semua ke AI, bukan pula mengembalikan semua ke pekerjaan manual. Bagi perannya. Tabel di bawah adalah garis batas di lapangan saya.

Situasi	Yang diserahkan ke Claude Code	Bukti yang dilihat manusia
Publikasi artikel	Jalankan dulu build dist dan cek otomatis URL publik	Hasil build, diff, URL
Ubah tombol pendaftaran	Cocokkan tujuan link dan jalur konsultasi di preview	Hasil build, diff, URL
Perbaikan Workers	Tanpa menyentuh environment variable, keluarkan log dry run saja	Hasil build, diff, URL

Intinya pembagian ini: pekerjaan membaca, menyusun, dan mengecek secara mekanis diserahkan ke AI, sedangkan operasi yang menambah perubahan tak terbalikkan ke produksi disetujui oleh manusia. Hapus data, tulis ke database produksi, penagihan, dan force push, di awal condongkan semuanya ke “tanya manusia dulu.” Hanya operasi yang sudah terbukti aman yang nanti dinaikkan statusnya menjadi otomatis.

Bagi yang ingin menetapkan batas izin lebih rinci, panduan setting permission Claude Code dan audit permission sebelum deploy bisa jadi rujukan.

Template prompt siap salin

Kuncinya jangan melempar tugas mentah-mentah, melainkan tegaskan “jangan rilis ke produksi dulu.” Tempel template berikut apa adanya.

Ubah perubahan ini menjadi "checklist dry run" sebelum deploy ke produksi.
Kembalikan item-item berikut dalam bentuk tabel.
- Hasil build (sukses / gagal beserta poin penting log)
- Risiko diff (apakah memuat info rahasia / penagihan / penghapusan)
- Preview URL
- Pemilik rollback dan command rollback
- Area yang tidak disentuh
- Syarat untuk mencoba ulang
Jangan jalankan deploy produksi dulu. Tunggu sampai saya memeriksa checklist-nya.

Dua baris terakhir itu yang manjur. Dengan menulis “jangan jalankan dulu” dan “tunggu sampai saya periksa,” Anda mencegah kecelakaan ketika Claude Code “berinisiatif” lalu mempublikasikan sendiri. Cara menulis prompt yang condong ke sisi aman juga saya rangkum di desain prompt untuk tingkat lanjut.

Skrip verifikasi yang langsung jalan

Kalau hasil verifikasi dinilai oleh mesin, bukan oleh “perasaan manusia,” kelolosan berkurang. Skrip berikut menerima objek hasil dry run, lalu mengembalikan nilai benar/salah apakah kondisinya sudah boleh meminta akses produksi. Selama ada Node.js, ini langsung jalan.

// Hasil dry run. Masukkan isi verifikasi yang sebenarnya di sini
const deployCheck = {
  build: "passed",              // apakah build lokal lolos
  diffReviewed: true,           // apakah diff sudah dilihat mata
  previewUrl: "https://example.pages.dev", // preview URL
  rollbackOwner: "Masa",        // pemilik rollback
  changedAreas: ["content", "cta-copy"],   // area yang disentuh
};

// Penjaga gerbang yang menilai apakah boleh meminta akses produksi
function canRequestProductionAccess(check) {
  return (
    check.build === "passed" &&          // build lolos
    check.diffReviewed &&                // diff sudah dilihat
    /^https:\/\//.test(check.previewUrl) && // preview URL ada dan https
    check.rollbackOwner.length > 0 &&    // pemilik rollback sudah ditetapkan
    !check.changedAreas.includes("secrets") // tidak menyentuh area rahasia
  );
}

const ready = canRequestProductionAccess(deployCheck);
console.log({ ready });
// Selama item yang false belum dipenuhi, jangan minta deploy produksi

Nilai kode ini ada pada bagian yang mengembalikan false begitu "secrets" masuk ke changedAreas. Dalam kondisi tidak sengaja menyentuh informasi rahasia, ia tidak akan pernah melaju sampai permintaan akses produksi. Sekalipun manusia sibuk dan lalai, penjaga gerbangnya menghentikan.

Tiga situasi tempat ini benar-benar berguna

Pertama, publikasi artikel. Kalau hanya bilang “tolong rilis blognya,” begitu build lolos, ia langsung melaju sampai publish. Dengan menyisipkan dry run, sebelum publish kita membuka URL publik dan memeriksa apakah judul dan isi cocok, sehingga kecelakaan layar putih di pembuka berhenti.

Kedua, penggantian tombol pendaftaran. Salah ketik satu huruf di tujuan link saja, jalur yang susah payah dibuat jatuh ke 404. Setelah saya memasukkan langkah menekan tombol langsung di preview untuk memastikan tujuannya, link rusak jadi nol.

Ketiga, perbaikan Cloudflare Workers. Di sini, menghapus satu environment variable saja sudah bisa menjatuhkan produksi. Karena itu saat dry run saya tidak biarkan ia menyentuh environment variable, cukup keluarkan log saja. Catatan khusus Workers juga saya rangkum di artikel integrasi Cloudflare Workers.

Jebakan yang sering terjadi dan cara memperbaikinya

Tiga kegagalan yang benar-benar pernah saya lakukan, beserta cara membenahinya.

Jebakan 1: menjalankan command produksi sebelum build. Kalau langsung menjalankan wrangler deploy, saat gagal Anda tidak bisa memisahkan apakah kodenya yang buruk atau lingkungannya. Cara membenahinya sederhana: selalu luluskan build lokal lebih dulu. Cukup mengubah satu urutan, penelusuran penyebab langsung jauh lebih cepat.

Jebakan 2: tidak menetapkan pemilik rollback. Kalau baru mulai berunding “siapa yang mengembalikan?” setelah gagal, dalam beberapa menit itu lonjakan akses langsung menghantam. Cara membenahinya: tuliskan pemilik rollback dan command rollback dalam bentuk teks pada tahap dry run. Sekadar mencatat previousDeployId saja sudah membuat pemulihan jadi tenang.

Jebakan 3: tidak membuka preview, hanya percaya kode status. HTTP 200 hanya berarti “server mengembalikan sesuatu,” bukan “halaman yang benar sudah muncul.” Cara membenahinya: pasti buka preview URL sekali di browser, lalu lihat dengan mata judul, URL kanonik, dan gambar hero. Inilah satu-satunya cara membongkar layar putih di pembuka.

Simpan bukti sebagai “catatan yang bisa dipakai lagi nanti”

Apa yang Anda verifikasi lewat dry run, jangan dibuang di tempat. Rangkum jadi catatan singkat, dan pekerjaan berikutnya akan jauh lebih cepat.

Yang perlu disimpan cukup segini: kalimat permintaan awal, area yang dibaca Claude Code, area yang tidak disentuh, command verifikasi yang dijalankan, URL publik atau screenshot, dan titik yang sempat membuat Anda ragu. Notulen panjang tidak perlu. Asal nanti Anda bisa menelusuri “kenapa keputusan ini diambil,” tujuannya sudah tercapai.

Yang paling manjur adalah menulis “titik percabangan keputusan” dalam satu baris. Misalnya, “preview URL sudah benar tetapi pemilik rollback belum ditetapkan, jadi produksi belum.” Saat lain kali mengerjakan tugas yang sama, baik Anda sendiri maupun orang lain bisa mereproduksi verifikasi yang sama. Pola pikir ini juga berlaku untuk otomasi selain deploy, jadi kalau dibaca bersama pengantar Claude Code untuk non-engineer, Anda akan menangkap rasa “bagaimana cara menyerahkan tugas.”

Pertanyaan umum

Q. Dry run pada akhirnya cuma menambah repot, kan? Awalnya terasa begitu. Tapi sekali kecelakaan terjadi, pemulihan dan penelusuran penyebab bisa menghabiskan berjam-jam. Dry run cuma beberapa menit. Saya menganggapnya asuransi yang sepadan, jadi saya teruskan.

Q. Kalau build lokal lolos, tidak perlu lihat preview? Tidak boleh. Walau build lolos, template bisa tertukar dan halaman bisa kosong. HTTP 200 dan “halaman yang benar” itu dua hal berbeda, jadi pemeriksaan mata tidak bisa dilewati.

Q. Pemilik rollback masih ada gunanya kalau saya sendirian? Ada. Sekalipun sendirian, dengan menuliskan “kalau gagal, kembalikan dengan command ini” lebih dulu, saat kecelakaan benar terjadi Anda tidak bingung. Keputusan itu sendiri menjadi prosedur.

Q. Kalau Claude Code bilang “sudah dipublikasikan,” boleh dipercaya? Lihat bukti dry run-nya, bukan jawabannya. Nilai dari apakah build, diff, preview, dan pemilik rollback sudah lengkap. Kata-kata itu suasana, bukti itu fakta.

Q. Apakah situs kecil pun perlu sampai sejauh ini? Pikirkan dari “apakah bisa dikembalikan,” bukan dari skala. Sekecil apa pun, kalau produksi jatuh tetap merepotkan. Mulai dengan satu langkah saja, yaitu membuka preview, dan Anda akan merasakan manfaatnya.

Hasil yang benar-benar saya coba

Setelah kecelakaan layar putih di pembuka, saya memasukkan prosedur dry run ini ke operasional blog saya sendiri.

Yang saya pastikan ada tiga hal. Pertama, setelah saya jadikan aturan untuk selalu membuka preview URL, halaman kosong akibat template tertukar menjadi nol. Kedua, setelah saya jalankan skrip verifikasi di atas sebelum publish, perubahan yang menyentuh area rahasia berhenti dengan ready: false dan tidak melaju sampai permintaan akses produksi. Ketiga, setelah saya catat pemilik rollback dan command rollback setiap kali, bahkan di situasi yang sempat bikin jantung copot saya bisa mengembalikan ke kondisi sebelumnya dalam beberapa menit.

Daripada menyerahkan semua ke AI yang pintar lalu berdoa, lebih baik membangun dulu pijakan yang tidak bikin terluka saat terjatuh. Terlihat memutar, tapi inilah yang pada akhirnya paling cepat, begitu rasa saya sekarang. Mulai dari satu langkah membuka preview saja, cobalah menambahkan penjaga gerbang pada deploy Anda sendiri.

Kalau Anda ingin menata garis batas deploy produksi dan sistem review hingga ke tingkat tim, kita bisa membuat prosedurnya bersama lewat pelatihan dan konsultasi. Untuk standar operasional resmi, rujuk juga dokumentasi Claude Code resmi dari Anthropic.