Release notes feature flag: apa yang disampaikan, dan kapan
5 menit baca
Menutup lingkaran pada permintaan fitur mengasumsikan ada momen bersih saat sesuatu itu dirilis. Feature flag menghilangkan momen itu, dan itulah yang membuat waktu release notes feature flag sulit ditentukan. Kode di-merge, flag ada, dan selama berhari-hari atau berminggu-minggu setelahnya fitur itu sekaligus live di produksi dan tidak terlihat bagi hampir semua orang yang mungkin ingin menggunakannya, sering termasuk orang yang awalnya memintanya. Memberi tahu terlalu cepat membuatnya menemui fitur yang belum ada. Memberi tahu terlalu lambat membuat lingkaran yang seharusnya membangun kepercayaan malah terbaca sebagai terlupakan.
Kenapa flag merusak urutan biasa “rilis, beri tahu”?
Karena itu memecah satu peristiwa jadi setidaknya dua: kode yang menjadi live, dan flag yang dinyalakan untuk akun tertentu. Setiap proses menutup lingkaran umpan balik mengasumsikan keduanya terjadi bersamaan, yang benar untuk kebanyakan rilis dan salah untuk apa pun di balik flag yang dipakai untuk rollout bertahap, penargetan, atau sebagai tombol darurat. Menutup lingkaran umpan balik pelanggan menjelaskan memberi tahu peminta persis pada saat entri changelog disetujui dan dipublikasikan; langkah itu ditulis untuk kasus di mana mempublikasikan entri dan fitur menjadi bisa dipakai adalah momen yang sama, dan flag justru kasus di mana keduanya tidak sama.
| Momen | Apa yang benar | Sudah harus diberi tahu peminta |
|---|---|---|
| Kode di-merge, flag mati di mana-mana | Fitur ada, tidak ada yang bisa memakainya | Tidak |
| Flag menyala untuk akun peminta | Fitur ada, orang itu spesifik bisa memakainya | Ya |
| Flag menyala untuk persentase rollout yang mengecualikannya | Fitur ada, orang itu masih belum bisa memakainya | Tidak |
| Flag sepenuhnya dihapus, fitur begitu saja menyala | Fitur ada untuk semua orang | Ya, jika belum diberi tahu |
Apa aturan sebenarnya untuk kapan memberi tahu seseorang?
Beri tahu saat flag menyala untuk akun mereka, bukan saat kode di-merge dan bukan saat flag dibuat. Satu aturan ini mencakup setiap baris tabel di atas, karena mengaitkan notifikasi dengan satu-satunya fakta yang benar-benar penting bagi peminta: apakah mereka, saat ini juga, bisa pergi memakai sesuatu itu. Notifikasi yang dikaitkan dengan merge atau pembuatan flag sebenarnya adalah laporan kemajuan rekayasa, dan orang yang meminta fitur tidak mau laporan kemajuan, mereka mau tahu kapan harus memeriksa.
Apakah itu berarti peminta butuh akses awal atau khusus?
Belum tentu, dan memaksakannya menciptakan masalah sendiri. Jika flag digulirkan bertahap karena alasan beban atau stabilitas, memindahkan satu akun ke depan antrean hanya untuk menutup lingkaran lebih cepat merusak alasan mengapa rollout itu dibuat bertahap sejak awal. Pilihan yang jujur adalah: menunggu akun peminta mencapai rollout secara alami dan memberi tahu mereka saat itu, atau, jika urgensinya membenarkan, dengan sengaja menyalakan flag lebih awal untuk mereka, sebagai keputusan nyata dari siapa pun yang memiliki rollout, bukan sebagai efek samping dari keinginan mengirim notifikasi.
Bagaimana jika flag itu tombol darurat, bukan mekanisme rollout?
Maka asumsi amannya terbalik. Flag yang dibuat agar bisa cepat mematikan fitur, alih-alih membertahapkan rilisnya, biasanya berarti fitur itu dimaksudkan sepenuhnya live begitu dibuat, dan flag ada demi keamanan alih-alih urutan. Dalam kasus itu, memberi tahu peminta saat waktu deploy sudah benar, sama seperti rilis mana pun tanpa flag; keberadaan flag adalah detail operasional yang seharusnya tidak mengubah kapan lingkaran ditutup. Perbedaan yang penting adalah untuk apa flag itu, bukan apakah ada satu.
Apakah flag mengubah apa yang seharusnya dikatakan release notes feature flag?
Itu mengubah kapan entri dipublikasikan, bukan apa isinya. Entri yang dipublikasikan persis pada saat flag menyala untuk 100% akun terbaca persis seperti entri changelog normal, dan memang seharusnya begitu; pembaca yang menemukannya nanti tidak punya alasan untuk tahu bahwa flag pernah terlibat. Yang seharusnya tidak dilakukan adalah dipublikasikan saat flag hanya menyala untuk persentase rollout kecil, karena entri changelog publik mengirim semua orang yang membacanya, termasuk akun tanpa flag, untuk mencari fitur yang tidak akan mereka temukan, yang merupakan versi lebih buruk dari masalah yang sama, dalam skala seluruh produk alih-alih skala satu peminta. Aturan waktu itulah seluruh perbedaan antara release notes feature flag dan entri biasa: isinya sama, hanya tanggal publikasinya yang bergeser. Cara menulis release notes membahas disiplin “tidak perlu tindakan” yang juga berlaku di sini: pembaca harus tahu apakah ini berlaku bagi mereka, bukan hanya bahwa itu ada di suatu tempat.
Haruskah email pembaruan produk memperlakukan fitur berflag secara berbeda?
Ya, terutama dengan menunda alih-alih menulis ulang. Template email pembaruan produk membahas notifikasi bertarget versus digest luas; fitur berflag adalah kasus di mana waktu notifikasi bertarget harus diperiksa terhadap status flag penerima itu sendiri sebelum dikirim, sesuatu yang tidak bisa dilakukan digest luas dengan mudah sama sekali, yang jadi alasan tambahan kenapa digest adalah kanal yang salah untuk apa pun yang masih di tengah rollout.
FAQ
Haruskah memberi tahu peminta bahwa fiturnya “segera hadir” begitu flag ada tapi belum menyala untuk mereka? Hanya jika ada tanggal nyata dan dekat, dan bahkan begitu, secukupnya saja. “Segera hadir” tanpa tanggal terbaca, setelah cukup waktu berlalu, sama saja dengan diam, dan menciptakan janji kedua yang juga harus dilacak dan ditepati.
Siapa yang memutuskan kapan flag sudah cukup jauh untuk menutup lingkaran? Siapa pun yang memiliki rollout, bukan siapa pun yang memiliki notifikasi. Pemilik rollout tahu apakah “100% akun” sudah dekat atau masih berminggu-minggu lagi; mengaitkan langkah penutupan lingkaran dengan status mereka, alih-alih tanggal kalender tetap, menjaga notifikasi tetap jujur.
Apakah fitur di balik flag permanen (tidak pernah sepenuhnya dihapus) pernah mendapat entri changelog publik? Ya, begitu mencapai apa pun yang dimaksud “ketersediaan umum” bagi produk itu, meski flag itu sendiri tetap ada di kode selamanya karena alasan operasional. Entri changelog membicarakan ketersediaan bagi pembaca, bukan detail implementasi tentang bagaimana ketersediaan itu terwujud.
Bagaimana jika flag dihapus dan fitur dimatikan alih-alih dirilis? Itu adalah penolakan, bukan notifikasi rilis, dan pantas mendapat kehati-hatian yang sama seperti penolakan lainnya. Cara menolak permintaan fitur membahas apa yang seharusnya dikatakan pesan itu; menutup lingkaran dengan jujur kadang berarti menutupnya dengan penolakan.
Apakah release notes feature flag butuh template terpisah dari entri normal? Tidak ada perubahan template, hanya satu langkah gating sebelum publikasi: periksa status flag untuk akun yang meminta, bukan hanya bahwa kodenya sudah di-merge, dan tahan entrinya sampai pemeriksaan itu lolos. Semua hal lain tentang entrinya, kata-katanya, panjangnya, disiplin FAQ-nya, tetap sama seperti release notes lainnya.
Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.