Deployment Canary SvelteKit memberikan strategi rilis bertahap untuk meminimalkan risiko perubahan sambil tetap mempertahankan kecepatan iterasi. Dalam artikel ini akan dijelaskan bagaimana membangun pipeline GitHub Actions yang menghasilkan artefak, mengarahkan sebagian lalu lintas ke versi baru, memantau metrik penting secara ringan, mendeteksi degradasi, serta menjalankan rollback otomatis saat perlu.

Langkah-langkah ini cocok untuk tim frontend dengan kebutuhan observabilitas sederhana yang ingin memastikan kualitas rilis tanpa memperpanjang waktu delivery.

1. Pipeline Build dan Deployment Canary

Pipeline harus mencakup linting, testing, build, dan deployment ke environment canary sebelum promosi ke produksi. Gunakan GitHub Actions untuk orkestrasi, karena dapat mengotomasi seluruh proses serta integrasi dengan environment target (misalnya Vercel, Cloudflare Pages, atau server Node). Berikut contoh workflow sederhana:

name: Canary Deployment
on:
  push:
    branches: [main]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install deps
        run: npm ci
      - name: Run tests
        run: npm run test
      - name: Build SvelteKit
        run: npm run build
      - name: Deploy Canary
        run: |
          # asumsi CLI deployment custom
          DEPLOY_TARGET=canary npm run deploy
          echo "CANARY_URL=https://canary.example.com" >> $GITHUB_ENV
      - name: Notify Monitoring
        run: ./scripts/register-canary.sh "$CANARY_URL"

Penting untuk memisahkan deployment ke canary dari deployment utama sehingga hanya sebagian trafik diarahkan ke build baru. Script deployment (`npm run deploy`) bisa memanggil layanan edge atau meng-update konfigurasi load balancer untuk menambahkan backend baru pada pool canary.

Memastikan artefak dapat dipromosikan

Simpan artefak build untuk digunakan oleh tahap promosi. Misalnya, archive build output dan simpan dengan actions/upload-artifact. Setelah monitoring stabil, pipeline dapat mengambil artefak tersebut untuk roll-forward ke produksi tanpa rebuild.

2. Observabilitas Ringan: Metrics dan Logs

Observabilitas tidak harus berat. Fokus pada dua hal: latency dan error rate. Gunakan middleware sederhana pada hooks.server.js untuk mencatat waktu respons dan status.

export async function handle({ event, resolve }) {
  const start = Date.now();
  const response = await resolve(event);
  const duration = Date.now() - start;
  const status = response.status;
  console.log(JSON.stringify({ route: event.url.pathname, status, duration }));
  // Kirim ke endpoint metrics ringan (Prometheus pushgateway, Datadog, dst.)
  reportMetrics({ status, duration, route: event.url.pathname });
  return response;
}

Gunakan endpoint HTTP atau tool seperti Prometheus Pushgateway agar pipeline monitoring dapat membaca metrik latensi dan error. Buat metrik agregat:

  • Error rate: persentase respons 5xx dan 4xx selama periode canary.
  • p95 latency: waktu yang paling sering dikeluhkan pengguna nyata.
  • Traffic ratio: berapa persen permintaan diarahkan ke canary.

Untuk logging ringan, cukup kirim JSON ke file atau endpoint log berbasis file. Hindari dependencies berat, cukup gunakan console.log saat masih dalam lingkungan terkontrol dan shipping ke aggregator seperti Loki atau Elasticsearch.

3. Deteksi Degradasi dan Rollback Otomatis

Deteksi degradasi dilakukan dengan membandingkan nilai metrik canary dan baseline (produksi). Gunakan alat sederhana (script CLI atau GitHub Action custom) untuk menjalankan kueri ke sistem monitoring setiap beberapa menit.

#!/usr/bin/env bash
CANARY_ERROR=$(curl -s http://monitoring/metrics?query=error_rate_canary)
BASELINE_ERROR=$(curl -s http://monitoring/metrics?query=error_rate_prod)
if (( $(echo "$CANARY_ERROR > $BASELINE_ERROR + 0.01" | bc -l) )); then
  echo "Degradasi terdeteksi"
  exit 1
fi

Script ini dijalankan sebagai langkah setelah deployment canary atau secara periodik dengan cron internal GitHub Actions. Bila kondisi error rate atau latency melewati threshold (misalnya 1% di atas baseline), jalankan rollback otomatis:

  • Rollback dapat mengubah routing load balancer untuk menghapus backend canary.
  • Gunakan API provider (misal Cloudflare Workers) untuk mematikan release baru.
  • Update status di sistem tiket dan kirim notifikasi tim.

GitHub Actions dapat men-trigger rollback via job tersendiri yang dijalankan bila job monitoring mengeluarkan exit 1. Pastikan rollback bersifat idempotent untuk menghindari kondisi tertunda.

4. Verifikasi Pasca-Rilis

Setelah canary stabil, lakukan verifikasi tambahan sebelum promosi ke produksi penuh:

  1. Smoke test: jalankan skrip API sederhana yang memastikan route penting merespon dengan status 200.
  2. Real user validation: alokasikan 5-10% pengguna atau sesi internal untuk rilis baru agar bisa memantau pengalaman nyata.
  3. Monitor SLA: pastikan metrik uptime dan latensi tetap di bawah SLA selama minimal 10-15 menit.

Setelah verifikasi lulus, pipeline promosi mengambil artefak build dan melakukan deployment ke environment produksi yang lebih luas.

5. Checklist Postmortem Ringan

Jika rollout mengalami masalah, gunakan checklist berikut untuk memandu postmortem tanpa memakan waktu terlalu banyak:

  • Identifikasi metrik yang melampaui threshold dan waktu kejadian.
  • Catat langkah rollback dan siapa yang men-trigger.
  • Pastikan ada catatan perbedaan antara versi canary dan baseline (kode, konfigurasi, dependency).
  • Verifikasi apakah deteksi degradasi bekerja sesuai rencana.
  • Ambil tindakan preventif, seperti menambahkan test coverage atau menurunkan traffic canary berikutnya.

6. Pencegahan Regresi E2E saat Deployment

Untuk menjaga regression di lapisan e2e, lakukan tindakan berikut:

  • Jalankan suite e2e yang relevan sebelum men-trigger canary. Gunakan test runner seperti Playwright atau Cypress dengan konfigurasi yang mewakili user journey kritis.
  • Gunakan feature flag untuk mengisolasi perilaku baru dari jalur pengguna utama.
  • Integrasikan regression suite ke pipeline sebagai job terpisah yang wajib lulus sebelum deployment.
  • Terapkan canary traffic shaping berdasarkan header atau cookie sehingga hanya sesi yang sudah diuji menjalankan versi baru.

Penutup

Deployment Canary SvelteKit dengan monitoring ringan dan rollback otomatis memberikan keseimbangan antara kecepatan rilis dan ketenangan operasional. Pipeline yang terstruktur, observabilitas fokus metrik penting, serta automatisasi rollback membuat tim memiliki kendali saat perubahan diterapkan. Patuhi checklist ringan untuk postmortem dan pertahankan suite e2e, sehingga regresi dapat ditekan hingga level yang wajar.