Progressive Delivery 2026: Deploy Aman di Kubernetes dengan Argo Rollouts (Canary & Blue-Green)

Setiap rilis perangkat lunak membawa risiko. Di era layanan mikro dan Kubernetes, menekan tombol deploy bukan lagi akhir dari cerita, melainkan awal dari pertaruhan: apakah versi baru benar-benar stabil di produksi? Tahun 2026 menandai pergeseran besar dalam budaya DevOps di Indonesia, dari sekadar CI/CD berjalan menuju progressive delivery yaitu cara meluncurkan fitur secara bertahap, terukur, dan bisa dibatalkan dalam hitungan detik. Artikel ini membahas mengapa progressive delivery menjadi standar tim platform Indonesia dan cara menerapkannya dengan Argo Rollouts di atas Kubernetes. Mengacu pada metrik DORA, tim yang menerapkan rilis bertahap cenderung mencatat lead time perubahan lebih pendek tanpa mengorbankan stabilitas layanan.

Mengapa Tim DevOps 2026 Beralih ke Progressive Delivery

Praktik deploy tradisional bergantung pada strategi all-or-nothing: Recreate, RollingUpdate, atau sekadar mengganti image container sekaligus. Masalahnya, ketika bug menyelinap ke versi baru, seluruh pengguna merasakan dampaknya. Progressive delivery memecah rilis menjadi langkah-langkah kecil yang setiap langkahnya diiringi pengamatan metrik.

Tiga kekuatan utama mendorong adopsi ini pada 2026:

• Keamanan rilis: hanya sebagian kecil trafik yang diarahkan ke versi baru, sehingga dampak bug terbatas.
• Putusan berbasis data: metrik error rate dan latensi menjadi trigger otomatis untuk promosi atau rollback.
• Kecepatan tanpa ketakutan: tim dapat deploy berkali-kali sehari karena tombol abort selalu tersedia.

Progressive delivery bukan sekadar alat, melainkan kontrak antara tim pengembang dan operasi: setiap perubahan harus bisa dibuktikan aman sebelum mencapai 100 persen pengguna.

Mengubah Deployment Menjadi Rollout

Argo Rollouts adalah proyek Cloud Native Computing Foundation (CNCF) yang memperluas Kubernetes dengan jenis objek Rollout. Berbeda dengan Deployment standar, Rollout memahami langkah-langkah rilis bertahap dan terintegrasi erat dengan alat analitik. Instalasi cukup melalui manifest resmi:

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts \
  -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
kubectl apply -n argo-rollouts \
  -f https://github.com/argoproj/argo-rollouts/releases/latest/download/analysis-install.yaml
# pasang plugin cli
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

Setelah terpasang, ubah manifest kind: Deployment menjadi kind: Rollout. Seluruh konfigurasi selector dan template tetap sama; yang berubah hanyalah definisi strategy.

Strategi Canary: Mengalirkan Trafik secara Bertahap

Canary adalah tulang punggung progressive delivery. Kita membagi rilis menjadi bobot trafik: 20 persen, lalu 50 persen, lalu 100 persen, dengan jeda pengamatan di antaranya. Berikut contoh Rollout untuk layanan pembayaran:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-pembayaran
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: { duration: 5m }
      - setWeight: 50
      - pause: { duration: 5m }
      - setWeight: 100
      revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: api-pembayaran
  template:
    metadata:
      labels:
        app: api-pembayaran
    spec:
      containers:
      - name: api
        image: registry.internal/api-pembayaran:1.4.0
        ports:
        - containerPort: 8080

Dengan konfigurasi di atas, Argo Rollouts akan meluncurkan 20 persen pod versi baru, menunggu lima menit, lalu naik ke 50 persen, dan akhirnya 100 persen. Jika sesuatu tidak beres, perintah berikut menghentikan rilis dan mengembalikan ke versi stabil:

kubectl argo rollouts abort api-pembayaran
kubectl argo rollouts undo api-pembayaran

Analisis Otomatis dengan Prometheus

Jeda pause di atas masih membutuhkan mata manusia. Tahap dewasa sebuah pipeline adalah membiarkan metrik memutuskan. Kita definisikan AnalysisTemplate yang mengekstrak error rate dari Prometheus, lalu menyisipkannya sebagai gerbang otomatis:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: cek-latensi
spec:
  metrics:
  - name: error-rate
    interval: 1m
    successCondition: result < 0.01
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc:9090
        query: |
          sum(rate(http_requests_total{status=~"5..",app="api-pembayaran"}[1m]))
          /
          sum(rate(http_requests_total{app="api-pembayaran"}[1m]))

Analisis ini lantas dirangkai ke dalam Rollout melalui analysis di dalam steps. Bila error rate melewati 1 persen, Rollout gagal secara otomatis dan trafik dikembalikan ke replika lama, tanpa campur tangan on-call engineer di tengah malam.

Blue-Green untuk Pembaruan Nol-Waktu-Henti

Saat aplikasi menuntut pembaruan tanpa jeda sama sekali, strategi blue-green lebih tepat. Dua lingkungan berjalan berdampingan: active melayani produksi, preview menampung versi baru yang diverifikasi dulu sebelum dipromosikan:

spec:
  strategy:
    blueGreen:
      activeService: api-pembayaran-active
      previewService: api-pembayaran-preview
      autoPromotionEnabled: false
      prePromotionAnalysis:
        templates:
        - templateName: cek-latensi

Tim memvalidasi preview lewat uji end-to-end, lalu menjalankan kubectl argo rollouts promote api-pembayaran. Peralihan terjadi instan di level Service, sehingga pengguna tidak merasakan downtime.

Merutekan Trafik Canary dengan Service Mesh

Canary pada contoh sebelumnya bekerja di level replika pod, yang cukup untuk pembaruan tanpa kebutuhan rute trafik presisi. Namun untuk pembagian persentase pengguna secara akurat, tim sering menyandingkan Argo Rollouts dengan pengontrol ingress atau service mesh seperti Istio, NGINX Ingress, atau AWS Load Balancer Controller. Dengan mendefinisikan trafficRouting, Rollout mengatur aturan rute sehingga 20 persen pengguna sungguhan dialihkan ke versi baru sementara sisanya tetap di versi lama:

strategy:
  canary:
    trafficRouting:
      istio:
        virtualService:
          name: api-pembayaran
          routes:
          - primary
    steps:
    - setWeight: 20
    - pause: { duration: 5m }
    - setWeight: 100

Pendekatan ini menutup celah antara persentase pod dan persentase pengguna, sehingga metrik analisis benar-benar mencerminkan pengalaman produksi.

Menghubungkan Progressive Delivery dengan GitOps

Progressive delivery mencapai potensi penuh bila digabung dengan GitOps. Alat seperti Argo CD menjaga klaster tetap selaras dengan repositori Git, sementara Argo Rollouts mengatur cara versi baru diperkenalkan. Kombinasi keduanya menciptakan jejak audit lengkap: siapa yang mengubah manifest, kapan, dan bagaimana trafik bereaksi. Bagi organisasi yang tunduk pada regulasi seperti UU Pelindungan Data Pribadi, kemampuan melacak setiap rilis ke satu commit Git adalah nilai tambah tersendiri yang sulit ditawar.

Praktik Terbaik untuk Tim di Indonesia

Menutup tulisan, berikut beberapa catatan agar adopsi progressive delivery di organisasi Anda berkelanjutan:

• Mulai dari satu layanan kritis, bukan seluruh monolit sekaligus.
• Siapkan metrik yang jujur. Tanpa Prometheus atau OpenTelemetry yang valid, analisis otomatis hanyalah ilusi.
• Dokumentasikan runbook abort. Alat cepat tidak berguna bila budaya tim masih takut menekan tombol.
• Gabungkan dengan GitOps. Jagalah definisi Rollout tetap di repositori Git agar setiap perubahan bisa diaudit.

Pada 2026, keunggulan kompetitif sebuah tim teknologi Indonesia tidak lagi diukur dari seberapa sering deploy, melainkan seberapa aman setiap deploy itu. Progressive delivery dengan Argo Rollouts memberi kerangka kerja yang menjembatani kecepatan dan keandalan, dua sisi yang selama ini dianggap bertentangan.