Feature flag release notları: ne söylenir, ne zaman

Bir özellik talebinde döngüyü kapatmak, şeyin teslim edildiği net bir an olduğunu varsayar. Bir feature flag bu anı ortadan kaldırır, ve feature flag release notlarının zamanlamasını zorlaştıran da budur. Kod merge edilir, flag var olur, ve günler ya da haftalar boyunca özellik aynı anda hem canlıdır hem de onu isteyebilecek neredeyse herkes için görünmezdir, sıklıkla bunu ilk başta isteyen kişi de dahil. Çok erken haber vermek onu henüz orada olmayan bir özelliğe götürür. Çok geç haber vermek, güven inşa etmesi gereken döngünün unutulmuş gibi okunmasına neden olur.

Bir flag olağan “teslim et, haber ver” sırasını neden bozar?

Çünkü bir olayı en az ikiye böler: kodun canlıya çıkması, ve flag’in belirli bir hesap için açılması. Bir geri bildirim döngüsünü kapatmanın her süreci bunların birlikte gerçekleştiğini varsayar, ki bu çoğu sürüm için doğru ve aşamalı yayılım, hedefleme ya da acil kapatma anahtarı olarak kullanılan bir flag’in arkasındaki her şey için yanlıştır. Müşteri geri bildirim döngüsünü kapatmak isteyen kişiye tam olarak bir changelog girişi onaylanıp yayınlandığı anda haber vermeyi tarif eder; bu adım, girişi yayınlamak ile özelliğin kullanılabilir olması aynı an olduğunda için yazılmıştır, ve bir flag tam olarak bunların aynı olmadığı durumdur.

Birine ne zaman haber verileceğine dair gerçek kural nedir?

Flag hesabı için açık olduğunda haber ver, kod merge edildiğinde değil ve flag oluşturulduğunda değil. Bu tek kural yukarıdaki tablonun her satırını kapsar, çünkü bildirimi isteyen kişi için gerçekten önemli olan tek gerçeğe bağlar: şu anda gidip o şeyi kullanabilir mi. Merge’e ya da flag’in oluşturulmasına bağlı bir bildirim aslında bir mühendislik ilerleme raporudur, ve bir özellik isteyen kişi ilerleme raporu istemez, ne zaman bakacağını bilmek ister.

Bu, isteyen kişinin erken veya özel erişime ihtiyacı olduğu anlamına mı gelir?

Mutlaka değil, ve bunu zorlamak kendi sorununu yaratır. Flag yük veya kararlılık nedenleriyle aşamalı olarak yayılıyorsa, bir hesabı sadece döngüyü daha hızlı kapatmak için sıranın başına taşımak, yayılımın kademeli olmasının nedenini baltalar. Dürüst seçenekler şunlardır: isteyen kişinin hesabının yayılıma doğal olarak ulaşmasını beklemek ve o zaman haber vermek, ya da, aciliyet bunu haklı çıkarıyorsa, yayılımın sahibi olan kişinin gerçek bir kararı olarak bilinçli şekilde onu erken açmak, bir bildirim gönderme isteğinin yan etkisi olarak değil.

Ya flag bir yayılım mekanizması değil de acil kapatma anahtarıysa?

O zaman güvenli varsayım tersine döner. Bir özelliği yayılımını kademelendirmek yerine hızlıca kapatabilmek için var olan bir flag genelde özelliğin oluşturulduğu anda tamamen canlı olması gerektiği anlamına gelir, ve flag sıralama yerine güvenlik için vardır. Bu durumda, isteyen kişiye deploy anında haber vermek doğrudur, flag’siz herhangi bir sürümde olduğu gibi; flag’in varlığı döngünün ne zaman kapandığını değiştirmemesi gereken operasyonel bir ayrıntıdır. Önemli olan ayrım flag’in ne için olduğudur, birinin var olup olmadığı değil.

Flag, feature flag release notlarının ne söylemesi gerektiğini değiştirir mi?

Ne zaman yayınlandığını değiştirir, neyi içerdiğini değil. Flag hesapların %100’ü için açık olduğu tam anda yayınlanan bir giriş, tam olarak normal bir changelog girişi gibi okunur, ve öyle olmalı; onu daha sonra bulan bir okuyucunun bir flag’in hiç işin içinde olduğunu bilmesi için hiçbir nedeni yoktur. Yapmaması gereken şey, flag sadece küçük bir yayılım yüzdesi için açıkken yayınlanmaktır, çünkü genel bir changelog girişi onu okuyan herkesi, flag’i olmayan hesaplar dahil, bulamayacakları bir özelliği aramaya gönderir, ki bu aynı sorunun daha kötü bir versiyonudur, tek bir isteyen kişinin ölçeğinde değil ürün genelinde. Bu zamanlama kuralı, feature flag release notları ile sıradan bir giriş arasındaki tüm farktır: içerik aynıdır, sadece yayın tarihi değişir. Release notes nasıl yazılır burada da geçerli olan “hiçbir eylem gerekmiyor” disiplinini ele alır: okuyuculara bunun onları etkileyip etkilemediği söylenmeli, sadece bir yerde var olduğu değil.

Ürün güncelleme e-postaları flag’li bir özelliği farklı ele almalı mı?

Evet, çoğunlukla yeniden yazmak yerine erteleyerek. Ürün güncelleme e-postası şablonu hedeflenmiş bildirimleri geniş özetlere karşı ele alır; flag’li bir özellik, hedeflenmiş bir bildirimin zamanlamasının gönderilmeden önce alıcının kendi flag durumuna karşı kontrol edilmesi gereken bir durumdur, ki bu bir geniş özetin hiç kolayca yapamayacağı bir şeydir, bu da hâlâ yayılımın ortasındaki her şey için bir özetin neden yanlış kanal olduğuna dair bir neden daha.

FAQ

Flag var olduğu ama isteyen kişi için henüz açık olmadığı zaman ona özelliğinin “yakında geliyor” olduğu söylenmeli mi? Sadece gerçek, yakın bir tarih varsa, ve o zaman bile ölçülü şekilde. Tarihsiz bir “yakında”, yeterince zaman geçtikten sonra tam olarak sessizlik gibi okunur, ve izlenmesi ve tutulması gereken ikinci bir söz yaratır.

Bir flag’in döngüyü kapatacak kadar ilerlediğine kim karar verir? Bildirimin sahibi değil, yayılımın sahibi. Yayılımı olan kişi “hesapların %100’ü”nün yakın mı yoksa hâlâ haftalar uzakta mı olduğunu bilir; döngüyü kapatma adımını sabit bir takvim tarihine değil onun durumuna bağlamak bildirimi dürüst tutar.

Kalıcı bir flag arkasındaki (hiç tamamen kaldırılmayan) bir özellik hiç genel bir changelog girişi alır mı? Evet, o ürün için “genel kullanıma açık” ne anlama geliyorsa ona ulaştığında, flag’in kendisi operasyonel nedenlerle sonsuza kadar kodda kalsa bile. Changelog girişi okuyucu için erişilebilirlikle ilgilidir, o erişilebilirliğin nasıl gerçekleştirildiği uygulama detayıyla değil.

Ya flag kaldırılır ve özellik teslim edilmek yerine öldürülürse? Bu bir ret, teslimat bildirimi değildir, ve başka herhangi bir ret kadar özen hak eder. Bir özellik talebi nasıl reddedilir o mesajın ne söylemesi gerektiğini ele alır; döngüyü dürüstçe kapatmak bazen onu bir hayırla kapatmak anlamına gelir.

Feature flag release notları normal bir girişten farklı bir şablona mı ihtiyaç duyar? Şablon değişmez, sadece yayından önce bir kapı adımı eklenir: kodun sadece merge edildiğine değil, soran hesap için flag durumuna bakın, ve bu kontrol geçene kadar girişi bekletin. Girişle ilgili geri kalan her şey, ifade, uzunluk, FAQ disiplini, diğer her release notu kadar aynı kalır.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Geliştirici dokümantasyonu, Changelog araçları karşılaştırması