30 saniyelik özet

Feature flag, bir özelliğin hangi kullanıcılar veya müşteri hesapları için açık olduğunu kontrol eden yazılım anahtarıdır. Progressive delivery, değişikliği sınırlı bir gruba açıp elde edilen kanıtlara göre erişimi aşamalı genişletme yaklaşımıdır. Birlikte kullanıldıklarında kodun canlı ortama alınması ile kullanıcıya sunulması ayrı kararlara dönüşür. Product Owner, yani ürünün değerini artırmaktan sorumlu rol, bu süreçte hedef grubu, beklenen faydayı ve ilerleme koşullarını netleştirir. Asıl soru özelliği açıp açamayacağımız değil, hangi kanıtla daha fazla kullanıcıya açacağımızdır.

Neden önemli?

Bir özelliğin test ortamında çalışması, gerçek kullanımda aynı sonucu vereceğini garanti etmez. Müşteriler farklı veri hacimleriyle, yetkilerle ve alışkanlıklarla çalışır. Herkese aynı anda sunulan değişiklik, fark edilmemiş bir sorunun etkisini büyütebilir. Üstelik hata çıkmasa bile kullanıcı yeni akışı anlamayabilir veya eski işini daha zor tamamlayabilir.

Kontrollü yayılım, bu belirsizlikleri daha dar bir alanda gözlemleme fırsatı verir. Ancak bunun iş değeri yalnızca teknik hataları azaltmak değildir. Destek ekibi yeni soruları görür, ürün ekibi kullanım davranışını izler, yöneticiler daha geniş yayılımın gerekçesini değerlendirebilir. Böylece yayın kararı takvimdeki bir tarihten çıkarak kanıta dayalı bir karar haline gelir.

Bu yaklaşım kapasite planlamasını da etkiler. Yeni özellik başarılı olduğunda talep artabilir; başarısız olduğunda destek yükü büyüyebilir. Yayılım planında yalnızca yazılım ekibinin hazırlığına bakmak eksik kalır. Müşteri iletişimi, eğitim içeriği ve operasyonun değişikliği karşılayabilmesi de değerlendirilmelidir. Erken erişim verilen müşteriye neyin değiştiğini anlatmak, geri bildirim kanalını belirlemek ve destek ekibini aynı bilgiyle donatmak ürün kararının parçasıdır.

Terim nedir?

Deployment, kodun canlı çalışma ortamına taşınmasıdır. Release ise özelliğin kullanıcıların erişimine sunulmasıdır. Feature flag bu iki adımı ayırabilir: Yeni kod canlı ortamda bulunurken özellik kapalı tutulabilir; hazır olduğunda belirlenen gruba açılabilir. Bu, her erişim değişikliği için yeniden kod yayımlama ihtiyacını azaltır.

Progressive delivery ise anahtarı açmanın ötesinde bir karar düzeni gerektirir. Kimlerle başlanacağı, hangi verilerin izleneceği, gözlem için hangi kullanım koşullarının oluşması gerektiği ve hangi durumda yayılımın durdurulacağı önceden belirlenir. Sorun görülmediğinde kapsam genişletilir; olumsuz sinyal geldiğinde aynı kapsamda kalınabilir veya özellik kapatılabilir.

Hedefleme birimi önemlidir. Ortak veri üzerinde çalışan bir kurumsal üründe kullanıcı bazında açılış, aynı müşteri hesabında farklı deneyimler oluşturabilir. Hesap bazında açılış daha tutarlı olabilir. Ayrıca kullanıcı her girişinde farklı bir deneyime düşüyorsa geri bildirimleri yorumlamak zorlaşır. Hangi birimin hangi deneyimi gördüğü ölçüm kayıtlarında da anlaşılmalıdır.

Geçici yayın anahtarları ile uzun süre kullanılan operasyon anahtarlarının ömrü aynı değildir. Geçici anahtar işini bitirdiğinde ilgili kod dalları ve testler temizlenmelidir. Her anahtarı süresiz tutmak bakım yükünü artırır.

Kavramsal kaynak: Pete Hodgson, Feature Toggles (aka Feature Flags), MartinFowler.com.

Gerçek vaka: GitHub’ın aşamalı özellik açma yaklaşımı

Alberto Gimeno’nun 27 Nisan 2021 tarihli GitHub mühendislik yazısı, şirketin feature flag kullanımını doğrudan anlatır. Yazıda GitHub Discussions ve GitHub Actions için manuel onay özelliği, bu araçla sunulan yenilikler arasında anılır.

GitHub, geliştirme sırasında özelliği üzerinde çalışan personele açabildiğini belirtir. Özellik yayına yaklaştığında çalışanlara daha geniş erişim verilir; iç duyuru ve geri bildirim kaydıyla sorunlar toplanır. Önemli değişiklikler için erken erişim gruplarından da geri bildirim alınır. Kullanıcı kapsamı oran üzerinden genişletilebilir ve bu değişiklik ekiplerin görebileceği bir iletişim kanalında duyurulur.

Yazı, hedeflemenin kullanıcıyla sınırlı olmadığını da gösterir: Organizasyon veya depo gibi birimler seçilebilir. Özellikle ortak verinin değiştiği durumlarda tutarlılık dikkate alınır. Yayılım tamamlandıktan sonra kullanılmayan kod ve testlerin temizlenmesi de ele alınır.

Bu vakadan çıkarılabilecek yönetim dersi, erişimi değiştirebilmenin tek başına yeterli olmadığıdır. Geri bildirim kanalı, ekipler arası görünürlük ve anahtarın yaşam döngüsü birlikte tasarlanmalıdır. Kaynak, burada aktarılan uygulamalara sayısal bir gelir artışı atfetmez.

Kaynak: GitHub Blog, How we ship code faster and safer with feature flags.

Varsayımsal örnek: Ortak rapor ekranının yenilenmesi

Kurumsal müşterilere hizmet veren bir ürün ekibi, ekiplerin birlikte kullandığı rapor ekranını yeniler. Amaç, kullanıcıların ihtiyaç duydukları raporu bulup doğru filtrelerle hazırlamasını kolaylaştırmaktır. Yeni ekran kodu canlı ortama alınır; erişim başlangıçta ekip içindeki deneme hesaplarıyla sınırlıdır.

Ürün sahibi, müşteri hesaplarını açılış birimi olarak seçer. Böylece aynı şirketin kullanıcıları ortak ekranı aynı biçimde görür. Pilot hesaplar yalnızca ürünü seven müşterilerden seçilmez; farklı veri hacimleri ve kullanım biçimleri dikkate alınır. Destek ekibine ekran değişikliği ve geri bildirimlerin nasıl kaydedileceği anlatılır.

Ekip, rapor hazırlama akışının tamamlanmasını, filtrelerin doğru uygulanmasını ve kullanıcıların yardım isteme nedenlerini izler. Beklenen fayda ile koruyucu göstergeler ayrılır: Raporu daha kolay hazırlamak hedeflenen faydadır; yanlış veri gösterilmemesi ve mevcut kayıtların korunması yayılımın koşuludur. Bu göstergeleri okuyabilmek için eski ekranın mevcut davranışı da başlangıçta kaydedilir.

Pilot sırasında kullanıcılar raporu hazırlasa da filtrelerin anlamını karıştırırsa ekip yayılımı genişletmez. Sorunun ekran açıklamalarından mı, veri modelinden mi kaynaklandığını araştırır. Özelliğin kapatılması eski ekrana dönüşü sağlayabilir; daha önce oluşturulan yanlış raporları kendiliğinden düzeltmez. Bu nedenle geri dönüş planı, erişimi kapatma işlemiyle birlikte etkilenen kayıtların incelenmesini de içerir. Teknik sorun çözülse bile kullanıcıların aynı işi rahatça tamamlayabildiğine dair gözlem alınmadan kapsam artırılmaz.

Yaygın üç hata

  1. Takvimi ilerleme ölçütü yapmak

Pilotun planlanan süresi dolduğunda otomatik olarak herkese açmak, öğrenme amacını zayıflatır. Kritik kullanım senaryoları henüz gerçekleşmemiş olabilir. Yayılımın genişlemesi, beklenen gözlemlerin oluşmasına ve önceden belirlenen koşulların karşılanmasına bağlanmalıdır. Sadece sessiz geçen bir dönem yeterli kanıt değildir.

  1. Anahtarı kapatmayı tam geri dönüş sanmak

Feature flag yeni davranışı durdurabilir; yapılmış veri değişikliklerini veya gönderilmiş bildirimleri geri almayabilir. Ekip, kapatma sonrası hangi durumun korunacağını ve hangi düzeltmenin ayrıca yapılacağını açıklamalıdır. Ayrıca bir özelliği arayüzde gizlemek, kullanıcının o işlemi yapma yetkisini kontrol etmenin yerine geçmez.

  1. Sorunsuz yayılımı değer kanıtı saymak

Hata görülmemesi, müşterinin fayda elde ettiğini göstermez. Özelliğin kullanılması da tek başına davranış değişikliğinin nedenini açıklamaz. A/B testi, farklı deneyimlerin etkisini uygun gruplarla karşılaştıran deney yöntemidir; her kademeli açılış böyle bir deney değildir. Teknik sağlık ve ürün faydası ayrı sorularla değerlendirilmelidir.

Mini uygulama / şablon

Özellik ve hedeflenen kullanıcı problemi
—
Beklenen kullanıcı davranışı veya iş sonucu
—
Anahtarın sahibi ve değişiklik yapma yetkisi
—
İlk hedef grup ve seçim gerekçesi
—
Açılış birimi
Kullanıcı, hesap veya başka bir birim:
Mevcut davranış için başlangıç verisi
—
İzlenecek fayda göstergeleri
—
Bozulmaması gereken kalite göstergeleri
—
Yayılımı genişletmek için gerekli kanıt
—
Bekleme veya kapatma koşulları
—
Kapatma sonrası deneyim ve veri düzeltme ihtiyacı
—
Müşteri iletişimi ve destek hazırlığı
—
Anahtarı kaldırma koşulu ve sorumlusu
—

Bu şablonu ürün, mühendislik ve destek ekipleri birlikte doldurabilir. İlk görüşmede her alanı kesinleştirmek yerine belirsiz kalan kararları görünür hale getirmek faydalıdır. Yayılım sırasında karar kaydına hangi grubun ne zaman erişim aldığı, hangi gözlemin yapıldığı ve kapsamın neden değiştirildiği eklenir. Bir sorun çıktığında kapatma yetkisine sahip kişinin erişimi ve geri dönüş adımları uygulanabilir olmalıdır. Anahtar kaldırıldığında ise yalnızca ayar paneli değil, ilgili kod, test ve ölçüm kayıtlarının gelecekteki kullanımı da değerlendirilir.

İlgili terimler

Release Planning, Deployment, Continuous Delivery, Canary Release, A/B Testing, Observability, Rollback, Technical Debt, Guardrail Metrics, Product Analytics