Dari Commit ke Rilis Penuh: Membangun Pipeline Progressive Delivery

Anda menggabungkan kode ke branch utama. Pipeline CI berubah hijau. Artefak sudah siap. Lalu bagaimana?

Di sebagian besar tim, langkah selanjutnya sederhana: deploy ke production. Tapi jika Anda pernah menyaksikan deployment yang salah - bug yang baru muncul di bawah traffic nyata, regresi performa yang diam-diam merayap masuk, fitur yang membingungkan pengguna - Anda tahu bahwa "deploy ke semua pengguna sekaligus" adalah pertaruhan yang tidak perlu Anda ambil.

Progressive delivery mengubah hal itu. Alih-alih satu saklar besar, Anda meluncurkan perubahan secara bertahap, menggunakan traffic routing, feature flags, dan monitoring otomatis untuk memutuskan di setiap langkah apakah akan melanjutkan atau mundur. Artikel ini memandu cara merangkai pipeline progressive delivery yang lengkap, dari saat kode digabungkan hingga fitur sepenuhnya aktif dan stabil.

Diagram alir berikut menunjukkan tahapan pipeline secara sekilas:

flowchart TD A[Commit / Merge] --> B[Build & Tests] B --> C[Canary Ring<br>1% traffic] C --> D{Monitor Metrics} D -- Pass --> E[Staged Rollout<br>10% → 25% → 50%] D -- Fail --> F[Auto Rollback] E --> G{Monitor & Gate} G -- Pass --> H[Full Rollout<br>100%] G -- Fail --> F H --> I[Flag Cleanup] F --> J[Notify Team]

Build dan Pengujian Dasar

Pipeline dimulai seperti biasa. Ketika developer menggabungkan kode ke branch utama, pipeline menjalankan unit test, integration test, dan security scan. Ini adalah pemeriksaan yang sama yang sudah Anda miliki - belum ada yang istimewa.

Jika semuanya lolos, pipeline menghasilkan artefak yang bisa di-deploy. Di sinilah progressive delivery mulai berbeda dari pipeline standar. Artefak tidak langsung dikirim ke semua pengguna. Artefak masuk ke ring deployment pertama, yang biasanya disebut canary ring.

Canary Ring: Uji Nyata Pertama Anda

Canary ring menerima sebagian kecil traffic - misalnya, satu persen dari seluruh permintaan. Pipeline men-deploy versi baru ke server yang melayani ring ini. Kemudian pipeline mengaktifkan feature flags yang relevan untuk pengguna yang masuk ke ring tersebut.

Berikut contoh GitLab CI yang mendefinisikan canary ring dan langkah-langkah staged rollout:

stages:
  - canary
  - staged-rollout
  - full-rollout

canary-deploy:
  stage: canary
  script:
    - kubectl set image deployment/my-app canary=my-app:$CI_COMMIT_SHA
    - kubectl scale deployment/my-app --replicas=1
  environment:
    name: production/canary
    url: https://canary.example.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

auto-promote:
  stage: staged-rollout
  script:
    - sleep 600  # jendela monitoring 10 menit
    - ./check-metrics.sh  # verifikasi error rate, latency dalam SLO
    - kubectl set image deployment/my-app-10pct my-app=my-app:$CI_COMMIT_SHA
    - kubectl scale deployment/my-app-10pct --replicas=2
  needs: ["canary-deploy"]
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

rollout-50pct:
  stage: staged-rollout
  script:
    - ./check-metrics.sh
    - kubectl set image deployment/my-app-50pct my-app=my-app:$CI_COMMIT_SHA
  needs: ["auto-promote"]
  when: manual  # memerlukan persetujuan manual

rollout-100pct:
  stage: full-rollout
  script:
    - ./check-metrics.sh
    - kubectl set image deployment/my-app my-app=$CI_COMMIT_SHA
  needs: ["rollout-50pct"]
  when: manual

Feature flags menambahkan lapisan kontrol ekstra di sini. Meskipun versi baru sudah berjalan, fitur tertentu dapat diaktifkan hanya untuk pengguna tertentu di dalam canary ring. Ini memungkinkan Anda menguji tidak hanya stabilitas versi baru, tetapi juga perilaku fitur tertentu pada pengguna nyata, tanpa mengekspos semua orang ke fitur tersebut.

Selama versi baru berjalan di canary ring, observability mulai bekerja. Pipeline memonitor error rate, latency, dan metrik lain yang ditentukan dalam Service Level Objectives (SLO) Anda. Jika semua metrik tetap dalam batas yang dapat diterima untuk periode tertentu - misalnya, sepuluh menit - pipeline secara otomatis melanjutkan ke tahap berikutnya. Jika ada metrik yang melanggar ambang batas, pipeline memicu rollback otomatis: traffic kembali ke versi lama, feature flags dimatikan, dan tim mendapat notifikasi.

Staged Rollout: Memperluas Audiens

Tahap berikutnya adalah ring yang lebih luas, mungkin melayani sepuluh persen pengguna. Prosesnya berulang: deploy, aktifkan flags, monitor, putuskan. Tapi sekarang Anda memiliki lebih banyak ruang untuk bereksperimen dengan feature flags. Misalnya, Anda dapat mengaktifkan fitur baru hanya untuk pengguna yang terdaftar sebagai beta tester. Ini memberi Anda data nyata dari pengguna nyata tanpa memengaruhi semua orang.

Pipeline terus memperluas audiens langkah demi langkah: dari sepuluh persen menjadi dua puluh lima persen, lalu ke lima puluh persen, dan akhirnya ke seratus persen. Setiap kali pipeline pindah ke ring berikutnya, pipeline melewati promotion gate. Gate ini bisa berupa pemeriksaan otomatis berdasarkan metrik, atau bisa menunggu persetujuan manual dari tim. Banyak tim menggunakan kombinasi: gate otomatis untuk keputusan cepat, dan persetujuan manual untuk tahap kritis, seperti sebelum masuk ke seratus persen pengguna.

Membersihkan Feature Flags

Setelah versi baru melayani semua pengguna, pipeline belum selesai. Feature flags yang sekarang aktif untuk semua orang perlu dibersihkan. Pipeline dapat menjalankan tugas yang memeriksa apakah suatu flag masih digunakan, lalu membuat pull request untuk menghapus kode flag dari repositori. Ini mencegah codebase Anda menumpuk flag mati yang tidak diingat siapa pun.

Apa yang Membuat Pipeline Ini Berbeda

Pipeline progressive delivery bukan sekadar urutan deployment. Ini adalah sistem yang menggabungkan traffic management, feature control, monitoring otomatis, dan keputusan berbasis data ke dalam satu alur yang berjalan dari commit hingga full rollout. Setiap tahap adalah lapisan keamanan yang memastikan perubahan tidak tiba-tiba merusak pengalaman pengguna.

Perbedaan utama dari pipeline tradisional adalah Anda tidak bertanya "apakah build lolos?" Anda bertanya "apakah perubahan ini aman untuk diekspos ke lebih banyak pengguna?" Pertanyaan itu tidak bisa dijawab oleh unit test saja. Ini membutuhkan traffic nyata, pengguna nyata, dan metrik nyata.

Checklist Praktis untuk Pipeline Anda

Jika Anda membangun pipeline progressive delivery, berikut komponen yang perlu diverifikasi di setiap tahap:

  • Canary ring: Apakah menerima sebagian kecil traffic yang terukur? Bisakah Anda merutekan pengguna secara konsisten sehingga pengguna yang sama tetap berada di ring yang sama?
  • Feature flags: Apakah flags dibatasi untuk pengguna atau grup tertentu? Bisakah Anda mengaktifkan/menonaktifkannya secara independen dari deployment?
  • Observability: Apakah error rate, latency, dan metrik bisnis dimonitor? Apakah ambang batas didasarkan pada SLO Anda, bukan tebakan sembarangan?
  • Promotion gates: Apakah setiap ring memiliki kondisi yang jelas untuk melanjutkan? Apakah ada langkah persetujuan manual untuk ekspansi kritis?
  • Rollback: Apakah rollback otomatis ketika metrik melanggar ambang batas? Apakah mencakup traffic routing dan penonaktifan flag?
  • Flag cleanup: Apakah ada proses untuk menghapus flags setelah full rollout? Apakah pipeline membuat pull request atau memberi notifikasi ke tim?

Kesimpulan

Pipeline progressive delivery mengubah deployment dari peristiwa biner menjadi proses bertahap. Anda tidak merilis perubahan dan berharap yang terbaik. Anda merilisnya ke grup kecil, mengamati apa yang terjadi, dan memutuskan apakah akan melanjutkan. Jika ada yang salah, hanya sebagian kecil pengguna yang terpengaruh, dan sistem pulih secara otomatis.

Pipeline ini bukan tentang menambah kompleksitas. Ini tentang menambah kontrol. Setiap ring, setiap gate, setiap pemeriksaan metrik adalah kesempatan untuk menangkap masalah sebelum menjadi insiden. Bangun pipeline Anda dengan pemikiran itu, dan Anda akan tidur lebih nyenyak setelah setiap merge.