Deploy vs Release: Mengapa Progressive Delivery Memisahkan Dua Hal yang Selama Ini Anda Anggap Sama

Tim Anda baru saja menyelesaikan alur checkout baru. Kode sudah diuji, pull request sudah di-merge, dan pipeline deployment hijau. Anda menekan tombol deploy. Versi baru masuk ke production. Sekarang setiap pengguna melihat tombol yang didesain ulang, field form yang diatur ulang, dan layar konfirmasi yang baru.

Tapi bagaimana jika Anda ingin melihat bagaimana performa alur baru tersebut sebelum menampilkannya ke semua orang? Bagaimana jika Anda hanya ingin mengizinkan 5% pengguna mencobanya terlebih dahulu, lalu memperluas berdasarkan data nyata?

Di sebagian besar tim, deploy dan release terjadi di waktu yang sama. Ketika kode baru mendarat di server, fitur di dalamnya langsung tersedia bagi pengguna. Namun, dua tindakan ini tidak harus terikat. Memisahkan keduanya memberi Anda tingkat kendali yang mengubah cara Anda berpikir tentang mengirimkan perangkat lunak.

Deploy itu teknis. Release itu pengalaman.

Deploy adalah tindakan menempatkan kode ke server. Ini adalah operasi teknis. Anda membangun artefak, mentransfernya ke environment, dan memulai versi baru. Server sekarang menjalankan kode baru.

Release adalah tindakan membuat fitur tersedia bagi pengguna. Ini adalah keputusan berdasarkan pengalaman. Kode sudah berjalan di server, tetapi fitur disembunyikan di balik saklar. Ketika Anda membalik saklar itu, pengguna melihat perilaku baru.

Deploy yang sama dapat berisi beberapa fitur yang belum dirilis. Anda dapat deploy sekali dan merilis secara bertahap. Anda juga dapat merilis fitur ke satu grup pengguna tetapi tidak ke grup lain, semuanya dari versi aplikasi yang sama yang sedang berjalan.

Diagram di bawah mengilustrasikan pemisahan ini:

flowchart TD A[Kode di-merge] --> B[Deploy ke server] B --> C[Semua kode berjalan di server] C --> D{Pengecekan feature flag} D -- Flag aktif --> E[Rilis fitur ke pengguna] D -- Flag nonaktif --> F[Fitur disembunyikan dari pengguna] E --> G[Pantau metrik] G --> H{Data positif?} H -- Ya --> I[Perluas persentase rollout] H -- Tidak --> J[Matikan flag] I --> K[Rilis penuh] K --> L[Hapus flag dari kode] J --> F

Pemisahan ini adalah fondasi dari progressive delivery.

Contoh konkret

Bayangkan tim Anda membangun tombol "Beli Sekarang" baru. Tombolnya lebih besar, lebih berwarna, dan ditempatkan lebih menonjol. Tim yakin dengan kodenya, tetapi tidak yakin bagaimana reaksi pengguna yang sudah ada. Perubahan tata letak yang mendadak mungkin membingungkan orang yang telah menggunakan antarmuka lama selama berbulan-bulan.

Dengan progressive delivery, begini cara Anda menanganinya:

  1. Anda deploy versi baru ke production. Kode tombol baru berjalan di server, tetapi disembunyikan. Pengguna melihat tombol lama.
  2. Anda mengonfigurasi sistem feature flag untuk menampilkan tombol baru kepada 5% pengguna. Pengguna ini dipilih secara acak.
  3. Setelah satu minggu, Anda memeriksa data. Pengguna yang melihat tombol baru menyelesaikan pembelian dengan tingkat yang lebih tinggi. Tidak ada laporan kebingungan.
  4. Anda meningkatkan rollout ke 50% pengguna. Seminggu lagi berlalu. Datanya masih terlihat bagus.
  5. Anda merilis ke 100% pengguna. Fitur sekarang sepenuhnya aktif.

Perhatikan apa yang terjadi: satu deploy, beberapa release. Kode masuk ke production sekali. Fitur menjadi terlihat secara bertahap, didorong oleh perilaku pengguna nyata.

Feature flag adalah mekanismenya

Untuk memisahkan deploy dari release, Anda memerlukan feature flag. Feature flag adalah cabang bersyarat dalam kode Anda yang memeriksa apakah suatu fitur harus aktif untuk pengguna saat ini. Flag dikendalikan secara eksternal, biasanya melalui layanan konfigurasi atau platform feature flag khusus.

Feature flag sederhana terlihat seperti ini dalam kode:

if feature_flags.is_active("new_checkout_button", user_id):
    render_new_button()
else:
    render_old_button()

Flag dapat diaktifkan/dinonaktifkan tanpa deployment baru. Anda mengubah konfigurasi, dan permintaan berikutnya dari pengguna tersebut melihat perilaku baru. Tidak ada perubahan kode, tidak ada build, tidak ada deploy.

Feature flag juga memungkinkan eksperimentasi. Anda dapat menjalankan pengujian A/B dengan mengarahkan segmen pengguna yang berbeda ke varian fitur yang berbeda. Satu grup melihat tombol merah, grup lain melihat tombol biru. Data memberi tahu Anda mana yang bekerja lebih baik.

Bagaimana ini berbeda dari canary dan staged rollout

Canary deployment dan staged rollout adalah tentang mengarahkan pengguna ke versi aplikasi yang berbeda. Anda menjalankan dua versi secara berdampingan, dan load balancer mengirimkan persentase traffic ke versi baru. Jika ada yang salah, Anda mengalihkan traffic kembali ke versi lama.

Progressive delivery bekerja secara berbeda. Anda menjalankan satu versi aplikasi. Semua pengguna mengenai server yang sama. Namun dalam versi itu, pengguna yang berbeda melihat fitur yang berbeda. Pemisahan terjadi di tingkat fitur, bukan di tingkat aplikasi.

Perbedaan ini penting ketika Anda ingin merilis fitur secara independen dari perubahan lain dalam deploy yang sama. Dengan canary, Anda tidak dapat merilis tombol baru ke 5% pengguna sambil menyembunyikan sisa versi baru. Anda mengirim pengguna ke versi baru atau versi lama. Dengan progressive delivery, Anda mengontrol setiap fitur secara individual.

Biaya feature flag

Feature flag tidak gratis. Setiap flag menambahkan cabang bersyarat ke kode Anda. Seiring waktu, flag menumpuk. Jika Anda tidak membersihkannya, basis kode Anda dipenuhi dengan kondisi mati yang membuat logika lebih sulit dibaca dan lebih sulit diuji.

Pola umum adalah menggunakan flag untuk suatu fitur, memvalidasinya, meluncurkannya sepenuhnya, dan kemudian menghapus flag di sprint berikutnya. Namun tim sering melupakan langkah ini. Flag tetap ada di kode, dan tidak ada yang ingat apa yang dikendalikannya atau apakah masih aktif.

Kedisiplinan penting di sini. Perlakukan feature flag sebagai sementara secara default. Ketika suatu fitur sepenuhnya dirilis ke semua pengguna, jadwalkan pekerjaan pembersihan. Jika Anda menggunakan platform feature flag, sebagian besar alat menyediakan dashboard yang menunjukkan flag mana yang sudah sepenuhnya di-rollout dan siap dihapus.

Kapan progressive delivery masuk akal

Tidak semua tim membutuhkan progressive delivery. Jika aplikasi Anda kecil, basis pengguna Anda homogen, dan fitur Anda sederhana, overhead feature flag mungkin tidak sepadan.

Namun progressive delivery menjadi berharga ketika:

  • Anda mengirimkan fitur yang mengubah perilaku pengguna secara signifikan.
  • Anda memiliki basis pengguna yang besar atau beragam di mana reaksi bervariasi.
  • Anda ingin memvalidasi fitur dengan data nyata sebelum rilis penuh.
  • Tim Anda sering merilis dan ingin memisahkan irama deploy dari waktu rilis.

Wawasan utamanya adalah bahwa progressive delivery memberi Anda jalan tengah antara "kirim ke semua orang" dan "jangan kirim sama sekali." Anda dapat mengirimkan kode, mengamati dampaknya, dan memperluas rilis berdasarkan bukti.

Daftar periksa praktis untuk mengadopsi progressive delivery

Jika Anda memutuskan untuk memisahkan deploy dari release, berikut langkah-langkah untuk memulai:

  • Pilih satu fitur yang akan diuntungkan dari paparan bertahap. Jangan mulai dengan setiap fitur.
  • Tambahkan feature flag untuk fitur tersebut. Gunakan file konfigurasi sederhana atau layanan khusus.
  • Deploy kode dengan flag dimatikan. Verifikasi fitur tersembunyi.
  • Nyalakan flag untuk persentase kecil pengguna. Pantau metrik dan log.
  • Perluas persentase berdasarkan data. Jika ada yang salah, matikan flag segera.
  • Ketika fitur sepenuhnya di-rollout, hapus flag dari kode.

Kesimpulan

Deploy dan release bukanlah hal yang sama. Deploy adalah menempatkan kode di server. Release adalah membuat fitur terlihat oleh pengguna. Progressive delivery memisahkan dua tindakan ini sehingga Anda dapat mengirimkan kode sesuai jadwal Anda dan merilis fitur sesuai jadwal data.

Lain kali tim Anda menyelesaikan fitur, tanyakan: apakah kita perlu merilis ini ke semua orang sekarang, atau bisakah kita membiarkan data yang memutuskan?