Blue-green deploy pada CodeIgniter 4 adalah cara rilis aplikasi dengan menyiapkan dua environment identik, lalu memindahkan trafik dari versi lama ke versi baru secara cepat. Strategi ini berguna untuk mengurangi downtime, mempercepat rollback, dan membuat verifikasi pasca-rilis lebih terukur.

Untuk aplikasi web PHP seperti CodeIgniter 4, pendekatan ini paling efektif bila digabung dengan health check, migrasi database yang kompatibel, sinkronisasi konfigurasi lingkungan, serta observability minimum berupa log, metrik, dan alert. Fokus artikel ini adalah langkah implementatif yang bisa langsung dipakai, bukan teori panjang.

Arsitektur singkat blue-green untuk CodeIgniter 4

Konsep dasarnya sederhana:

  • Blue: environment yang saat ini melayani trafik produksi.
  • Green: environment kandidat rilis baru.
  • Load balancer / reverse proxy: komponen yang mengarahkan trafik ke Blue atau Green.
  • Shared dependency: biasanya database, cache, object storage, dan layanan pihak ketiga tetap dipakai bersama.

Pada implementasi praktis, Blue dan Green idealnya memiliki:

  • Versi PHP dan ekstensi yang sama.
  • Konfigurasi web server yang sama.
  • Isi file aplikasi yang berbeda sesuai rilis.
  • Variabel environment yang setara, kecuali nilai yang memang berbeda per slot.

Contoh alur tingkat tinggi:

  1. Blue aktif di produksi.
  2. Deploy rilis baru ke Green.
  3. Jalankan install dependency, cache config, dan verifikasi health check di Green.
  4. Jalankan migrasi database yang aman dan kompatibel.
  5. Pindahkan trafik dari Blue ke Green.
  6. Pantau error rate, latensi, dan health check.
  7. Jika ada masalah, rollback dengan mengembalikan trafik ke Blue.

Catatan penting: rollback aplikasi cepat bukan berarti rollback database juga aman. Desain migrasi harus mendukung kompatibilitas dua versi aplikasi selama masa transisi.

Komponen minimum yang perlu disiapkan

1. Dua slot aplikasi

Anda bisa menggunakan dua VM, dua direktori release pada host yang berbeda, atau dua deployment terpisah di container/orchestrator. Yang penting, Blue dan Green benar-benar bisa hidup berdampingan.

2. Reverse proxy atau load balancer

Nginx, HAProxy, atau load balancer cloud bisa dipakai. Tujuannya adalah melakukan cutover cepat tanpa mengubah kode aplikasi.

Contoh konsep upstream di Nginx:

upstream ci4_blue {
    server 10.0.1.10:8080;
}

upstream ci4_green {
    server 10.0.1.11:8080;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://ci4_blue;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Saat cutover, target proxy_pass atau upstream aktif diganti dari Blue ke Green, lalu reload konfigurasi secara aman.

3. Endpoint health check

Health check harus cukup ringan untuk dipanggil berkala, tetapi cukup bermakna untuk mendeteksi masalah dasar aplikasi.

Pada CodeIgniter 4, buat endpoint sederhana yang memeriksa:

  • Aplikasi dapat merespons HTTP dengan benar.
  • Koneksi database berhasil.
  • Dependency penting tersedia jika memang kritikal.

Contoh controller health check:

<?php

namespace App\Controllers;

use CodeIgniter\HTTP\ResponseInterface;
use Config\Database;

class Health extends BaseController
{
    public function index(): ResponseInterface
    {
        try {
            $db = Database::connect();
            $db->query('SELECT 1');

            return $this->response
                ->setStatusCode(200)
                ->setJSON([
                    'status' => 'ok',
                    'app' => 'ci4',
                    'checks' => [
                        'database' => 'ok'
                    ]
                ]);
        } catch (\Throwable $e) {
            log_message('error', 'Health check failed: {message}', ['message' => $e->getMessage()]);

            return $this->response
                ->setStatusCode(503)
                ->setJSON([
                    'status' => 'fail',
                    'checks' => [
                        'database' => 'fail'
                    ]
                ]);
        }
    }
}

Daftarkan route misalnya /health. Untuk aplikasi yang memakai queue, cache, atau layanan eksternal, jangan semua dependency dijadikan hard-fail kecuali benar-benar memblokir request utama. Kalau tidak, health check terlalu sensitif dan memicu cutover gagal padahal aplikasi inti masih sehat.

Langkah implementasi blue-green deploy di CodeIgniter 4

1. Build artifact yang konsisten

Jangan melakukan perubahan manual di server produksi. Bangun artifact rilis yang isinya konsisten:

  • Source code aplikasi.
  • Dependency Composer sesuai lock file.
  • Asset hasil build jika ada frontend.
  • File konfigurasi non-rahasia yang memang perlu dibundel.

Prinsip pentingnya: server hanya menerima artifact yang sudah tervalidasi, bukan melakukan eksperimen saat deploy.

2. Deploy ke Green tanpa menerima trafik

Pada tahap ini, Green belum menerima request publik. Lakukan:

  1. Ekstrak artifact.
  2. Pastikan permission direktori writable benar.
  3. Pasang file .env yang sesuai.
  4. Jalankan pemeriksaan dasar aplikasi.

Contoh urutan perintah yang umum:

composer install --no-dev --prefer-dist --optimize-autoloader
php spark migrate --all
php spark cache:clear

Perintah tepatnya bisa berbeda tergantung proses build Anda. Yang penting adalah dependency, migrasi, dan cache diperlakukan konsisten di semua slot.

3. Sinkronisasi environment dengan disiplin

Salah satu penyebab deploy gagal adalah Blue dan Green punya variabel environment berbeda. Minimal lakukan checklist berikut:

  • Database host, port, nama database, user, dan password benar.
  • app.baseURL konsisten dengan domain produksi.
  • Kunci enkripsi, session driver, dan konfigurasi cache sama.
  • Kredensial layanan pihak ketiga tersedia.
  • Flag debug produksi tidak aktif untuk trafik publik.

Hindari menyimpan .env sensitif di repository. Gunakan secret manager, mekanisme inject environment dari CI/CD, atau template terenkripsi. Untuk verifikasi, bandingkan daftar key yang wajib ada, bukan hanya isi file secara mentah.

4. Validasi health check sebelum cutover

Sebelum trafik dipindahkan, panggil endpoint health check di Green beberapa kali. Idealnya tambahkan juga:

  • Request ke halaman atau API penting.
  • Login non-interaktif untuk akun uji jika memungkinkan.
  • Validasi koneksi database dan session.

Kesalahan umum di tahap ini adalah hanya memeriksa status 200 dari root path, padahal endpoint utama gagal karena konfigurasi session, cache, atau route tertentu.

5. Cutover trafik

Setelah Green lulus pemeriksaan, pindahkan trafik dari Blue ke Green. Strategi sederhana:

  • Ganti upstream di load balancer.
  • Reload konfigurasi tanpa restart penuh jika memungkinkan.
  • Pantau metrik selama beberapa menit pertama.

Untuk sistem yang lebih matang, Anda bisa mulai dengan persentase trafik kecil. Namun untuk banyak deployment PHP tradisional, cutover penuh lebih sederhana selama rollback juga cepat.

6. Simpan Blue sebagai kandidat rollback

Jangan langsung menghapus Blue setelah Green aktif. Pertahankan setidaknya sampai:

  • Error rate stabil.
  • Latency normal.
  • Tidak ada masalah migrasi atau background task.

Migrasi database yang aman untuk blue-green

Bagian paling berisiko dalam CodeIgniter 4: Blue-Green Deploy dengan Rollback dan SLO Dasar biasanya bukan pengalihan trafik, melainkan migrasi database. Karena Blue dan Green bisa hidup bersamaan, skema database harus kompatibel dengan keduanya selama masa transisi.

Pola migrasi yang lebih aman

  • Expand-then-contract: tambahkan kolom/struktur baru terlebih dahulu, ubah aplikasi agar bisa membaca format lama dan baru, baru hapus struktur lama di rilis berikutnya.
  • Nullable dulu: saat menambah kolom baru, hindari langsung membuatnya wajib bila data lama belum terisi.
  • Backfill terpisah: untuk data besar, isi data lama lewat job terpisah, bukan dalam request web.
  • Feature flag: aktifkan penggunaan skema baru setelah Green stabil.

Contoh perubahan yang berbahaya saat deploy

  • Mengganti nama kolom yang masih dipakai Blue.
  • Menghapus tabel atau indeks yang masih diakses aplikasi lama.
  • Mengubah tipe data dengan cara yang memutus kompatibilitas query.

Urutan aman yang umum:

  1. Tambahkan kolom baru yang kompatibel.
  2. Deploy aplikasi yang bisa membaca/menulis keduanya bila perlu.
  3. Backfill data lama.
  4. Setelah semua trafik stabil di Green, hapus ketergantungan ke struktur lama di rilis berikutnya.

Prinsip praktis: rollback aplikasi harus bisa dilakukan tanpa perlu rollback skema secara darurat. Jika migrasi Anda memaksa rollback database, maka manfaat blue-green berkurang drastis.

Rollback cepat saat error rate naik

Rollback pada blue-green seharusnya sederhana: kembalikan trafik ke slot sebelumnya. Namun keputusan rollback perlu berbasis indikator yang jelas, bukan perasaan.

Trigger rollback yang masuk akal

  • Error rate HTTP 5xx naik signifikan dibanding baseline.
  • Endpoint login, checkout, atau API utama gagal.
  • Latency melonjak dan menyebabkan timeout.
  • Health check Green gagal berulang.

Alur rollback operasional

  1. Deteksi anomali dari alert atau dashboard.
  2. Konfirmasi cepat di log dan health endpoint.
  3. Alihkan trafik dari Green ke Blue.
  4. Verifikasi Blue kembali sehat.
  5. Bekukan deploy lanjutan sampai akar masalah jelas.

Yang sering terlupa: setelah rollback, jangan langsung men-deploy ulang dengan asumsi masalah sementara. Kumpulkan bukti dari log, metrik, dan perubahan terakhir agar penyebab tidak berulang.

Observability dasar: log, metrik, dan alert

Tanpa observability minimum, Anda tidak akan tahu kapan harus cutover, kapan harus rollback, dan apa yang sebenarnya rusak. Untuk web app PHP, mulai dari yang sederhana tetapi berguna.

1. Log terstruktur

Format log sebaiknya konsisten dan mudah dicari. Jika belum punya pipeline JSON penuh, setidaknya pastikan setiap log penting memuat:

  • Timestamp
  • Level log
  • Environment/slot deployment
  • Request ID atau correlation ID
  • Path, method, status code
  • Pesan error yang ringkas

Contoh log aplikasi yang lebih informatif:

log_message('error', 'payment callback failed', [
    'request_id' => service('request')->getHeaderLine('X-Request-ID'),
    'slot' => getenv('DEPLOY_SLOT') ?: 'unknown',
    'path' => service('request')->getPath(),
    'message' => $e->getMessage()
]);

Jika Anda memakai reverse proxy, dorong header X-Request-ID agar tracing antar komponen lebih mudah.

2. Metrik inti yang perlu dipantau

Anda tidak perlu sistem observability yang kompleks di awal. Untuk deploy yang aman, minimal pantau:

  • Request rate: apakah trafik benar-benar sudah berpindah?
  • Error rate: persentase respons 5xx atau request gagal.
  • Latency: median dan tail latency seperti p95 jika tersedia.
  • Health check status: jumlah gagal per interval.
  • Resource dasar: CPU, memori, dan koneksi PHP-FPM/web server.

Jika endpoint bisnis kritikal terbatas, buat metrik per endpoint penting seperti /login, /checkout, atau API publik utama.

3. SLI dan SLO dasar yang relevan

Untuk aplikasi web PHP, indikator Service Level Indicator yang realistis:

  • Availability SLI: persentase request sukses non-5xx untuk endpoint utama.
  • Latency SLI: persentase request yang selesai di bawah ambang tertentu.
  • Correctness SLI sederhana: persentase health check sukses atau persentase login berhasil untuk request valid.

Contoh Service Level Objective dasar yang bisa dipakai tim kecil:

  • Dalam 30 hari, endpoint web utama memiliki tingkat sukses minimal 99.9%.
  • Dalam 30 hari, 95% request halaman utama selesai di bawah ambang latensi internal yang sudah disepakati tim.
  • Selama 15 menit setelah deploy, error rate tidak boleh melebihi ambang rollback yang ditentukan.

Hindari memilih SLO yang terlalu ambisius tanpa data baseline. SLO berguna untuk keputusan operasional, bukan sekadar angka bagus di dokumen.

4. Alert sederhana yang benar-benar berguna

Mulai dari beberapa alert berikut:

  • Error rate 5xx naik di atas ambang selama beberapa menit.
  • Health check Green gagal berturut-turut setelah cutover.
  • Latency endpoint kritikal naik tajam setelah deploy.
  • Lonjakan exception tertentu pada release baru.

Alert harus cukup sensitif untuk menangkap masalah, tetapi tidak terlalu bising. Terlalu banyak false positive membuat tim justru mengabaikan alert saat insiden nyata terjadi.

Checklist deploy CodeIgniter 4 dengan blue-green

Sebelum deploy

  • Artifact rilis sudah dibangun dari commit yang jelas.
  • Dependency terkunci dan lulus pengujian dasar.
  • Blue dan Green memakai versi runtime yang sama.
  • Variabel environment wajib tersedia di Green.
  • Migrasi database ditinjau untuk kompatibilitas dua versi.
  • Health check endpoint sudah diuji.
  • Dashboard dan alert untuk pasca-deploy siap dipantau.

Saat deploy

  • Deploy ke Green tanpa trafik publik.
  • Jalankan migrasi yang aman.
  • Validasi health check dan endpoint penting.
  • Pastikan session, cache, dan koneksi database normal.
  • Cutover trafik ke Green.
  • Pantau error rate, latency, dan log selama beberapa menit pertama.

Setelah deploy

  • Blue tetap dipertahankan sementara.
  • Konfirmasi endpoint bisnis utama berjalan.
  • Tinjau log exception baru.
  • Tutup rilis hanya setelah metrik stabil.

Saat rollback

  • Alihkan trafik kembali ke Blue.
  • Verifikasi Blue sehat.
  • Dokumentasikan gejala, waktu, dan perubahan terakhir.
  • Tunda migrasi destruktif lanjutan sampai akar masalah selesai.

Studi kasus insiden ringan setelah deploy gagal

Ringkasan kejadian

Setelah cutover dari Blue ke Green, error rate naik pada endpoint login. Health check tetap lolos karena hanya memeriksa database. Dalam beberapa menit, tim menerima alert error 5xx yang meningkat pada jalur autentikasi.

Dampak

  • Pengguna baru tidak bisa login.
  • Halaman umum tetap bisa diakses.
  • Durasi gangguan singkat karena rollback cepat tersedia.

Kronologi singkat

  1. Green lulus health check dasar.
  2. Traffic dipindahkan ke Green.
  3. Error 500 naik di endpoint login.
  4. Tim memeriksa log dan menemukan kegagalan session driver karena konfigurasi environment tidak sinkron.
  5. Rollback ke Blue dilakukan.

Root cause

Variabel environment untuk session handler pada Green berbeda dari Blue. Aplikasi tetap hidup dan bisa menjawab request umum, tetapi proses login gagal karena dependency session tidak benar-benar tervalidasi dalam health check.

Mitigasi saat insiden

  • Rollback trafik ke Blue.
  • Nonaktifkan akses publik ke Green sementara.
  • Bandingkan environment Blue vs Green untuk key kritikal.
  • Tambahkan validasi login sintetis pada pipeline verifikasi.

Pencegahan untuk rilis berikutnya

  • Buat daftar variabel environment wajib dan pemeriksaan otomatis sebelum cutover.
  • Perluas health check atau tambahkan readiness test untuk fitur kritikal seperti login.
  • Tambahkan alert khusus untuk lonjakan error endpoint autentikasi.
  • Dokumentasikan proses rollback dan siapa yang berwenang mengeksekusi.

Format postmortem ringkas yang bisa dipakai

Judul insiden: Login gagal setelah cutover Green
Tanggal/Waktu: 2026-xx-xx 10:15-10:24
Durasi: 9 menit
Dampak: Sebagian pengguna tidak dapat login
Deteksi: Alert error rate 5xx endpoint /login
Root cause: Environment session di Green tidak sinkron
Kontributor: Health check terlalu dangkal, checklist env belum otomatis
Mitigasi: Rollback ke Blue, perbaiki env Green
Tindakan pencegahan:
- Tambah validasi session/login sebelum cutover
- Tambah diff otomatis untuk env wajib
- Tambah alert endpoint autentikasi
Owner: Tim aplikasi + tim platform
Status: Selesai / dipantau

Postmortem tidak perlu panjang, tetapi harus cukup jelas untuk mencegah pengulangan. Fokus pada perbaikan sistem, bukan mencari siapa yang salah.

Trade-off dan batasan pendekatan ini

  • Biaya infrastruktur lebih tinggi karena Anda memelihara dua environment aktif.
  • Migrasi database lebih menantang karena harus kompatibel lintas versi.
  • Stateful component seperti session, file upload sementara, atau job queue perlu perhatian ekstra.
  • Proses operasional harus disiplin; tanpa checklist dan observability, blue-green bisa gagal seperti deploy biasa.

Namun bila dibandingkan deploy langsung di tempat yang sama, blue-green memberi keuntungan besar pada kecepatan rollback dan pengurangan risiko downtime aplikasi.

Penutup

Untuk blue-green deploy pada CodeIgniter 4, kunci keberhasilan bukan hanya menyiapkan dua server, tetapi memastikan cutover dapat divalidasi dan dibatalkan dengan cepat. Mulailah dari setup sederhana: dua slot yang identik, endpoint health check yang relevan, migrasi database kompatibel, sinkronisasi environment yang ketat, serta observability dasar yang cukup untuk mendeteksi anomali.

Jika Anda baru menerapkannya, jangan langsung mengejar otomasi penuh. Pastikan dulu proses manual Anda aman, terdokumentasi, dan bisa diulang. Setelah itu, otomasi checklist, verifikasi, dan rollback agar rilis CodeIgniter 4 makin stabil dari waktu ke waktu.