Deployment vs Release: Kapan Pengguna Benar-Benar Mendapatkan Versi Baru Anda

Tim Anda baru saja selesai melakukan deployment versi 1.2.0 ke production. Artifact sudah ada di server, aplikasi berjalan, dan semua health check menunjukkan hijau. Apakah itu berarti semua pengguna Anda sekarang menggunakan fitur baru? Mungkin tidak.

Mungkin tim Anda sengaja menyembunyikan fitur tertentu sambil memantau stabilitas. Mungkin deployment dilakukan ke server baru yang belum terhubung dengan pengguna. Kesenjangan antara "kode sudah berjalan" dan "pengguna bisa menggunakannya" lebih lebar dari yang disadari kebanyakan tim.

Perbedaan Antara Deployment dan Release

Deployment adalah tindakan teknis. Anda menempatkan artifact di suatu environment dan membuatnya berjalan. Server menerima binary baru, migrasi database selesai, aplikasi mulai merespons permintaan. Dari perspektif infrastruktur, tugas selesai.

Diagram alir berikut mengilustrasikan bagaimana deployment dan release berbeda:

flowchart TD A[Code Commit] --> B[Build & Test] B --> C[Deploy to Production] C --> D{Release Strategy?} D -->|Feature Flags| E[Feature Flag Off] D -->|Canary| F[Route 5% Traffic] D -->|Blue-Green| G[Deploy to Inactive Env] E --> H[Enable Flag for Users] F --> I[Monitor & Increase %] G --> J[Switch Traffic] H --> K[Users Access Feature] I --> K J --> K style C fill:#4a90d9,color:#fff style K fill:#27ae60,color:#fff

Release adalah keputusan bisnis. Ini adalah momen ketika sebuah fitur atau perbaikan benar-benar dapat diakses oleh pengguna. Deployment bisa terjadi tanpa release, tetapi release tidak bisa terjadi tanpa deployment.

Perbedaan ini penting karena mengubah cara Anda memandang risiko. Ketika deployment dan release adalah hal yang sama, setiap deployment membawa beban penuh dampak terhadap pengguna. Ketika Anda memisahkannya, Anda mendapatkan ruang untuk bermanuver.

Feature Flags: Pemisahan Paling Sederhana

Feature flags adalah cara paling umum untuk memisahkan deployment dari release. Anda menambahkan kode yang dapat mengaktifkan atau menonaktifkan fitur tanpa melakukan deployment ulang. Versi baru masuk ke production berisi beberapa fitur, tetapi hanya satu yang aktif untuk sekelompok kecil pengguna.

Berikut contoh sederhana konfigurasi feature flag dalam file YAML:

# config/feature-flags.yaml
features:
  new-checkout:
    enabled: false
    description: "Alur checkout baru dengan pembayaran satu halaman"
    rollout_percentage: 0
  dark-mode:
    enabled: true
    description: "Toggle mode gelap untuk semua pengguna"
    rollout_percentage: 100

Ketika tim siap untuk merilis checkout baru, mereka mengubah enabled: false menjadi enabled: true dan memperbarui persentase rollout. Tidak ada perubahan kode, tidak ada deployment ulang — hanya pembaruan konfigurasi yang berlaku segera.

Jika fitur berjalan dengan baik, Anda membukanya untuk lebih banyak pengguna. Jika ada yang rusak, Anda mematikan flag. Tidak perlu rollback, tidak perlu deployment darurat. Sisa aplikasi tetap berjalan normal.

Pola ini sangat cocok untuk tim yang sering melakukan deployment. Anda bisa melakukan deployment kode beberapa kali sehari tanpa khawatir mengekspos fitur yang belum selesai. Flag menjadi saklar pengaman Anda.

Canary Releases: Uji dengan Lalu Lintas Nyata

Canary releases membawa pemisahan lebih jauh. Anda melakukan deployment versi baru ke production tetapi hanya mengarahkan sebagian kecil pengguna ke versi tersebut — misalnya 5 persen. Kelompok ini mendapatkan kode baru sementara yang lainnya tetap pada versi lama.

Anda memantau tingkat error, waktu respons, dan perilaku pengguna untuk kelompok kecil itu. Jika semuanya terlihat normal, Anda secara bertahap meningkatkan persentasenya. Jika ada yang salah, Anda mengarahkan semua lalu lintas kembali ke versi lama. Tidak perlu rollback, tidak ada downtime.

Keuntungan utamanya adalah Anda menguji dengan lalu lintas nyata, bukan pengujian sintetis. Pengguna nyata memiliki browser nyata, kondisi jaringan nyata, dan pola penggunaan nyata. Canary menangkap masalah yang tidak akan pernah ditemukan oleh staging environment.

Blue-Green Deployment: Pemisahan di Tingkat Infrastruktur

Blue-green deployment memisahkan release dari deployment di tingkat infrastruktur. Anda memelihara dua production environment yang identik: blue dan green. Versi lama berjalan di blue. Anda melakukan deployment versi baru ke green sementara blue masih melayani semua pengguna.

Ketika Anda yakin green stabil, Anda mengalihkan lalu lintas dari blue ke green. Release terjadi pada saat peralihan lalu lintas, bukan saat deployment selesai. Jika ada yang salah setelah peralihan, Anda mengembalikan lalu lintas ke blue.

Pola ini berguna untuk aplikasi di mana Anda tidak bisa menggunakan feature flags dengan mudah, atau di mana perubahannya terlalu fundamental untuk di-toggle dengan flag. Perubahan skema database, upgrade framework besar, atau modifikasi infrastruktur sering kali diuntungkan oleh blue-green deployment.

Mengapa Memisahkan Deployment dan Release Itu Penting

Pemisahan memberi Anda kendali atas waktu. Anda bisa melakukan deployment jam 2 pagi saat lalu lintas rendah, tetapi menunda release hingga pagi hari ketika tim Anda siap memantau. Anda bisa melakukan deployment beberapa kali sehari tanpa khawatir mengganggu pengguna, karena release adalah keputusan terpisah.

Ini juga mengubah cara Anda menangani masalah. Ketika deployment dan release digabungkan, deployment yang buruk berarti pengguna langsung melihat error. Ketika dipisahkan, Anda punya waktu untuk mendeteksi masalah sebelum pengguna terpengaruh. Sinyal kesehatan dari deployment memberi tahu Anda bahwa server berjalan. Sinyal setelah release memberi tahu Anda bahwa pengguna puas.

Apa yang Harus Dipantau Setelah Release

Release adalah momen ketika pengguna mulai merasakan perubahan Anda. Sebelum release, semuanya dalam kendali Anda. Setelah release, pengguna terlibat. Jika ada masalah, merekalah yang merasakannya pertama kali.

Health check yang tampak hijau selama deployment mungkin tidak menceritakan keseluruhan cerita. Aplikasi berjalan, tetapi apakah pengguna menyelesaikan tugas mereka? Apakah tingkat error benar-benar rendah, atau apakah error terjadi di bagian aplikasi yang tidak tercakup oleh monitoring Anda? Apakah performa stabil di bawah beban pengguna nyata?

Anda perlu memantau secara berbeda setelah release. Perhatikan metrik yang berfokus pada pengguna: waktu muat halaman, tingkat penyelesaian transaksi, tingkat error per fitur. Bandingkan dengan baseline sebelum release. Deployment hijau dengan release yang buruk tetaplah hasil yang buruk.

Daftar Periksa Praktis untuk Release Berikutnya

Sebelum Anda menyatakan release selesai, periksa hal-hal berikut:

  • Dapatkah Anda melakukan rollback tanpa deployment ulang? Jika tidak, apa rencana rollback Anda?
  • Apakah Anda tahu pengguna mana yang melihat versi baru? Jika Anda melakukan canary, konfirmasi bahwa pembagian lalu lintas berfungsi.
  • Apakah Anda memantau metrik yang berfokus pada pengguna, bukan hanya kesehatan server? Kesehatan server memberi tahu Anda bahwa aplikasi berjalan. Metrik pengguna memberi tahu Anda bahwa aplikasi berfungsi.
  • Apakah Anda memiliki cara untuk menonaktifkan fitur tanpa deployment ulang? Jika Anda tidak menggunakan feature flags, pertimbangkan untuk menambahkannya sebelum release berikutnya.
  • Siapa yang perlu tahu bahwa release telah terjadi? Tim dukungan, penulis dokumentasi, dan pemangku kepentingan lainnya harus diberi tahu.

Kesimpulan

Deployment menempatkan kode di server. Release menempatkan fitur di tangan pengguna. Perlakukan keduanya sebagai keputusan terpisah, dan Anda akan mendapatkan kemampuan untuk melakukan deployment dengan percaya diri, merilis dengan hati-hati, dan pulih dengan cepat ketika ada yang salah. Tim terbaik tidak hanya melakukan deployment dengan baik — mereka juga melakukan release dengan baik, karena mereka tahu keduanya tidaklah sama.