Calm Releases: Checklist 15 Menit Sebelum Deploy (Biar Tim Tetap Waras)

Beberapa orang menyebutnya “process”. Aku menyebutnya: menghindari penderitaan yang bisa dicegah.

Cerita singkat: sekali deploy, auth hampir bikin panik satu ruangan

Pernah ada deploy yang keliatannya aman karena “cuma refactor kecil”. Habis itu login flow di production tiba-tiba looping, dan callback auth balik error yang bikin user mental.

Ternyata root cause-nya kombinasi klasik: ENV di Vercel ada yang beda dari staging, dan satu perubahan kecil di redirect URL kebawa tanpa ke-notice. Untungnya Sentry langsung nangkep error pattern-nya, jadi gak nunggu komplain dulu baru sadar.

Pelajarannya sederhana: masalah release jarang “bug besar”, biasanya mismatch kecil yang lolos karena gak ada ritual 15 menit terakhir. Sejak itu, aku treat pre-deploy kayak seatbelt, bukan formalitas.

15-Minute Pre-Deploy Checklist

• Tulis scope release dalam 1 kalimat: apa yang berubah dan siapa yang kena.

• Lakuin smoke test cepat di staging/preview: login, flow utama, satu edge case.

• Pastikan migration sifatnya additive: tambah kolom/tabel dulu, breaking changes belakangan.

• Siapkan rollback plan: minimal tau “balik ke commit/tag mana” dan apa dampaknya.

• Cek Sentry: pastikan release tagging aktif, dan gak ada spike error yang belum beres.

• Validasi ENV vars di Vercel: key penting ada, value-nya bener, dan gak nyasar project lain.

• Siapkan post-deploy verify: endpoint/halaman apa yang harus “green” dalam 2 menit pertama.

Anti-patterns yang bikin deploy jadi drama

• Deploy tanpa rollback plan, lalu semua orang pura-pura berani.
  Solusinya: tentuin rollback path sebelum tombol deploy ditekan.

• Edit config langsung di prod karena “cuma sebentar”.
  Solusinya: semua config lewat ENV/setting yang tercatat, bukan clicky-clicky penuh dosa.

• Migration langsung breaking changes sekali jalan.
  Solusinya: lakukan rollout bertahap (additive first), baru cleanup setelah aman.

• “Fix di prod dulu” biar cepat, terus lupa balik.
  Solusinya: hotfix boleh, tapi harus ditutup dengan PR yang rapi dan catatan jelas.

Kode: pre-deploy env check + build/test (Node/TypeScript)

import { spawnSync } from "node:child_process";

const REQUIRED_ENVS = [
  "NEXT_PUBLIC_SUPABASE_URL",
  "NEXT_PUBLIC_SUPABASE_ANON_KEY",
  "SENTRY_AUTH_TOKEN",
  "SENTRY_DSN",
  "NEXT_PUBLIC_APP_URL",
];

function assertEnv() {
  const missing = REQUIRED_ENVS.filter((k) => !process.env[k]?.trim());
  if (missing.length) {
    console.error("Missing ENV vars:", missing.join(", "));
    process.exit(1);
  }
  if (!process.env.NEXT_PUBLIC_APP_URL?.startsWith("https://")) {
    console.error("NEXT_PUBLIC_APP_URL must start with https://");
    process.exit(1);
  }
}

function run(cmd: string, args: string[]) {
  const r = spawnSync(cmd, args, { stdio: "inherit", shell: true });
  if (r.status !== 0) process.exit(r.status ?? 1);
}

console.log("Pre-deploy checks...");
assertEnv();
run("npm", ["run", "lint"]);
run("npm", ["test", "--silent"]);
run("npm", ["run", "build"]);
console.log("OK. Ship it (calmly).");

COPY THIS

• Scope release ditulis 1 kalimat (what + who impacted)

• Checklist smoke test: login + main flow + 1 edge case

• ENV vars di Vercel dicek (key & value)

• Supabase migration aman (additive, gak nge-lock flow kritikal)

• Sentry DSN & release tagging aktif untuk build ini

• Error spike terakhir di Sentry udah dipahami, bukan “nanti aja”

• Rollback plan jelas (commit/tag + langkah balik)

• Post-deploy verify: endpoint/halaman yang wajib green ditentuin

• Catatan perubahan singkat disiapin buat tim/client non-teknis

• Setelah deploy: monitor 5 menit pertama (Sentry + flow utama)

Release yang tenang itu bukan gaya-gayaan “enterprise process”, itu cara paling murah buat menjaga trust. Kalau kamu bisa shipping tanpa panik, kamu keliatan kompeten tanpa harus banyak ngomong.

Aku lebih suka sistem yang bikin orang tidur nyenyak daripada cerita kepahlawanan yang sebenernya bisa dihindari.