Pada pipeline otomatis untuk Otomasi Rilis SvelteKit, tujuan utamanya adalah memastikan setiap perubahan lulus linting/testing Vite, terbangun dengan benar, dan diuji via canary sebelum rollout penuh. Artikel ini menjelaskan alur lengkap GitHub Actions yang melibatkan cache dependensi, build, canary deployment, persetujuan manual untuk rollback, dan notifikasi ke Slack/Discord.

Pipeline di bawah membantu meminimalkan risiko produksi dengan mendorong validasi awal lalu memberikan kontrol operator sebelum release lengkap.

1. Struktur dasar pipeline GitHub Actions

Gunakan satu workflow dengan beberapa job berurutan yang saling tergantung. Contoh hirarki minimal:

  • lint-test: menjalankan linting dan unit test berbasis Vite.
  • build: membuat artefak produksi.
  • deploy-canary: mendorong build ke staging/canary environment.
  • approval: job manual untuk verifikasi manusia sebelum rollout penuh.
  • deploy-production: rollout sebenarnya setelah approval.

Setiap job sebaiknya berjalan di runner ubuntu-latest dengan cache node_modules dan file lock sehingga lebih cepat.

2. Linting dan testing berbasis Vite

Gunakan script NPM/pnpm yang sesuai. Contoh langkah job lint-test:

jobs:
  lint-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: |
            node_modules
            .pnpm-store
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json', '**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-node-
      - name: Install dependencies
        run: npm ci
      - name: Run lint
        run: npm run lint
      - name: Run test
        run: npm run test:unit

Cache menyimpan baik node_modules maupun store pnpm (jika digunakan), mempercepat install berikutnya. Hash lockfile memastikan cache invalidasi saat versi dependensi berubah.

3. Build produksi dengan artefak tahan banting

Job build bergantung pada lint-test untuk menjaga kualitas. Tambahkan artefak agar job deployment menggunakan output yang sama:

  build:
    needs: lint-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Restore cache
        uses: actions/cache@v4
        with:
          path: node_modules
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      - run: npm ci
      - run: npm run build
      - name: Upload build
        uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: build/

Jika Anda menggunakan adapter seperti adapter-node atau adapter-static, pastikan npm run build menghasilkan direktori yang konsisten untuk deployment.

4. Deploy canary ke lingkungan staging

Deploy canary harus mengambil artefak build lalu mengirimkannya ke staging via hosting atau platform cloud. Contoh job SvelteKit menggunakan scp atau CLI provider:

  deploy-canary:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build-output
      - name: Sync ke staging
        run: |
          rsync -avz build/ user@staging:/var/www/app
        env:
          SSH_PRIVATE_KEY: ${{ secrets.STAGING_SSH_KEY }}
          DEPLOY_TARGET: staging
      - name: Notify staging
        run: echo "Canary deployment selesai"

Gunakan secrets untuk menyimpan kunci SSH dan variabel target, jangan langsung di-commit. Pastikan environment staging memiliki monitoring untuk memverifikasi kesehatan.

5. Persetujuan manual dan rollback

Untuk rollback dan kontrol, tambahkan job manual berbasis workflow_dispatch atau environment protection rules:

  wait-for-approval:
    needs: deploy-canary
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://production.example.com
    steps:
      - name: Tunggu persetujuan
        run: echo "Menunggu approval sebelum production"

Environment protection di GitHub memungkinkan Anda menambahkan reviewer yang harus menyetujui sebelum job berikutnya berjalan. Untuk rollback cepat, siapkan skrip deployment yang bisa menarik versi sebelumnya menggunakan tag.

6. Notifikasi Slack/Discord

Integrasi notifikasi menjaga tim selalu tahu status pipeline. Gunakan action resmi untuk Slack/Discord dengan webhook yang disimpan di secrets:

  notify:
    needs: [deploy-canary, wait-for-approval]
    runs-on: ubuntu-latest
    steps:
      - name: Kirim notifikasi Slack
        uses: rtCamp/action-slack-notify@v2
        with:
          webhook_url: ${{ secrets.SLACK_WEBHOOK_URL }}
          message: "Pipeline SvelteKit berhasil deploy canary"
      - name: Kirim notifikasi Discord
        uses: 8398a7/action-discord@v3
        with:
          webhook_id: ${{ secrets.DISCORD_WEBHOOK_ID }}
          webhook_token: ${{ secrets.DISCORD_WEBHOOK_TOKEN }}
          message: "Canary deployment siap untuk di-approve"

Pisahkan webhook untuk Slack dan Discord agar bisa mengirimkan notifikasi berbeda berdasarkan stage. Jangan lupa untuk mencatat channel mana yang menerima pesan status.

7. Validasi canary sebelum rollout penuh

Validasi dapat dilakukan secara otomatis (monitoring, smoke test) dan manual (QA). Pertimbangkan langkah berikut:

  • Jalankan smoke test API atau UI ringan terhadap canary endpoint setelah deployment.
  • Pantau metrik utama (error rate, latensi) selama periode tertentu sebelum approval.
  • Gunakan label atau feature flag untuk melayani sebagian pengguna dari canary environment.
  • Sertakan hasil validasi di komentar pull request atau notifikasi agar reviewer tahu apakah canary sehat.

Jika smoke test gagal, job bisa menghentikan pipeline dan mengirim alert. Selalu simpan logs pipeline untuk debugging.

8. Checklist Developer Experience (DX)

Untuk memastikan katalog rilis tetap sehat, sertakan checklist DX berikut:

  1. Pipeline lint-test di-trigger setiap commit ke branch utama.
  2. Cache dependensi aktif dengan key berbasis lockfile.
  3. Build artifacts diunggah dan digunakan kembali tanpa rebuild ulang.
  4. Deploy canary otomatis dengan variabel lingkungan yang ditetapkan.
  5. Approval manual dijaga dengan environment protection sebelum production.
  6. Notifikasi dikirim ke Slack/Discord untuk setiap stage penting.
  7. Validasi canary terdokumentasi dan mudah diakses tim QA.
  8. Rollback manual tersedia via tag atau skrip deployment.

Dengan memastikan setiap poin terpenuhi, tim dapat meminimalkan risiko sambil tetap menjaga kecepatan rilis.