Belajar DevOps Engineer - Continuous Delivery & Deployment (CD)

#Pendahuluan

Di episode 5 kita membangun CI yang menghasilkan artifact — bukti bahwa kode bisa dibangun dan lolos uji. Tapi artifact yang tersimpan di registry tidak ada gunanya jika tidak pernah sampai ke pengguna. Di episode inilah Continuous Delivery & Deployment (CD) bekerja: meneruskan artifact ke berbagai environment dan menempatkannya ke produksi dengan cara yang aman.

Penting untuk membedakan dua istilah yang sering tertukar:

• Continuous Delivery — setiap artifact yang lolos CI selalu siap rilis ke produksi; rilisnya sendiri bisa menunggu keputusan manusia.
• Continuous Deployment — setiap artifact yang lolos otomatis langsung dirilis ke produksi tanpa persetujuan manual.

Perbedaannya hanya satu approval gate. Keduanya berbagi fondasi yang sama: otomasi penuh dari kode hingga ke gerbang produksi.

#Environment: Dev, Staging, dan Production

CD bekerja di atas rantai environment. Setiap environment meniru produksi dengan tingkat kemiripan dan risiko yang berbeda:

Prinsip yang harus dipegang: apa pun yang jalan di staging harus persis sama yang jalan di produksi — artifact yang sama, konfigurasi yang sama (kecuali secret). Kalau tidak, kalian sedang menguji hal yang berbeda dari yang dirilis.

#Strategi Deployment: Meminimalkan Risiko

Cara menempatkan versi baru ke produksi menentukan risiko dan waktu rollback. Tiga strategi dominan:

#Rolling Update

Versi baru menggantikan yang lama bertahap — instance per instance. Klasik di Docker Swarm dan (secara default) Kubernetes Deployment. Kelebihan: tidak butuh resource ekstra. Kekurangan: selama transisi, dua versi berjalan bersamaan, dan rollback harus "menggulung balik".

Replica 1-5: v1.0 → v2.0 bertahap satu per satu

#Blue-Green

Dua environment lengkap: blue (versi lama) dan green (versi baru). Green diuji penuh dulu, lalu traffic dialihkan seketika. Rollback hanya memindahkan traffic kembali ke blue. Kelebihan: rollback instan. Kekurangan: butuh resource hampir dua kali lipat.

Traffic 100% → Blue (v1.0)
Uji Green (v2.0) → Valid
Traffic 100% → Green (v2.0)   # switch instan

#Canary

Versi baru dirilis ke sebagian kecil pengguna dulu (misal 5%), dipantau metriknya, lalu dinaikkan bertahap ke 100%. Kelebihan: deteksi masalah dengan dampak minimal. Kekurangan: perlu observability (episode 11) dan kontrol traffic yang canggih (nanti di service mesh, episode 19).

Traffic 5% → Canary (v2.0), 95% → Stable (v1.0)
Metrik sehat → naik ke 50%, lalu 100%

#Approval Gate: Titik Manusia dalam Otomasi

Continuous Deployment tidak berarti menghapus manusia — berarti menghapus pekerjaan manual yang berulang. Approval gate adalah tempat keputusan manusia yang memang harus dibuat manusia, misalnya:

• Persetujuan release ke produksi untuk aplikasi bisnis kritis.
• Konfirmasi sebelum failover data atau migrasi database.
• Approval finansial untuk resource cloud yang mahal.

Di GitHub Actions, gate dibuat dengan environment protection rule:

name: CD
on:
  workflow_run:
    workflows: [CI]
    types: [completed]
 
jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - name: Deploy ke produksi
        run: ./deploy.sh

Environment production di pengaturan repository bisa dikonfigurasi dengan required reviewers — deployment akan menunggu persetujuan manusia sebelum berjalan.

#Praktik: Pipeline CD End-to-End

Gambaran lengkap yang akan kita bangun (dalam bentuk nyata di episode 17, 18, dan 21):

Alurnya: setiap commit → CI hijau → artifact dipublish → otomatis ke dev dan staging → menunggu approval → canary ke produksi → dipantau. Jika metrik memburuk, sistem otomatis mengembalikan ke versi sebelumnya.

Kunci dari seluruh alur ini adalah artifact yang immutable (episode 17): versi yang diuji di staging adalah persis versi yang dirilis ke produksi. Jangan pernah build ulang di tengah perjalanan.

#Pitfall Umum

• Dev dan prod tidak identik — perbedaan lingkungan adalah sumber bug "hanya di produksi".
• Deploy tanpa observability — kalian tidak tahu apakah rilis berhasil sebelum pengguna melaporkan.
• Tanpa rollback plan — setiap strategi deployment wajib punya jalur kembali yang teruji.
• Menjadikan manusia sebagai "deploy button" — jika persetujuannya untuk hal yang bisa diotomasi, berarti CD kalian belum tuntas.

#Penutup

Inti yang harus dibawa pulang:

• Continuous Delivery = selalu siap rilis; Continuous Deployment = otomatis rilis penuh.
• Rantai environment dev → staging → prod menjamin verifikasi bertahap.
• Pilih strategi sesuai kebutuhan: rolling (hemat), blue-green (rollback instan), canary (risiko minimal).
• Approval gate adalah titik keputusan manusia yang disengaja, bukan pekerjaan manual.

Di episode 7 selanjutnya kita membahas Docker & containerization — teknologi yang membuat environment konsisten dan deployment portabel. Semua strategi deployment di atas menjadi praktis berkat container yang menjalankan aplikasi dengan cara yang sama di mana pun.