Pada pipeline Nuxt.js berlapis, tujuan utama adalah menyalurkan build ke produksi dengan jaminan observability penuh dan kemampuan postmortem cepat ketika sesuatu tidak berjalan sesuai rencana. Artikel ini langsung menjawab cara menerapkan tahap build, canary/feature flag, dan produksi yang terukur, plus observability, rollback, dan checklist mitigasi pasca insiden.

Arsitektur Pipeline Nuxt.js 3 Tahap

Salah satu cara menjaga kestabilan adalah memisahkan proses deployment menjadi tiga tahapan: build, canary (atau feature flag), lalu produksi. Tahap pertama menghasilkan artefak statis dan server bundle, tahap kedua memasang artefak pada persinggahan terbatas untuk validasi perilaku nyata, dan tahap terakhir mempublikasikan ke seluruh layanan.

Tahap Build

Build seharusnya mencakup running npm run build di environment yang sudah di-cache dependency-nya. Simpan artefak seperti .nuxt, dist, dan hasil server bundle di storage CI/CD agar bisa dibagi ke tahap selanjutnya tanpa rebuild ulang. Di tahap ini juga jalankan linting dan unit test dasar agar bundel tidak memasukkan kode regesi.

Tahap Canary atau Feature Flag

Canary ditempatkan di cluster terbatas atau share percentage tertentu. Kombinasikan feature flag (misalnya melalui LaunchDarkly atau internal flag) agar pengguna terpilih bisa mengakses fitur baru. Penting menyiapkan observability terpisah untuk canary: log tambahan dengan konteks flag, metric latency per endpoint, dan alert threshold lebih agresif. Tahap ini juga yang paling cocok memasang deployment gate berbasiskan health check API dan metric custom.

Tahap Produksi

Setelah canary stabil selama jangka waktu tertentu dan tidak memicu alert kritis, promosikan artefak yang sama ke seluruh cluster. Hindari rebuild di tahap ini untuk memastikan identik. Gunakan rollout bertahap (rolling update) agar jika ada issue bisa langsung masuk ke rollback tanpa pengaruh luas.

Observability Real-time

Observability terintegrasi memudahkan deteksi regresi lebih awal. Di Nuxt.js, awasi tiga lapis: log, metric, dan alert.

  • Log: Kombinasikan server-side logging (misalnya Winston/ Pino) dengan trace ID yang dibawa dari client ke server. Laporkan error stack lengkap dan context request.
  • Metric: Gunakan exporter (Prometheus atau DataDog) untuk latency SSR, error rate, dan pool usage. Setiap stage deploy harus memiliki metric tag "stage:canary" atau "stage:production".
  • Alert: Pasang threshold error rate >2% untuk canary dan >1% di produksi, serta latency 95th percentile melebihi SLA. Alert harus terhubung ke saluran tim (Slack/Email) dengan playbook rollback langsung.

Observability real-time juga berarti health endpoint (misalnya /health) yang diuji oleh load balancer tiap 15 detik—cek response 2xx dan verifikasi cache dependencies.

Checkpoint Pencegahan Otomatis

Automasi mencegah propagasi isu. Berikut langkah utama:

  • Smoke Test: Jalankan post-deploy smoke test yang memanggil route kritis; jika gagal, script harus memicu rollback otomatis sebelum QA manual.
  • Health Check: Setelah deployment, sistem harus menunggu semua replica menandakan ready dan health check path valid. Jika timeout, tahap dapat diarahkan ke rollback atau pause otomatis.
  • Deployment Gate: Gunakan approval manual hanya bila metric canary menunjukkan indikasi stabil. Pipeline harus memblokir promosi ke produksi sampai gate disetujui.

Gate tersebut bisa berupa manual approval di GitHub Actions atau automated policy di Argo Rollouts.

Strategi Rollback dan Checklist Insiden

Rollback terarah berarti hanya mengganti versi layanan tertentu, bukan seluruh cluster. Terapkan strategi berikut:

  • Version Pinning: Simpan tag image/artefak, lalu rollback berarti kembali ke tag sebelumnya tanpa build ulang.
  • Deployment Gate Trigger: Jika latency atau error rate melampaui threshold, skrip harus men-trigger rollback skrip (misalnya kubectl rollout undo).
  • Checklist Pasca-Insiden: Segera setelah rollback, tim menjalankan checklist: (1) Dokumentasikan waktu start, (2) Detail alert, (3) Snapshot logs utama, (4) Konfirmasi stabilitas setelah rollback.

Debugging tip: Saat rollback, jangan langsung hapus canary; biarkan lognya tersedia untuk root cause diagnosis.

Contoh Postmortem Ringkas

Dokumentasi cepat membantu tim kecil menutup insiden tanpa birokrasi. Format sederhana:

  • Timeline: 10:22 Deploy canary; 10:27 Alert latency + rollback; 10:34 Stabil
  • Root Cause: Cache invalidation di middleware menyebabkan response header tidak cocok dengan SSR cache summary.
  • Tindakan Perbaikan: Tambahkan validasi header di build step dan perpanjang timeout cache purge.

Kesimpulan harus menyertakan follow-up action, owner, dan estimasi kapan dicek ulang.

Contoh GitHub Actions untuk Pipeline Multi-stage

name: Deploy Nuxt.js Berlapis

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 18
      - run: npm ci
      - run: npm run build
      - run: npm run test:unit
      - run: tar -czf nuxt-artifact.tar.gz .nuxt dist
      - uses: actions/upload-artifact@v4
        with:
          name: nuxt-artifact
          path: nuxt-artifact.tar.gz

  canary:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: nuxt-artifact
      - run: tar -xzf nuxt-artifact.tar.gz
      - run: ./scripts/deploy-canary.sh
      - run: ./scripts/smoke-test.sh && ./scripts/health-check.sh
      - run: ./scripts/gate-approval.sh

  production:
    needs: canary
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: nuxt-artifact
      - run: tar -xzf nuxt-artifact.tar.gz
      - run: ./scripts/deploy-production.sh

Pipeline ini menjaga artefak konsisten, menjalankan smoke test di canary, dan baru mempromosikan ke produksi setelah deployment gate sukses.

Penerapan pipeline seperti di atas membuat proses deploy Nuxt.js lebih terkendali, observability lebih tajam, serta postmortem dan rollback lebih cepat. Kuncinya adalah memikirkan observable sejak tahap build dan memastikan setiap insiden memiliki checklist mitigasi yang bisa dieksekusi tanpa menunggu rapat panjang.