# Deploy and Release

Ini konsep yang sering bikin bingung karena orang kadang nyampurin **deploy** sama **release**. Padahal, di praktik modern DevOps, keduanya harus *dipisah* supaya proses lebih aman, fleksibel, dan minim risiko. Yuk kita bedah lengkap:

***

### 📌 1. Bedanya Deploy & Release

* **Deploy** = proses **meletakkan kode baru** (binary, container image, service, dll) ke environment (staging/prod).\
  👉 Deployment *tidak otomatis* berarti user bisa pakai fitur baru.
* **Release** = proses **mengaktifkan fitur** yang sudah ada di environment untuk user.\
  👉 Bisa dilakukan setelah deploy, tanpa redeploy.

Contoh:

* Kita sudah deploy kode fitur "Dark Mode" ke production minggu lalu.
* Tapi fitur itu belum kelihatan karena masih ditutup dengan **feature flag**.
* Hari ini, kita "release" dengan menyalakan flag untuk 10% user dulu.

***

### 📌 2. Kenapa Harus Dipisah?

1. **Mengurangi risiko** – kode bisa aman di-deploy tanpa langsung dipakai user.
2. **Cepat rollback** – kalau ada masalah, tinggal matiin flag release tanpa rollback deployment.
3. **Eksperimen & gradual rollout** – bisa nyalain fitur untuk sebagian user (canary, A/B testing).
4. **Lebih fleksibel** – tim DevOps fokus di deploy, tim Product/Business bisa atur release.

***

### 📌 3. Cara Memisahkan Deploy & Release

Ada beberapa teknik best practice:

#### a. **Feature Flags (Feature Toggles)**

* Kode fitur baru dibungkus flag:

  ```go
  if featureFlag.IsEnabled("dark_mode") {
      renderDarkModeUI()
  } else {
      renderDefaultUI()
  }
  ```
* Deploy boleh kapan saja, tapi release tinggal toggle di config (misalnya via LaunchDarkly, Unleash, atau internal service).

#### b. **Blue-Green Deployment**

* Dua environment: **Blue (aktif)** & **Green (idle)**.
* Deploy ke Green → test → switch traffic ke Green (ini bagian release).

#### c. **Canary Release**

* Deploy versi baru ke sebagian kecil server / user.
* Release bertahap → kalau stabil, perbesar persentase → akhirnya 100%.

#### d. **Progressive Delivery**

* Kombinasi canary + feature flags + observability.
* Misalnya: fitur cuma aktif di region tertentu, device tertentu, atau user beta tester.

***

### 📌 4. Workflow Ideal (Contoh)

1. **CI/CD Pipeline**:
   * Build & test kode.
   * Deploy otomatis ke production (tapi fitur default *off*).
2. **Release Control**:
   * Product Manager atur fitur via dashboard flag.
   * Misalnya: aktifkan untuk 5% user.
3. **Monitoring & Observability**:
   * Pantau metrics (error rate, latency, conversion).
   * Kalau ada anomali → rollback release (matikan flag), deployment tetap aman.

***

### 📌 5. Tools Pendukung

* **Feature Flag**: LaunchDarkly, Unleash, Flipt, atau buatan sendiri.
* **Deployment**: ArgoCD, Spinnaker, GitOps, Helm, Kubernetes.
* **Release Strategy**: Argo Rollouts (canary/blue-green), Flagger.

***

### 📌 6. Analogi Sederhana

* **Deploy** = naro barang baru di gudang.
* **Release** = ngebuka pintu gudang & mulai jualan barang ke pelanggan.\
  Kalau barang jelek? Tinggal tutup pintu (matikan release), nggak perlu mindahin barang lagi (rollback deployment).

***

👉 Jadi best practice modern:

* **Deploy sering, otomatis, aman** → Continuous Deployment.
* **Release terkontrol, bertahap, fleksibel** → Feature Flags + Progressive Delivery.
