Observability dan Rollback SvelteKit di Cloudflare Pages harus menjadi bagian dari deployment pipeline sejak awal. Jawaban langsungnya: kamu bisa menggabungkan pipeline build standar dengan pengumpulan metrics/log/tracing dari request, lalu menyiapkan release tag, feature flag, dan instrumentasi alert agar rollbacks dapat dilakukan tanpa harus menebak-nebak penyebab kegagalan.

Artikel ini membahas alur deployment, bagaimana mengumpulkan data observability yang berarti, persiapan rollback saat deployment bermasalah, tindakan pencegahan seperti validasi build dan health check, serta cara menjalankan postmortem ringan agar tim belajar dari kesalahan.

Alur Deployment SvelteKit ke Cloudflare Pages

Alur deployment yang konsisten mempertahankan tiga langkah utama: build, publish ke Cloudflare Pages, dan verifikasi pasca-deploy.

1. Build dengan validasi

Mulai dengan memastikan perintah build tidak hanya menghasilkan bundle, tapi juga menjalankan linting atau pengecekan tipe. Contoh pipeline:

npm install
npm run check   # SvelteKit, TypeScript, lint
npm run build

Perintah npm run check bisa disesuaikan untuk menjalankan tsc --noEmit dan eslint. Validasi ini memisahkan bug logis atau typing dari masalah runtime di Cloudflare Pages.

2. Publish ke Cloudflare Pages

Setelah build selesai, publish output statis. Jika menggunakan adapter static, path output default build atau ./build. Deployment menggunakan CLI Wrangler:

npx wrangler pages publish ./build --project-name=my-sveltekit-site --branch=main

Jika kamu men-trigger deployment dari GitHub Actions, pastikan langkah publish lambat atau timeout ditangani. Gunakan retry sederhana atau runner terisolasi.

3. Verifikasi pasca-deploy

Setelah berhasil publish, jalankan health check non-invasive terhadap endpoint utama.

curl -f https://example.pages.dev/health || exit 1

Pastikan endpoint /health hanya memeriksa bagian statis/edge yang dapat di-highlight dari SvelteKit (misalnya memanggil endpoint internal yang melakukan render ringan). Jika validasi gagal, rollback otomatis bisa di-trigger (lihat bagian rollback).

Observability: Metrics, Log, dan Tracing

Cloudflare Pages menyediakan observability dasar lewat analytics dan Logpush. Tambahkan observability aplikasi SvelteKit untuk mendapatkan data request/response yang lebih terperinci.

Metrics

Gunakan middleware di hooks.server.js untuk mencatat waktu render, status, dan path. Contoh sederhana mengirimkan metrik ke sistem eksternal (misalnya Cloudflare Metrics melalui custom worker):

import { metrics } from '$lib/metrics';

export async function handle({ event, resolve }) {
  const start = performance.now();
  const response = await resolve(event);
  const duration = performance.now() - start;
  event.waitUntil(metrics.record({
    route: event.url.pathname,
    status: response.status,
    duration
  }));
  return response;
}

Pastikan metrics.record tidak menunggu (gunakan event.waitUntil) agar tidak menambah latency. Tambahkan tag seperti status dan route agar metrik bisa dipilah di dashboard.

Logs

SvelteKit yang berjalan di Cloudflare Pages dapat menulis log dengan console.log atau mengirim ke Logpush. Gunakan format JSON khusus agar mudah diurai:

console.log(JSON.stringify({
  level: 'error',
  path: event.url.pathname,
  message: 'Gagal render',
  error: err.message
}));

Konfigurasikan Cloudflare Logpush agar mengirim log ke bucket S3 atau ke DataDog/Elasticsearch. Pastikan level log disaring sebelum masuk ke pipeline apabila log volume tinggi.

Tracing

Untuk tracing distribusi, integrasikan Sentry atau OpenTelemetry dengan middleware yang menangkap span per request. Tujuan utama adalah melihat apakah latency tinggi berasal dari SvelteKit merender halaman atau dari dependency lain (API, fetch). Menambahkan header trace ke request internal membantu menghubungkan trace Backend-Edge-Client.

Kesiapan Rollback dan Feature Flag

Menghadapi kegagalan deploy memerlukan rollback cepat. Kuncinya ada pada tagging release, feature flag, dan konfigurasi yang mudah diubah.

Tag release dan deployment versioned

Sebelum deploy, buat tag Git untuk menandai release yang sudah diuji:

git tag -a v2.1.0 -m "Deployment observability dan rollback"
git push origin v2.1.0

Jika deploy utama gagal, gunakan versi tag sebelumnya untuk publish ulang:

npx wrangler pages publish ./build --project-name=my-sveltekit-site --branch=v2.0.5

Alternatifnya, jika kamu menggunakan branch deployment untuk setiap release, rollback perlu memastikan branch tersebut menggabungkan tag yang stabil.

Feature flag dan konfigurasi dinamis

Gunakan feature flag berbasis environment variable yang dapat diubah tanpa deploy ulang. Contoh sederhana menggunakan config di src/lib/config.ts:

export const config = {
  newHeader: process.env.FEATURE_NEW_HEADER === 'true',
  apiEndpoint: process.env.API_ENDPOINT ?? 'https://default'
};

Dengan ini, jika fitur baru menyebabkan masalah rendering, cukup ubah environment variable di dashboard Cloudflare Pages tanpa membuat build baru. Catat perubahan tersebut di log deploy agar rollback konfigurasi terlihat.

Tindakan Pencegahan: Validasi, Health Check, dan Alert

Preventive action mencakup validasi build, health check, dan alert untuk mendeteksi anomali lebih awal.

  • Validasi linting dan testing: jalankan npm run test dan npm run check di pipeline CI sebelum publish.
  • Health check blade: endpoint /health mengembalikan status 200 dengan memeriksa dependency paling kritis. Tempelkan di skrip monitoring Cloudflare Workers atau uptime monitor eksternal.
  • Alert: manfaatkan Cloudflare Alerts untuk memicu ketika error rate > threshold atau ketika build gagal. Sertakan webhook ke Slack/Teams agar tim tahu kapan rollback perlu dijalankan.

Tambahkan deployment log di repositori yang mencatat SHA, tag release, waktu deploy, serta siapa yang melakukan deploy. Ini membantu saat menyusun postmortem.

Postmortem Ringan Setelah Deploy Gagal

Jika terjadi kegagalan, lakukan postmortem ringan tanpa mencari kambing hitam, tetapi fokus pada fakta. Contoh template singkat:

  • Apa yang terjadi: misalnya: "Error 500 saat render homepage setelah deploy 15.30".
  • Penyebab utama: misal: "Dependency API internal mengembalikan 503 karena token invalid".
  • Tindakan perbaikan: "Rollback ke tag v2.0.5, perbarui token, tambahkan test untuk validasi token sebelum deploy".
  • Langkah preventif: "Tambahkan health check dependency API dan warnakan alert ketika status 5xx".

Dokumentasikan timeline yang jelas (build start, publish, error, rollback). Tunggu notifikasi Cloudflare Analytics untuk memastikan rollback benar-benar stabil sebelum menutup postmortem.

Dengan alur yang konsisten mencakup observability penuh, rollback cepat, dan tindakan pencegahan, deployment SvelteKit di Cloudflare Pages akan bisa dijaga dalam kondisi dapat dipercaya bahkan di bawah tekanan.