Deploy vs Release: Mengapa Anda Perlu Tahu Perbedaannya

Anda baru saja menyelesaikan fitur baru di laptop. Kode berfungsi, pengujian lolos, dan Anda merasa puas. Sekarang Anda perlu mengirimkannya ke pengguna. Langkah selanjutnya yang jelas adalah menempatkan versi baru ke server produksi. Anda menjalankan skrip deployment, server mulai menjalankan kode baru, dan Anda pun bernapas lega.

Tapi inilah pertanyaan yang tidak nyaman: apakah pengguna Anda sudah benar-benar melihat fitur baru tersebut?

Jika Anda menjawab "ya" tanpa berpikir dua kali, Anda mungkin mencampuradukkan dua hal yang seharusnya dipisahkan. Deploy dan release bukanlah tindakan yang sama, dan memperlakukannya sebagai satu kesatuan menciptakan risiko yang tidak perlu.

Apa Sebenarnya Arti Deploy

Deploy adalah tindakan teknis. Anda mengambil artefak dari proses build, memindahkannya ke lingkungan target, dan menjalankannya di sana. Server kini menjalankan versi baru. Dari sudut pandang teknis, aplikasi sudah berada di tempat yang benar dan berjalan.

Anggap saja seperti ini: Anda baru saja pindah ke apartemen baru. Furnitur sudah di dalam, lampu menyala, dan tempat itu sudah layak huni. Tapi Anda belum membuka pintu depan untuk tamu.

Deploy menjawab pertanyaan "Apakah versi baru sudah ada di server?" Deploy tidak menjawab "Apakah pengguna sudah menggunakannya?"

Apa Sebenarnya Arti Release

Release adalah keputusan bisnis. Ini adalah momen ketika pengguna benar-benar dapat mengakses dan menggunakan perubahan yang Anda deploy. Anda bisa melakukan deploy tanpa melakukan release. Versi baru ada di server, tetapi pengguna masih berinteraksi dengan versi lama.

Perbedaan ini penting karena memberi Anda kendali. Saat Anda memisahkan deploy dari release, Anda mendapatkan kemampuan untuk memverifikasi, menjadwalkan, dan melakukan rollback perubahan secara independen.

Mengapa Memisahkan Keduanya Mengubah Segalanya

Anda Dapat Memverifikasi Sebelum Pengguna Melihatnya

Diagram urutan berikut mengilustrasikan pemisahan tersebut:

sequenceDiagram participant Dev as Developer participant Server as Production Server participant Users as Users Dev->>Server: Deploy artefak baru Note over Server: Versi baru berjalan Dev->>Server: Jalankan smoke test & verifikasi Note over Dev,Server: Langkah verifikasi Dev->>Server: Release (aktifkan fitur) Server->>Users: Pengguna melihat fitur baru

Setelah deploy, tim Anda dapat memeriksa apakah aplikasi berjalan normal di produksi tanpa membuat pengguna terpapar potensi masalah. Anda dapat menjalankan smoke test, memeriksa tingkat error, dan memastikan migrasi database tidak merusak apa pun. Jika ada yang terlihat salah, Anda memperbaikinya sebelum ada yang menyadarinya.

Inilah perbedaan antara "kami deploy dan berharap semuanya berfungsi" dengan "kami deploy, verifikasi berfungsi, lalu memutuskan untuk membiarkan pengguna melihatnya."

Anda Mengontrol Kapan Perubahan Dilihat Pengguna

Mungkin Anda ingin melakukan release saat lalu lintas rendah. Mungkin tim marketing Anda butuh waktu untuk menyiapkan pengumuman. Mungkin Anda menunggu dokumentasi selesai. Dengan memisahkan deploy dan release, Anda dapat menjadwalkan release secara independen dari deploy.

Ini sangat berguna untuk perubahan yang sensitif terhadap waktu. Anda dapat melakukan deploy patch keamanan segera ke server produksi, lalu me-release-nya ke pengguna pada momen yang dipilih dengan hati-hati.

Rollback Menjadi Lebih Aman

Rollback adalah tindakan mengembalikan aplikasi ke versi sebelumnya. Ketika deploy dan release digabungkan, rollback bersifat all or nothing. Anda mengembalikan kode, dan pengguna langsung melihat versi lama.

Ketika keduanya terpisah, Anda memiliki opsi. Jika release menyebabkan masalah, Anda dapat melakukan rollback release tanpa melakukan deploy ulang versi lama. Kode baru tetap di server, tetapi pengguna melihat perilaku lama. Atau, Anda dapat melakukan rollback deploy, dan release akan mengikuti secara otomatis.

Fleksibilitas ini mengurangi tekanan pada tim Anda. Anda tidak perlu terburu-buru memperbaiki karena Anda dapat dengan cepat menyembunyikan perubahan yang bermasalah dari pengguna.

Cara Memisahkan Deploy dan Release dalam Praktik

Pendekatan paling sederhana adalah feature toggle. Anda melakukan deploy kode baru dengan fitur dimatikan melalui konfigurasi. Ketika tim siap, Anda mengaktifkan toggle. Aktivasi itulah momen release Anda.

Pendekatan lain adalah traffic routing. Deploy versi baru ke subset server, lalu secara bertahap arahkan pengguna ke versi baru. Ini umum dalam canary deployment dan blue-green deployment. Deploy terjadi ketika versi baru sudah di server. Release terjadi secara bertahap seiring perpindahan traffic.

Beberapa tim menggunakan pemisahan lingkungan. Deploy ke lingkungan staging yang mirip dengan produksi, verifikasi di sana, lalu deploy ke produksi dan release segera. Ini tetap memisahkan deploy dari release jika Anda menganggap deploy staging sebagai langkah verifikasi sebelum release produksi.

Kesalahpahaman Umum

"Deploy dan release itu sama di setup kami." Ini biasanya berarti Anda tidak pernah memisahkannya, bukan berarti keduanya secara inheren sama. Jika deploy Anda secara otomatis membuat fitur tersedia untuk semua pengguna, Anda telah menggabungkannya karena pilihan, bukan karena keharusan.

"Feature toggle menambah kompleksitas." Memang, tetapi kompleksitasnya bisa dikelola. Mulailah dengan flag boolean sederhana di file konfigurasi. Anda tidak perlu sistem feature flag yang lengkap dari hari pertama.

"Memisahkan keduanya memperlambat kami." Awalnya, ya. Tapi pertama kali Anda menangkap masalah produksi sebelum pengguna melihatnya, atau pertama kali Anda melakukan rollback release dalam hitungan detik, bukan menit, Anda akan melihat nilainya.

Daftar Periksa Praktis Singkat

Sebelum deploy Anda berikutnya, tanyakan pertanyaan-pertanyaan ini:

  • Setelah deploy, bagaimana kami akan memverifikasi bahwa versi baru berfungsi di produksi?
  • Apa pemicu untuk release? Berbasis waktu? Persetujuan manual? Health check otomatis?
  • Jika release menyebabkan masalah, bagaimana cara menyembunyikannya dari pengguna tanpa melakukan deploy ulang?
  • Siapa yang memutuskan kapan release? Engineering? Product? Keduanya?
  • Bisakah kami melakukan deploy tanpa release? Jika tidak, apa perubahan terkecil yang memungkinkan hal itu?

Inti Sebenarnya

Deploy dan release adalah dua momen berbeda dalam proses pengiriman. Deploy bersifat teknis: kode ada di server. Release bersifat bisnis: pengguna dapat menggunakan kode. Memisahkan keduanya memberi Anda waktu verifikasi, fleksibilitas penjadwalan, dan opsi rollback yang lebih aman.

Anda tidak perlu peralatan yang rumit untuk memulai. Flag konfigurasi sederhana atau sakelar traffic manual sudah cukup. Yang penting adalah menyadari bahwa ini adalah dua keputusan, bukan satu. Setelah Anda memperlakukannya secara terpisah, Anda akan bertanya-tanya mengapa Anda pernah menganggapnya sama.

Dan perbedaan ini menjadi semakin penting saat Anda mulai melakukan deploy lebih sering. Karena setelah release pertama, aplikasi Anda akan terus berubah. Setiap perubahan melalui deploy dan release lagi. Memahami perbedaannya sejak awal membuat siklus berulang tersebut lebih aman dan tidak terlalu menegangkan.