SvelteKit: Blue-Green Deploy dengan Rollback Cepat dan Alerting Dasar

SvelteKit: blue-green deploy adalah strategi rilis yang membantu Anda memindahkan trafik ke versi baru dengan risiko lebih rendah dan rollback yang cepat saat terjadi masalah. Untuk aplikasi SvelteKit yang dijalankan sebagai proses Node di belakang reverse proxy atau load balancer, pola ini relatif sederhana: siapkan dua lingkungan identik, uji versi baru di lingkungan pasif, alihkan trafik, lalu pertahankan versi lama sebagai jalur mundur.

Artikel ini fokus pada implementasi praktis untuk tim kecil: alur build, health check, smoke test, cutover trafik, rollback cepat, metrik minimum yang perlu dipantau, dan alerting dasar. Contoh disusun agar tidak terlalu bergantung pada provider tertentu, sehingga bisa diterapkan pada VM, bare metal, atau container.

Kapan blue-green deploy cocok untuk SvelteKit

Blue-green deploy cocok bila Anda menjalankan SvelteKit sebagai layanan Node dan ingin menghindari downtime saat rilis. Dengan pendekatan ini, ada dua environment produksi:

Blue: versi yang sedang menerima trafik.
Green: versi kandidat yang sudah dibuild dan disiapkan, tetapi belum menerima trafik publik.

Ketika versi Green lolos verifikasi, reverse proxy atau load balancer memindahkan trafik dari Blue ke Green. Jika muncul error setelah cutover, trafik bisa segera dikembalikan ke Blue tanpa menunggu proses redeploy.

Pendekatan ini lebih aman dibanding mengganti binary atau restart langsung di node aktif, terutama bila aplikasi memiliki SSR, integrasi API eksternal, atau perubahan konfigurasi runtime yang berisiko.

Trade-off yang perlu dipahami

Butuh resource ganda karena dua versi aktif berjalan bersamaan selama proses deploy.
Perlu disiplin kompatibilitas untuk konfigurasi, session, dan database migration.
Rollback aplikasi cepat, tetapi rollback schema database tidak selalu cepat atau aman.

Untuk itu, perubahan database sebaiknya dirancang kompatibel maju-mundur (backward/forward compatible) setidaknya selama jendela deploy.

Arsitektur sederhana: SvelteKit adapter Node di belakang reverse proxy

Secara umum, alurnya seperti ini:

CI/CD membuild artefak SvelteKit.
Artefak dipasang ke environment pasif, misalnya Green.
Proses Node Green dijalankan pada port terpisah.
Reverse proxy melakukan health check dan/atau pengalihan upstream.
Smoke test dijalankan ke Green.
Jika lolos, trafik dipindahkan dari Blue ke Green.
Monitoring memantau error rate, latency, restart, dan health endpoint.
Jika ada insiden, rollback dilakukan dengan mengarahkan trafik kembali ke Blue.

Untuk SvelteKit, skenario umum adalah menggunakan adapter Node sehingga hasil build menghasilkan server Node yang bisa dijalankan sebagai proses mandiri. Reverse proxy seperti Nginx, HAProxy, atau load balancer lain berada di depan dan meneruskan trafik ke instance aktif.

Contoh topologi

Reverse proxy menerima request HTTPS publik.
Blue app berjalan di port 3001.
Green app berjalan di port 3002.
Health endpoint tersedia pada masing-masing versi.
Observability mengumpulkan log, metrik, dan status proses.

Jika Anda menggunakan session state di memory proses Node, blue-green bisa memicu masalah saat cutover. Simpan session di store eksternal atau gunakan pendekatan stateless bila memungkinkan.

Menyiapkan build dan runtime SvelteKit

Build artefak yang konsisten

Target utama deploy adalah artefak yang sama antara pengujian dan produksi. Hindari membuild ulang secara manual di server produksi bila tidak perlu. Simpan hasil build beserta informasi versi, misalnya commit SHA.

Contoh langkah umum:

npm ci
npm run build

# arsipkan output build dan file runtime yang diperlukan
# misalnya: build/, package.json, package-lock.json, static assets, env template

Prinsip pentingnya:

Pin dependency lewat lockfile.
Bedakan build-time dan runtime config.
Sertakan metadata rilis seperti commit SHA atau release ID untuk memudahkan triage.

Menjalankan dua versi secara paralel

Blue dan Green harus bisa berjalan bersamaan tanpa bentrok. Cara termudah adalah memberi port berbeda dan direktori rilis terpisah.

/srv/myapp/releases/2026-06-16-001/
/srv/myapp/releases/2026-06-16-002/

BLUE_PORT=3001
GREEN_PORT=3002

Jika memakai process manager seperti systemd, supervisord, atau mekanisme container, pastikan masing-masing environment dapat:

membaca environment variable yang benar,
menulis log ke lokasi yang mudah dicari,
di-restart independen,
dikenali statusnya oleh monitoring.

Health check untuk SvelteKit yang benar-benar berguna

Health check bukan sekadar endpoint yang selalu mengembalikan 200 OK. Untuk deploy aman, ada dua level health check:

Liveness check: proses hidup dan bisa merespons.
Readiness check: aplikasi siap menerima trafik nyata.

Dalam banyak kasus kecil, satu endpoint /health sudah cukup, asalkan isinya relevan. Minimal, endpoint sebaiknya memverifikasi:

server HTTP merespons,
konfigurasi runtime termuat,
dependensi penting yang wajib saat request tersedia, misalnya koneksi ke API internal atau database bila benar-benar diperlukan untuk halaman utama.

Jangan membuat health check terlalu berat. Jika endpoint memanggil banyak layanan eksternal, false alarm akan meningkat dan deploy menjadi lambat.

Contoh endpoint health sederhana

// src/routes/health/+server.ts
import { json } from '@sveltejs/kit';

export async function GET() {
  const startedAt = process.uptime();

  // Tambahkan pemeriksaan ringan bila perlu,
  // misalnya validasi env penting atau ping singkat ke dependency kritikal.

  return json({
    status: 'ok',
    uptime_seconds: Math.floor(startedAt),
    version: process.env.RELEASE_ID ?? 'unknown'
  });
}

Endpoint ini berguna untuk:

verifikasi bahwa instance Blue/Green yang benar sedang berjalan,
menampilkan versi rilis saat triage,
memberi sinyal dasar ke reverse proxy atau monitoring.

Kapan health check harus gagal

Endpoint health sebaiknya gagal bila aplikasi memang tidak layak menerima trafik, misalnya:

variabel environment wajib tidak tersedia,
dependency internal yang kritikal gagal total,
aplikasi masuk mode degradasi yang tidak aman untuk request baru.

Namun, bila beberapa fitur non-kritis sedang bermasalah, pertimbangkan tetap mengembalikan status sehat sambil mencatat degradasi di log atau metrik. Tujuannya agar deploy tidak memutus seluruh layanan karena satu fitur tambahan.

Smoke test sebelum cutover trafik

Health check hanya memastikan aplikasi hidup. Smoke test memastikan alur penting benar-benar berfungsi. Untuk SvelteKit, smoke test sebaiknya menyentuh jalur SSR dan aset statis.

Minimal lakukan:

request ke halaman utama,
request ke satu route dinamis penting,
request ke asset statis utama,
validasi respons bukan 500 dan mengandung marker tertentu.

Contoh smoke test sederhana

# Green berjalan di port 3002
curl -fsS http://127.0.0.1:3002/health
curl -fsS http://127.0.0.1:3002/ | grep -q '<body'
curl -fsS http://127.0.0.1:3002/produk/contoh | grep -q 'Produk'
curl -fsS http://127.0.0.1:3002/favicon.png > /dev/null

Anda bisa menambahkan uji login atau API internal, tetapi jaga agar tetap cepat. Tujuan smoke test adalah menangkap kegagalan besar seperti:

build rusak,
env salah,
SSR gagal saat route tertentu diakses,
asset tidak ditemukan,
dependency kritikal tidak bisa diakses.

Kesalahan umum adalah hanya menguji /health lalu langsung cutover. Banyak bug produksi baru muncul saat route SSR tertentu dipanggil atau saat aplikasi membutuhkan env yang tidak dipakai oleh health endpoint.

Cutover trafik di reverse proxy atau load balancer

Pada blue-green deploy, cutover idealnya sesederhana mungkin: ubah upstream aktif dari Blue ke Green. Prinsip ini membuat rollback juga sederhana.

Contoh konsep dengan reverse proxy

Berikut contoh konfigurasi Nginx yang menunjukkan ide dasarnya. Nilai detail dapat berbeda sesuai lingkungan Anda.

upstream sveltekit_active {
    server 127.0.0.1:3001;
    # saat cutover, ganti ke 127.0.0.1:3002 lalu reload nginx
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://sveltekit_active;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Alur cutover:

Blue aktif di proxy.
Deploy Green di port lain.
Jalankan health check dan smoke test ke Green secara langsung.
Ganti upstream aktif ke Green.
Reload proxy tanpa memutus koneksi aktif bila didukung.
Pantau metrik beberapa menit pertama dengan ketat.

Pada load balancer yang mendukung weight atau target group, Anda juga bisa memulai dengan trafik kecil ke Green. Namun untuk tim kecil, cutover penuh sering lebih mudah dioperasikan dan lebih mudah di-rollback, selama smoke test dan observability memadai.

Mengapa cutover lewat proxy lebih aman

Tidak perlu menghentikan versi lama saat versi baru mulai menerima trafik.
Rollback cepat cukup dengan mengembalikan upstream aktif.
Proses deploy dan validasi terpisah, sehingga diagnosis lebih jelas.

Rollback cepat saat rilis bermasalah

Rollback pada blue-green deploy harus dianggap sebagai operasi normal, bukan kegagalan prosedur. Jika metrik atau gejala menunjukkan versi baru bermasalah, tujuan pertama adalah mengurangi dampak ke pengguna, bukan mencari akar masalah saat itu juga.

Kapan rollback harus dipicu

Contoh sinyal yang layak memicu rollback:

error rate naik tajam setelah cutover,
latency meningkat signifikan dan konsisten,
proses Green restart berulang,
health endpoint Green mulai gagal,
smoke test pasca-cutover gagal.

Langkah rollback yang efektif

Alihkan trafik kembali ke Blue di reverse proxy atau load balancer.
Verifikasi Blue sehat dan error rate turun.
Bekukan deploy lanjutan.
Kumpulkan log dan metrik dari Green.
Identifikasi penyebab sebelum mencoba rilis ulang.

Hindari menghapus Green terlalu cepat. Instance bermasalah justru berisi bukti penting untuk investigasi: log startup, env, response error, dan pola restart.

Metrik minimum yang wajib dipantau

Untuk deploy aman, Anda tidak perlu observability yang sangat kompleks di awal. Namun ada empat metrik minimum yang sebaiknya selalu ada.

1. Error rate

Pantau persentase atau jumlah respons 5xx, serta bila relevan 4xx tertentu yang melonjak akibat bug rilis. Error rate adalah sinyal paling cepat bahwa versi baru gagal melayani request nyata.

Yang perlu diperhatikan:

bandingkan sebelum dan sesudah cutover,
pecah per route penting bila memungkinkan,
korelasikan dengan log stack trace dan release ID.

2. Latency

Pantau latency untuk request utama, minimal p95 atau ukuran distribusi lain yang konsisten di sistem Anda. Rata-rata saja sering menipu karena lonjakan di sebagian kecil request bisa tidak terlihat.

Peningkatan latency setelah deploy sering terkait dengan:

SSR yang melakukan query atau fetch lebih lambat,
cache tidak bekerja,
dependency eksternal timeout,
event loop Node terhambat oleh pekerjaan berat.

3. Restart proses

Jika proses Node sering restart, ada kemungkinan crash, memory pressure, env salah, atau masalah startup. Ini metrik yang sering terlewat, padahal sangat penting setelah rilis.

Minimal pantau:

jumlah restart per release,
exit code atau alasan restart,
waktu startup hingga siap menerima trafik.

4. Health endpoint

Health endpoint harus dipantau dari luar proses aplikasi. Dengan begitu Anda tahu apakah instance masih dapat dijangkau dan masih layak menerima trafik.

Pantau:

status sukses/gagal,
waktu respons health check,
versi release yang sedang aktif.

Alerting dasar yang cukup untuk tim kecil

Alerting dasar seharusnya sederhana, jelas, dan bisa ditindaklanjuti. Terlalu banyak alert justru membuat deploy bermasalah sulit dibedakan dari noise.

Aturan alert minimum

Error rate tinggi selama beberapa menit setelah deploy.
Latency meningkat konsisten pada endpoint penting.
Restart proses lebih dari ambang wajar dalam jangka pendek.
Health endpoint gagal pada instance aktif.

Agar tidak berisik, gunakan prinsip:

alert berdasarkan durasi singkat yang masuk akal, bukan satu titik data,
sertakan release ID dan environment pada pesan alert,
bedakan severity antara warning dan critical.

Contoh isi alert yang baik

[CRITICAL] myapp-green error rate meningkat setelah deploy
release=2026-06-16-002
active_env=green
symptom=5xx naik pada route SSR utama
next_action=rollback ke blue dan cek log startup + env API_BASE_URL

Alert seperti ini lebih berguna daripada pesan generik seperti “server down”, karena memberi konteks dan langkah awal yang jelas.

Contoh alur deploy blue-green untuk SvelteKit

Build artefak SvelteKit di CI.
Publish artefak ke server atau registry internal.
Deploy ke Green tanpa mengubah trafik aktif.
Start proses Green di port terpisah.
Verifikasi health check Green.
Jalankan smoke test ke Green.
Cutover trafik dari Blue ke Green.
Pantau metrik 5-15 menit pertama dengan ketat.
Tetapkan Green sebagai aktif dan pertahankan Blue untuk rollback sementara.
Bersihkan versi lama setelah masa aman berlalu.

Untuk aplikasi dengan database migration, letakkan migration pada tahap yang aman. Hindari perubahan schema yang membuat Blue langsung rusak setelah Green aktif, karena itu akan menghilangkan manfaat rollback cepat.

Contoh insiden singkat setelah deploy

Gejala

Lima menit setelah cutover ke Green, alert menunjukkan error rate naik pada halaman produk SSR. Health endpoint masih 200 OK, tetapi latency juga meningkat. Log Green memperlihatkan banyak error saat memanggil API internal.

Triage cepat

Konfirmasi waktu mulai gangguan bertepatan dengan cutover.
Bandingkan metrik Blue dan Green.
Cek log Green berdasarkan release ID.
Uji route yang gagal langsung ke port Green.

Ditemukan bahwa variabel environment API_BASE_URL di Green mengarah ke endpoint yang salah. Health endpoint tidak menangkap ini karena hanya memeriksa proses hidup, bukan jalur request SSR yang benar-benar memakai API tersebut.

Rollback

Alihkan trafik kembali ke Blue.
Verifikasi error rate turun dan latency kembali normal.
Biarkan Green tetap hidup untuk investigasi.

Perbaikan

Perbaiki environment Green.
Tambahkan smoke test untuk route SSR yang memakai API internal.
Pertimbangkan readiness check ringan yang memvalidasi dependency kritikal tersebut.

Postmortem ringan yang fokus pada pencegahan

Ringkasan postmortem yang berguna biasanya cukup singkat:

Apa yang terjadi: deploy Green memakai env API yang salah.
Dampak: request SSR halaman produk menghasilkan 5xx setelah cutover.
Deteksi: alert error rate dan latency pasca-deploy.
Akar masalah: validasi sebelum cutover belum mencakup route yang memakai API internal.
Pencegahan: tambahkan checklist env, smoke test route kritikal, dan metadata release di health endpoint.

Fokus pencegahan sebaiknya pada perbaikan sistem, bukan menyalahkan operator. Jika rollback cepat berhasil, itu berarti desain operasional Anda sudah berada di jalur yang benar.

Kesalahan umum saat menerapkan blue-green deploy

Health check terlalu dangkal sehingga bug SSR lolos.
Migration database tidak kompatibel dan membuat Blue tidak bisa dipakai lagi saat rollback.
Session lokal di memory menyebabkan pengguna logout atau state hilang saat cutover.
Tidak ada release ID sehingga log dan metrik sulit dikaitkan ke rilis tertentu.
Alert terlalu banyak dan tim tidak tahu mana yang benar-benar mendesak.
Rollback belum dilatih sehingga saat insiden justru bingung prosedurnya.

Checklist rilis aman untuk tim kecil

Gunakan checklist singkat berikut sebelum setiap deploy produksi:

Artefak build berasal dari CI dan identik dengan yang diuji.
Release ID atau commit SHA tersedia di log dan health endpoint.
Blue dan Green bisa berjalan paralel pada port atau target terpisah.
Environment variable Green sudah diverifikasi.
Health endpoint memeriksa kondisi minimum yang benar-benar penting.
Smoke test mencakup halaman utama, satu route SSR penting, dan aset statis.
Reverse proxy atau load balancer siap cutover dan rollback cepat.
Metrik error rate, latency, restart, dan health endpoint aktif.
Alert pasca-deploy dikirim ke kanal yang dipantau tim.
Perubahan database kompatibel dengan rollback aplikasi.
Operator tahu langkah rollback tanpa improvisasi.
Versi Blue dipertahankan sampai Green stabil dalam jendela observasi.

Penutup

SvelteKit: blue-green deploy bukan hanya soal punya dua environment, tetapi tentang memisahkan tahap validasi dari tahap menerima trafik. Dengan adapter Node di belakang reverse proxy, Anda bisa membangun proses rilis yang aman: build konsisten, health check yang bermakna, smoke test yang relevan, cutover sederhana, dan rollback cepat.

Untuk tim kecil, fondasi yang paling penting bukan alat paling canggih, melainkan disiplin operasional: endpoint health yang benar, metrik minimum yang dipantau, alert yang bisa ditindaklanjuti, serta checklist rilis yang selalu dipakai. Jika itu konsisten, risiko deploy bermasalah pada aplikasi SvelteKit akan jauh lebih terkendali.

Quick Search

shopping_cart Keranjang