Pipeline deployment otomatis untuk proyek Laravel harus menjamin kualitas rilis sekaligus menyediakan visibilitas dan opsi kembali cepat jika terjadi kegagalan. Artikel ini langsung menjelaskan bagaimana merancang pipeline CI/CD yang menggabungkan validasi kode, observability penuh, dan mekanisme rollback agar tim dapat menyelesaikan gangguan tanpa menunda fitur penting.

1. Dasar pipeline deployment otomatis yang dapat diandalkan

Mulailah dari fase yang jelas: checkout kode, instal dependensi, jalankan tes unit/integrasi, build aset, deploy ke staging, lalu ke produksi. Kerangka umum ini dapat diatur pada GitHub Actions, GitLab CI, atau tool sejenis. Contoh bagian job untuk Laravel pada GitHub Actions:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup PHP & Composer
        run: |
          composer install --no-scripts --no-progress
      - name: Jalankan tes
        run: php artisan test
      - name: Deploy ke server
        run: ./deploy.sh staging

Pastikan deploy script mengemas langkah seperti migrasi, cache clear, dan optimisasi config. Taruh setiap langkah pada stage terpisah agar kegagalan dapat dipantau dan rollback dipicu dari titik paling akhir.

2. Observability: metrik, logging, dan alert terintegrasi

Observability di pipeline bukan hanya monitoring server, tapi memantau setiap deploy. Gunakan metrik latency API, error rate, dan job queue depth dengan Grafana dan Prometheus atau layanan yang tersedia. Fokuskan pada metrik yang langsung berkaitan dengan deployment:

  • Durasi deploy: catat waktu dari permintaan deploy sampai selesai agar dapat mendeteksi gangguan pipeline.
  • Error rate: pantau exception Laravel dan error HTTP 5xx dari log web server.
  • Queue failure: hitung job queue gagal setelah deploy agar dapat rollback jika pekerjaan penting gagal.

Contoh alert berbasis Grafana/Prometheus:

ALERT DeployFailure
  IF increase(laravel_http_errors_total{status="5xx"}[5m]) > 10
  FOR 10m
  LABELS {severity="critical"}
  ANNOTATIONS {summary="Kenaikan HTTP 5xx setelah deploy"}

Atau untuk log berbasis Grafana Loki/Elastic: query terburu-buru seperti "source=nginx level=error status=500" bisa memicu alert. Dokumenkan arti tiap alert dan siapa penanggung jawabnya untuk mempersingkat waktu respon.

3. Validasi pra-deploy sebagai gate utama

Jangan hanya mengandalkan tes unit. Tambahkan validasi berikut di pipeline:

  • Static analysis: gunakan PHPStan/Psalm untuk menemukan bug logika lebih awal.
  • Linting config: periksa .env.example dan config caching agar tidak ada missing key di produksi.
  • Smoke test staging: jalankan skrip yang memanggil endpoint kritis (misal login, checkout) setelah deploy staging selesai.

Contoh bagian job smoke test (menggunakan cURL sederhana):

steps:
  - name: Smoke test staging
    run: |
      curl -f https://staging.example.com/api/health || exit 1

Jika salah satu dari validasi ini gagal, pipeline harus berhenti dan tidak meneruskan deploy ke produksi.

4. Strategi rollback cepat

Rollback harus bisa dijalankan otomatis maupun manual. Strategi umum:

  1. Deploy dengan versi tetap: deploy dijalankan ke direktori berbasis timestamp. Deploy rollback cukup mengubah symlink ke versi sebelumnya.
  2. Rollback database: hindari rollback schema otomatis di produksi kecuali benar-benar diperlukan. Gunakan migrasi yang aman dan dukung fixture rollback manual.
  3. Automated trigger: pipeline bisa memicu rollback jika alert metrik tertentu menyala dalam window deploy (misal error rate naik 5x dalam 5 menit).

Komunikasikan langkah rollback dalam runbook: siapa yang menjalankan, command apa yang dijalankan (misal ./deploy.sh rollback), dan bagaimana memverifikasi setelah rollback.

5. Postmortem ringan dan dokumentasi tindakan preventif

Setiap insiden deploy harus diakhiri dengan postmortem pendek yang menjawab pertanyaan:

  • Apa yang terjadi dan kapan?
  • Akar penyebab teknis (misal migration gagal due to missing column)?
  • Apa response pertama kali? (troubleshoot & rollback)
  • Tindakan preventif selanjutnya (update checklist, add test)?

Dokumentasikan postmortem dalam satu halaman ringkas; sertakan logs atau alert terkait. Misalnya: "Deploy 2024-04-08 gagal karena job queue goroutine menumpuk akibat rilis job worker baru". Tindakan pencegahan meliputi: menambahkan simulasi worker load sebelum deploy, memperpanjang timeout queue, dan menambahkan alert queue depth.

6. Checklist preventif untuk mengurangi risiko

Buat checklist deployment yang harus diverifikasi sebelum menyetujui merge ke main:

  • Tes unit dan integrasi sukses di pipeline.
  • Smoketest endpoints utama di staging.
  • Log dan metrik sudah siap dipantau (Grafana dashboard refresh).
  • Migration sudah diperiksa untuk backward compatibility.
  • Tim respons siap (on-call) dengan panduan rollback.

Checklist bisa dijadikan template PR review, memastikan tidak ada langkah penting terlewat.

Kesimpulan

Pipeline deployment otomatis Laravel yang efektif menggabungkan validasi pra-deploy, observability lengkap, dan strategi rollback terencana. Dengan metrik berorientasi hasil, postmortem ringan, dan checklist preventif, tim dapat merilis fitur baru dengan kecepatan tanpa mengorbankan stabilitas.