Özellik bayrakları: Açmadan önce kapatma planını yazın

Yeni randevu dağıtımını küçük bir müşteri grubunda denemek isteyen ekip, özelliği bir bayrağın arkasına alır. Sorun çıktığında bayrağı kapatır; fakat yeni akışın oluşturduğu randevular eski ekranda görünmez. Açma anahtarı vardır, güvenli dönüş yoktur. Kurgusal servis randevusu örneği üzerinden özellik bayrağının yalnızca görünürlüğü değil, veri ve işletim kararlarını da gerektirdiğini inceleyelim. Bu yöntem her risk için otomatik bir geri alma çözümü değildir.

Bayrağın değiştirdiği tek iş kararını belirleyin

Örnekte bayrak, uygun servis saatlerinin hesaplanmasında yeni dağıtım yönteminin kullanılmasını seçsin. Müşterinin hesabına erişimi veya çalışanın yetkisini seçmesin. Kullanıcı arayüzünden bir düğmeyi gizlemek yetkilendirme kontrolü değildir; ilgili işlem sunucu tarafında kendi erişim kurallarıyla korunmalıdır. Bir bayrağa birbiriyle ilgisiz çok sayıda değişiklik bağlamak, hangi davranışın sonuç ürettiğini anlamayı zorlaştırır. Kapsam kartında etkilenen akışı ve etkilenmemesi gereken işleri birlikte yazın.

Hata durumundaki varsayılanı iş sonucuyla seçin

Bayrak sağlayıcısı cevap vermediğinde ne olacak? Yeni hesaplama kapanıp eski doğrulanmış yönteme mi dönülecek, yoksa işlem kontrollü bir açıklamayla duracak mı? Varsayılanı yalnız true veya false olarak kaydetmeyin; kullanıcının ne göreceğini anlatın. OpenFeature değerlendirme API’si, hata durumlarında çağrıda verilen varsayılan değere dönme davranışını tanımlar. Bu teknik davranışın iş açısından güvenli olması uygulamanın seçimine bağlıdır. Boş randevu sonucu ile sağlayıcı hatası aynı müşteri mesajına dönüşmemelidir.

Hedef grubunu ve ölçüm penceresini sabitleyin

İlk denemeyi açıkça seçilmiş pilot işletmelerle sınırlayabilirsiniz. Aynı işletmenin çalışanları birbiriyle çelişen akışlar görmemeli; gerekiyorsa hedeflemeyi kişi yerine işletme düzeyinde kurun. Hassas müşteri bilgisini sırf hedefleme kolay olsun diye günlük veya bayrak bağlamına taşımayın. Hangi akışın çalıştığını tanımaya yetecek en az bilgiyi kullanın. Ölçüm penceresinde hem yeni hem eski yöntemin randevu oluşturma sonucunu ve açık hata nedenlerini izleyin; trafik artışını tek başına kalite kanıtı saymayın.

Açık ve kapalı yolları aynı veriyle deneyin

Bir test kaydıyla uygun saat bulmayı, randevuyu değiştirmeyi ve iptali iki durumda da çalıştırın. Yeni yöntemle açılan kayıt eski yönteme dönüldüğünde okunabiliyor mu? Süren bir işlem sırasında karar değişirse ne olur? Bayrağı kapatmak veri tabanı değişikliğini, gönderilmiş bildirimi veya dış sisteme açılmış işi kendiliğinden geri almaz. Örnekte yeni randevu alanları eski ekranla uyumlu değilse, açılım öncesinde uyumluluk veya ayrı bir iyileştirme akışı hazırlanmalıdır.

Kapatma kararını kişi ve gözlemle ilişkilendirin

Açılım kartında bir sorumlu, yedek kişi ve durdurma koşulu bulunsun. Örnek koşul, aynı randevunun iki kez oluşmasının doğrulanması olabilir; bu bir başarı eşiği değil, kurgusal risk örneğidir. Karar verecek kişinin gerekli ölçümü nerede göreceğini ve kapatma sonrası hangi kayıtları inceleyeceğini yazın. Sorunun özelliğe bağlı olduğundan emin değilseniz inceleme ile müdahaleyi ayrı kaydedin. Bayrağı kimin, ne zaman ve hangi gerekçeyle değiştirdiği izlenebilir olmalıdır.

Kalıcı hâle gelen bayrağı temizleyin

Pilotun sonunda yalnız açıldı notu bırakmayın. Yeni yöntem kalıcıysa eski dalın ve gereksiz ayarın kaldırılması için iş açın; değilse denemenin neden kapandığını kaydedin. Sahipsiz bayraklar, test edilmesi gereken olası durumları artırabilir. Son kullanım tarihi bir otomatik silme talimatı değil, yeniden değerlendirme hatırlatıcısı olsun. Teslimin tamamlandığını, kalan yapılandırma ve testlerin güncel kod davranışıyla uyumunu kontrol ederek belirleyin. Böylece küçük bir pilot kalıcı belirsizliğe dönüşmez.

Sık sorulan sorular

Bayrağı kapatmak sürümü geri almakla aynı mı?

Hayır. Bayrak belirli bir kod yolunu değiştirir; veri, dış işlemler ve dağıtılmış sürüm için ayrı değerlendirme gerekir.

İlk pilotta herkesi rastgele ayırmalı mıyız?

Şart değil. İş akışının tutarlı kalacağı, açıkça tanımlı bir pilot grubu daha anlaşılır olabilir.

Yetki kontrolünü bayrakla yapabilir miyiz?

Bayrakla görünürlük seçilebilir; erişim yetkisi kendi güvenli kontrolünden geçmelidir.

BiKreatif ile pilot kapsamını belirlerken açılacak özellik kadar hata varsayılanını, kapatma kararını ve kalan veri sorumluluğunu da birlikte tanımlayın.

özel yazılım projeleri hizmetimiz

Kaynak

OpenFeature — Flag Evaluation API — https://openfeature.dev/specification/sections/flag-evaluation/