Pendahuluan

CodeIgniter 4: Deployment Observability dan Rollback Otomatis membantu tim engineering menjaga rilis tetap stabil dengan menggabungkan pipeline CI/CD, metrik, logging, health check, serta rollback otomatis ketika kegagalan terdeteksi. Langkah-langkah berikut langsung menjawab kebutuhan utama: mengawasi aplikasi selama deploy, mendeteksi kegagalan, lalu mengembalikan versi sebelumnya ketika masalah kritis muncul.

Artikel ini menjelaskan cara membangun pipeline deployment praktis, menyiapkan observability untuk CodeIgniter 4, mengotomasi rollback, dan menangani insiden dengan mitigasi serta postmortem agar setiap rilis bermasalah menjadi pelajaran.

Membangun Pipeline Deployment CodeIgniter 4 dengan Observability

Arsitektur pipeline dasar

Pipeline harus mencakup satu set tahapan: build, test, deploy staging/production, dan verifikasi observability. Gunakan tool CI/CD pilihan (GitHub Actions, GitLab CI, atau Jenkins) yang menjalankan skrip seperti php spark test, composer install, dan migrasi database secara otomatis.

Tambahkan stage monitoring setelah deploy untuk menangkap log dan metrik sebelum menganggap rilis sukses. Misalnya, jalankan job yang memanggil endpoint health check dan menyimpan hasilnya ke sistem observability.

Log terpadu dan metrik nyata

Pastikan konfigurasi app/Config/Logger.php mengirim log ke file dan sistem eksternal (misal Fluentd/Elasticsearch). Di production, gunakan handler yang menandai log berlevel warning ke atas sehingga alert bisa dipicu. Di sisi metrik, integrasikan dengan Prometheus atau Grafana menggunakan middleware yang mencatat durasi request dan error rate.

Contoh middleware untuk metrik latency:

public function before(Request $request, $arguments = null) { $this->start = hrtime(true); }
public function after(Request $request, Response $response, $arguments = null) { $duration = (hrtime(true) - $this->start) / 1e6; Metrics::observe('http_request_duration_ms', $duration, ['route' => $request->uri->getPath()]); }

Pengamatan terus menerus membantu pipeline mengetahui saat deploy menyebabkan lonjakan error atau lambat, sebelum pengguna menyadarinya.

Deteksi Kegagalan Otomatis dengan Health Check dan Alerting

Health check terstruktur

Buat endpoint /health yang memeriksa koneksi database, kredensial cache, dan issuer token. Endpoint ini harus mengembalikan HTTP 200 hanya jika semua dependensi utama bekerja. Jangan lupa memberi timeout pendek agar layanan monitoring tidak terjebak.

Contoh rute sederhana:

public function health() { try { if (! $this->db->connID) throw new 
untimeException('db'); if (! $this->cache->isSupported()) throw new 
untimeException('cache'); return $this->response->setStatusCode(200)->setJSON(['status' => 'ok']); } catch (	hrowable $e) { return $this->response->setStatusCode(500)->setJSON(['status' => 'fail', 'reason' => $e->getMessage()]); } }

Integrasikan endpoint ini dengan sistem observability seperti Prometheus blackbox_exporter atau health check pada load balancer agar alert bisa dikirimkan ketika kegagalan muncul.

Alert yang men-trigger rollback

Tentukan rule alert yang menghitung error rate dan latency pasca-deploy. Misalnya, pada Grafana Alerting atau Alertmanager, buat rule: rate(http_server_errors_total[5m]) > 0.05.

Ketika alert aktif, pipeline harus bisa menghentikan deploy lebih lanjut dan memicu skrip rollback otomatis (lihat bagian berikut).

Rollback Otomatis dan Mitigasi Insiden Ringan

Strategi rollback yang terkendali

Rollback otomatis perlu mendeteksi kondisi kritis lalu mengembalikan versi sebelumnya. Umumnya dilakukan dengan menyimpan artefak deploy (misal release tarball) dan mengubah symlink current ke release sehat.

Contoh skrip deploy sederhana di server:

RELEASE_DIR=/var/www/releases/$(date +%s) ln -sfn $RELEASE_DIR /var/www/html

Setelah deploy gagal terdeteksi, jalankan skrip rollback:

PREV=$(readlink /var/www/releases/previous) ln -sfn $PREV /var/www/html systemctl restart php-fpm

Pasangkan dengan job CI/CD yang menerima webhook alert. Job tersebut bisa menggunakan API server atau SSH untuk mengembalikan symlink dan restart services.

Mitigasi insiden ringan sebelum rollback

Terkadang masalah bisa diatasi tanpa rollback, misalnya dengan mematikan fitur tertentu atau memperbaiki konfigurasi.

  • Feature toggle: Aktifkan flag untuk fitur baru sehingga bisa dimatikan ketika error terjadi, meminimalkan dampak rollback.
  • Cache cleanup: Jika error terkait cache migration, tambahkan job untuk membersihkan cache sementara.
  • Restart worker: Untuk queue worker bermasalah, jalankan php spark queue:work ulang.

Catat setiap tindakan mitigasi di log dan channel incident agar bisa dievaluasi di postmortem.

Postmortem dan Pencegahan untuk Rilis Berikutnya

Langkah postmortem

Setelah insiden, keluarkan postmortem yang mencakup:

  • Timeline: Kapan deploy dimulai, deteksi alert, dan aksi rollback.
  • Penyebab utama: Misalnya query lambat, konfigurasi environment, atau regressi aplikasi.
  • Aksi korektif: Patch bug, perbaiki konfigurasi, tambah test atau monitoring.
  • Aksi preventif: Tambahkan observability tambahan atau perbaiki pipeline untuk mendeteksi lebih awal.

Gunakan template postmortem standar agar bisa dibandingkan antar insiden.

Pencegahan rilis bermasalah

Tambahkan pendekatan berikut:

  • Canary Release: Deploy ke subset server terlebih dahulu untuk memvalidasi metrik sebelum full roll-out.
  • Rollback drill: Latih tim menjalankan rollback otomatis secara berkala agar prosedur tetap tajam.
  • Monitoring audit: Tinjau alert yang sering false positive dan sesuaikan threshold.

Dengan pendekatan ini, observability menjadi bagian integral dari deployment, bukan tambahan setelah masalah terjadi.

Penutup

Pipeline CodeIgniter 4 yang menggabungkan observability, deteksi kegagalan, rollback otomatis, dan postmortem memastikan tim bisa merespons rilis bermasalah secara cepat dan terstruktur. Fokus pada log, metrik, health check, dan tanggapan insiden akan meningkatkan kepercayaan build secara berkelanjutan.