Deployment vs Release: Mengapa Kode Baru Anda Belum Sampai ke Pengguna

Anda baru saja menyelesaikan deployment. Pipeline hijau, artefak sudah berada di server produksi, dan tim Anda siap menyebutnya selesai. Namun saat Anda memeriksa aplikasi, pengguna masih melihat versi lama. Tidak ada yang berubah di sisi mereka.

Momen ini membingungkan banyak tim. Anda melakukan semuanya dengan benar. Kode sudah ada. Server menjalankan binary baru. Lalu mengapa pengguna tidak mendapatkan pembaruan?

Jawabannya sederhana: deployment dan release adalah dua hal yang berbeda. Dan memahami perbedaan itu mengubah cara Anda berpikir tentang mengirimkan perangkat lunak.

Deployment Berarti Kode Berada di Server

Deployment adalah tindakan menempatkan versi baru aplikasi Anda ke server. Artefak keluar dari registry, disalin ke lingkungan target, dan server mulai menjalankannya. Jika Anda melakukan deployment ke produksi, versi baru secara fisik sudah ada di server produksi.

Itu saja. Deployment adalah tindakan teknis. Ini tidak mengatakan apa pun tentang apakah pengguna benar-benar dapat menggunakan versi baru tersebut.

Anggap saja seperti ini: Anda telah memuat film baru ke proyektor di bioskop. Film sudah terpasang, gulungan siap, dan proyektor menyala. Tapi filmnya belum mulai diputar. Penonton masih menonton film sebelumnya.

Diagram berikut menunjukkan timeline dan alur lalu lintas antara versi lama dan baru selama deployment, release, dan canary release:

sequenceDiagram participant Dev as Tim Dev participant LB as Load Balancer participant Old as Versi Lama participant New as Versi Baru participant User as Pengguna Dev->>LB: Deploy versi baru LB->>New: Mulai versi baru Note over New: Berjalan tapi idle User->>LB: Request LB->>Old: Arahkan ke versi lama Note over LB: Momen release Dev->>LB: Alihkan traffic ke baru LB->>New: Arahkan semua pengguna Note over LB: Canary release Dev->>LB: Arahkan 5% ke baru User->>LB: Request LB->>New: Arahkan beberapa pengguna LB->>Old: Arahkan sebagian besar pengguna Dev->>LB: Naikkan ke 50% Dev->>LB: Arahkan 100%

Release Berarti Pengguna Mendapatkan Versi Baru

Release adalah momen ketika versi baru mulai melayani traffic pengguna yang sebenarnya. Traffic berarti permintaan yang datang dari pengguna ke aplikasi Anda. Selama traffic masih diarahkan ke versi lama, pengguna tidak akan merasakan efek apa pun dari kode baru yang ada di server.

Versi baru sudah ada. Ia berjalan. Tapi ia idle. Tidak ada yang mengaksesnya.

Release adalah saat Anda mengganti tanda dari "segera tayang" menjadi "sedang tayang." Proyektor mulai berputar, dan penonton melihat film baru.

Mengapa Repot-repot Memisahkannya?

Jika Anda bisa melakukan deployment dan release secara bersamaan, mengapa Anda ingin memisahkannya? Karena pemisahan memberi Anda kendali.

Ketika deployment dan release adalah tindakan yang sama, setiap deployment menjadi perjudian. Anda mendorong kode, pengguna langsung melihatnya, dan jika ada yang rusak, semua orang mengalami masalah. Tidak ada penyangga antara "kami menempatkannya di sana" dan "pengguna melihatnya."

Ketika Anda memisahkannya, Anda mendapatkan jendela waktu. Anda dapat:

  • Melakukan deployment versi baru dan membiarkannya diam.
  • Memantau perilakunya tanpa dampak pada pengguna.
  • Memverifikasi bahwa ia mulai dengan benar, terhubung ke database, dan menangani permintaan internal.
  • Memperbaiki masalah sebelum ada pengguna yang menyadarinya.

Jendela waktu itu adalah jaring pengaman Anda. Ini mengubah deployment dari acara berisiko tinggi menjadi operasi rutin.

Cara Memisahkan Deployment dari Release

Metode paling sederhana menggunakan load balancer atau reverse proxy. Begini cara kerjanya:

  1. Lakukan deployment versi baru ke server bersama versi lama.
  2. Konfigurasi load balancer untuk mengirim semua traffic pengguna ke versi lama.
  3. Versi baru berjalan tetapi tidak menerima permintaan eksternal.
  4. Saat Anda siap, perbarui konfigurasi load balancer untuk mengarahkan traffic ke versi baru.

Perubahan konfigurasi itulah release Anda. Itu bisa terjadi beberapa detik setelah deployment, atau berjam-jam kemudian. Waktunya terserah Anda.

Berikut contoh praktis menggunakan CLI load balancer hipotetis untuk mengalihkan traffic:

# Deploy versi baru di samping versi lama
# (asumsikan keduanya sudah berjalan di server)

# Periksa distribusi traffic saat ini
trafficctl get-weight myapp
# Output: myapp-v1: 100%, myapp-v2: 0%

# Alihkan 10% traffic ke versi baru (canary)
trafficctl set-weight myapp-v2 10%

# Setelah pemantauan, alihkan semua traffic ke versi baru
trafficctl set-weight myapp-v2 100%

# Rollback jika diperlukan: langsung arahkan kembali semua traffic ke versi lama
trafficctl set-weight myapp-v1 100%

Canary Releases: Peluncuran Bertahap

Pendekatan yang lebih halus adalah canary release. Alih-alih mengalihkan semua traffic sekaligus, Anda mengirim persentase kecil pengguna ke versi baru terlebih dahulu.

Katakanlah Anda memiliki seribu pengguna. Anda mulai dengan merute lima puluh dari mereka ke versi baru. Jika semuanya terlihat baik setelah lima menit, Anda tingkatkan menjadi dua ratus. Lalu lima ratus. Lalu semuanya.

Pendekatan ini membatasi radius ledakan. Jika versi baru memiliki bug, hanya lima puluh orang yang mengalaminya, bukan seribu. Anda menangkap masalah lebih awal, dengan kerusakan minimal.

Canary releases juga bekerja dengan baik dengan feature flags. Anda dapat melakukan deployment kode yang tersembunyi di balik flag, mengaktifkannya untuk grup kecil, mengamati hasilnya, dan secara bertahap memperluas audiens.

Rollback Tanpa Redeployment

Pemisahan juga memudahkan rollback. Jika Anda me-release versi yang buruk, Anda tidak perlu melakukan deployment ulang versi lama. Versi lama masih ada di server, masih berjalan, dan masih mampu menangani traffic.

Anda tinggal mengubah konfigurasi load balancer kembali. Traffic beralih ke versi lama. Pengguna kembali ke kondisi stabil dalam hitungan detik.

Bandingkan dengan pendekatan deploy-dan-release gabungan. Di sana, rollback berarti:

  • Menemukan artefak lama.
  • Melakukan deployment ulang.
  • Menunggu server restart.
  • Berharap rollback itu sendiri tidak menimbulkan masalah.

Proses itu memakan waktu beberapa menit dalam kondisi terbaik, dan seringkali lebih lama. Selama waktu itu, pengguna mengakses aplikasi yang rusak.

Siapa yang Memutuskan Kapan Release?

Deployment adalah keputusan teknis. Pipeline CI/CD Anda dapat menanganinya secara otomatis. Namun release sering melibatkan pemangku kepentingan produk atau bisnis.

Tim produk tahu apakah fitur tersebut siap untuk pengguna. Mereka mungkin ingin mengujinya secara internal terlebih dahulu, menjalankan A/B test, atau menunda release karena alasan pemasaran. Mereka memahami dampak pengguna dengan cara yang tidak bisa dilakukan oleh pipeline deployment.

Ini tidak berarti setiap release membutuhkan rapat. Untuk pembaruan rutin, Anda dapat mengotomatiskan release setelah periode observasi singkat. Namun untuk perubahan signifikan, keputusan untuk release harus melibatkan orang-orang yang memahami konteks bisnis.

Daftar Periksa Praktis untuk Release Berikutnya

Sebelum Anda me-release versi baru ke pengguna, jalankan pemeriksaan ini:

  • Apakah versi baru sudah berjalan di produksi setidaknya beberapa menit tanpa error?
  • Apakah log menunjukkan perilaku normal?
  • Apakah Anda memiliki cara untuk mengarahkan traffic kembali ke versi lama jika diperlukan?
  • Apakah seseorang telah mengonfirmasi bahwa fitur tersebut siap dari perspektif produk?
  • Apakah jendela release dipilih untuk meminimalkan dampak pada pengguna?
  • Apakah Anda tahu siapa yang harus dihubungi jika ada yang salah setelah release?

Daftar ini sengaja dibuat pendek. Terlalu mempersulit proses release menyebabkan langkah-langkah dilewati. Buatlah sederhana, dan benar-benar jalankan setiap kali.

Inti Sebenarnya

Deployment dan release bukanlah hal yang sama. Deployment adalah menempatkan kode di server. Release adalah membiarkan pengguna menyentuhnya. Memperlakukan keduanya sebagai tindakan terpisah memberi Anda kendali atas risiko, kecepatan rollback, dan pengalaman pengguna.

Lain kali pipeline Anda berubah hijau, tanyakan pada diri sendiri: apakah Anda baru saja melakukan deployment, atau benar-benar melakukan release? Jawabannya menentukan apakah pengguna Anda mendapatkan pembaruan atau masih menunggu film dimulai.