Özellik bayrakları oluşturmak, hedefleme yapmak, kademeli dağıtımlar yürütmek, acil kapatma eklemek ve değişiklikleri güvenle izlemek için web uygulaması tasarlamayı ve inşa etmeyi öğrenin.
Bir özellik bayrağı (feature toggle) kodu tekrar dağıtmadan bir ürün yeteneğini açıp kapamanıza izin veren basit bir kontroldür. Bir sürümü bir deploy’a bağlamak yerine “kod dağıtıldı” ile “kod aktif” arasını ayırırsınız. Bu küçük değişiklik, ne kadar güvenli—ve ne kadar hızlı—yayın yapabileceğinizi değiştirir.
Ekipler özellik bayraklarını şu yüzden kullanır: riskleri azaltır ve esnekliği artırır:
Operasyonel değer basittir: özellik bayrakları gerçek dünya davranışına—hatalar, performans gerilemeleri veya olumsuz kullanıcı geri bildirimi—hızlı, kontrollü bir şekilde yanıt vermenizi sağlar, tümü tam bir yeniden dağıtım döngüsünü beklemeden.
Bu rehber sizi üç temel parçaya sahip pratik bir özellik bayrağı ve dağıtım yönetimi web uygulaması inşa etmeye götürecek:
Amaç, devasa bir kurumsal platform değil; ürün ekibinin önüne koyup prodüksiyonda güvenebileceğiniz, anlaşılır ve bakım yapılabilir bir sistemdir.
Hızlı prototipleme istiyorsanız, bir vibe-coding iş akışı yardımcı olabilir. Örneğin, ekipler genellikle Koder.ai kullanarak yapılandırılmış bir sohbet spesifikasyonundan React panosu ve Go/PostgreSQL API’nin ilk çalışan sürümünü üretir, sonra kural motoru, RBAC ve denetim gereksinimlerini planlama modunda yineleyip kaynak kodunu dışa aktarır.
Ekranları tasarlamadan veya kod yazmadan önce sistemin kimin için olduğunu ve “başarı”nın neye benzediğini netleştirin. Özellik bayrağı araçları genellikle kural motoru yanlış olduğu için değil, iş akışının ekiplerin nasıl yayın yaptığına uymadığı için başarısız olur.
Mühendisler hızlı, öngörülebilir kontroller ister: bir bayrak oluştur, hedefleme kuralları ekle ve yeniden deploy etmeden yayınla. Ürün yöneticileri kademeli ve planlanmış sürümlere güvenmek ister; kimlerin etkilendiğine net görünürlük isterler. Destek ve operasyonlar ise bir olaya hızlıca müdahale edebilecek güvenli bir yol ister—tercihen mühendisleri çağırmadan—riskli bir özelliği çabucak devre dışı bırakabilmek.
İyi bir gereksinimler dokümanı bu rolleri ve hangi eylemleri gerçekleştirebileceklerini (ve gerçekleştiremeyeceklerini) açıkça adlandırır.
Kademeli dağıtım ve geri alma sağlayan sıkı bir çekirdeğe odaklanın:
Bunlar “güzel eklemeler” değil—bir dağıtım aracını benimseten özelliklerdir.
Bunları şimdi yakalayın ama önce inşa etmeyin:
Güvenlik gereksinimlerini açık kurallar olarak yazın. Yaygın örnekler: üretim değişiklikleri için onaylar, tam denetlenebilirlik (kim neyi, ne zaman ve neden değiştirdi), ve bir olay sırasında bile erişilebilir hızlı geri alma yolu. Bu “güvenli tanımı” izinler, UI sürtünmesi ve değişiklik geçmişi hakkında sonraki kararları yönlendirecektir.
Özellik bayrağı sistemini “bayrakları yönetmek” ile “değerlendirmeleri sunmak” olarak ayırdığınızda en kolay anlaşılır hale gelir. Böylece yönetici deneyimi hoş ve güvenli olabilirken uygulamalar hızlı, güvenilir yanıtlar alır.
Yüksek seviyede, dört yapı taşı istersiniz:
Basit bir zihinsel model: panel bayrak tanımlarını günceller; uygulamalar hızlı değerlendirme için bu tanımların derlenmiş anlık görüntüsünü tüketir.
Genelde iki deseniniz olur:
Sunucu tarafı değerlendirme (çoğu bayrak için önerilen). Backend, SDK/değerlendirme katmanına bir kullanıcı/kontekst objesi verip ne yapılacağına karar verir. Bu, kuralları ve hassas öznitelikleri istemci tarafında tutmamak için iyidir ve tutarlı davranışı uygulamayı kolaylaştırır.
İstemci tarafı değerlendirme (seçerek kullanın). Web/mobil istemci, yalnızca istemcinin bilmesine izin verilen ön-filtrelenmiş, imzalı bir konfigürasyon alıp yerel olarak değerlendirir. Bu backend yükünü azaltıp UI duyarlılığını artırabilir, ancak daha sıkı veri hijyeni gerektirir.
Başlangıç için modüler monolit genelde en pratik olandır:
Kullanım arttıkça ilk bölünen genellikle değerlendirme yolu (okuma-ağır) ile yönetici yolu (yazma-ağır) olur. Aynı veri modelini koruyarak daha sonra özel bir değerlendirme servisi ekleyebilirsiniz.
Bayrak kontrolleri sıcak yollar üzerinde gerçekleşir, bu yüzden okumaları optimize edin:
Hedef, panel kapalıyken bile uygulamaların son bilinen iyi konfigürasyonu kullanarak tutarlı davranmasıdır.
Özellik bayrağı sistemi, veri modeline bağlı olarak başarılı olur veya başarısız olur. Çok gevşekse değişiklikleri denetleyemez veya güvenli geri alma yapamazsınız; çok katıysa ekipler kullanmaktan kaçınır. Açık varsayılanları, öngörülebilir hedeflemeyi ve güvenilir bir geçmişi destekleyen bir yapı hedefleyin.
Flag (Bayrak) ürün düzeyinde ana anahtardır. Zaman içinde istikrarlı tutmak için verin:
key (benzersiz, SDK’lar tarafından kullanılır, ör. new_checkout)name ve description (insanlar için)type (boolean, string, number, JSON)archived_at (soft delete)Variant (Varyant) bir bayrağın döndürebileceği değeri temsil eder. Boolean bayraklar bile açık/kapalı varyantlarıyla standartlaştırma ve raporlama sağlar.
Environment (Ortam) davranışı bağlama göre ayırır: dev, staging, prod. Bir bayrağın her ortam için farklı kurallar ve varsayılanları olmasını açıkça modelleyin.
Segment kaydedilmiş grup tanımıdır (örn. “Beta testerlar”, “İç kullanıcılar”, “Yüksek harcama yapanlar”). Segmentler birçok bayrakta yeniden kullanılabilmelidir.
Karmaşıklığın çoğu kurallardadır; bunları birinci sınıf kayıtlar yapın.
Pratik bir yaklaşım:
FlagConfig (her bayrak + ortam için) default_variant_id, enabled durumu ve mevcut yayınlanmış revizyona işaretçi saklar.Rule bir revizyona aittir ve şunları içerir:
priority (daha düşük sayı kazanır)conditions (öznitelik karşılaştırmaları gibi JSON dizi)serve (sabit varyant veya varyantlar arasında yüzde dağılım)fallback her zaman FlagConfig içindeki default_variant_id olur.Değerlendirme basittir: yayınlanmış revizyonu yükle, kuralları önceliğe göre sırala, ilk eşleşeni uygula; yoksa default.
Her değişikliği bir FlagRevision olarak ele alın:
status: draft veya publishedcreated_by, created_at, opsiyonel commentYayınlama atomik bir eylemdir: FlagConfig.published_revision_id ortam başına seçilen revizyona ayarlanır. Taslaklar ekiplerin değişiklikleri kullanıcıları etkilemeden hazırlamasına izin verir.
Denetim ve geri almalar için eklemeli (append-only) bir değişiklik günlüğü saklayın:
AuditEvent: kim neyi, ne zaman, hangi ortamda değiştirdibefore/after snapshot’ları (veya revizyon ID’lerini referanslayan JSON patch)Geri alma, ayarları manuel yeniden oluşturmak yerine “daha eski bir revizyonu yeniden yayımla” olur. Bu daha hızlı, daha güvenli ve panonun geçmiş görünümünde teknik olmayan paydaşlara kolayca açıklanabilir.
Hedefleme, "kimin neyi aldığı" kısmıdır. İyi yapıldığında güvenli yayın yapmanızı sağlar: önce dahili kullanıcılara, sonra belirli müşteri katmanına, sonra bir bölgeye açabilirsiniz—redeploy olmadan.
Her değerlendirmeyle uygulamalarınızın güvenilir şekilde gönderebileceği küçük, tutarlı bir öznitelik setiyle başlayın:
Öznitelikleri sıkıcı ve tahmin edilebilir tutun. Bir uygulama plan=Pro, diğeri plan=pro gönderirse kurallarınız beklenmedik davranır.
Segmentler “Beta testerlar”, “AB müşterileri” veya “Tüm enterprise adminleri” gibi yeniden kullanılabilir gruplardır. Bunları statik listeler değil, kaydedilmiş tanımlar olarak uygulayın ki üyelik gerektiğinde hesaplanabilsin:
Değerlendirmeyi hızlı tutmak için segment üyeliği sonuçlarını kısa süre (saniyeler/dakikalar) önbelleğe alın, ortam ve kullanıcı bazlı anahtarlayın.
Sonuçların panoda açıklanabilir olmasını sağlamak için net bir değerlendirme sırası tanımlayın:
AND/OR gruplarını ve yaygın operatörleri destekleyin: equals, not equals, contains, in list, greater/less than (sürüm veya sayısal öznitelikler için).
Kişisel veriyi en aza indirgeyin. Mümkünse stabil, PII olmayan tanımlayıcıları tercih edin (ör. dahili kullanıcı ID’si). İzin/engelleme listeleri için kimlikleri saklamanız gerekiyorsa hashlenmiş ID’ler kullanın ve e-posta, isim veya ham IP adreslerini bayrak sistemine kopyalamaktan kaçının.
Dağıtımlar bir özellik bayrağı sisteminin gerçek değerini gösterdiği yerdir: değişiklikleri kademeli açabilir, seçenekleri karşılaştırabilir ve sorunları durdurabilirsiniz—redeploy etmeye gerek kalmadan.
Yüzdelik dağıtım “%5 kullanıcıya etkinleştir” demektir; sonra güven arttıkça artırırsınız. Anahtar detay tutarlı kümelemedir: aynı kullanıcı oturumlar arasında güvenilir şekilde içeride (veya dışarıda) kalmalıdır.
Örneğin 0–99 arası bir bucket atamak için stabil bir tanımlayıcı (user_id veya account_id) deterministik hash’ini kullanın. Her istekte rastgele seçim yaparsanız kullanıcılar deneyler arasında “flip” yapar, metrikler gürültülü olur ve destek ekipleri sorunları yeniden üretemez.
Ayrıca kümeleme birimini kasıtlı seçin:
İlk olarak boolean bayraklarla başlayın, ama çoklu varyantlar (control, new-checkout-a, new-checkout-b) için plan yapın. Çoklu varyantlar A/B testleri, metin denemeleri ve kademeli UX değişiklikleri için gereklidir.
Kurallar her zaman bir değerlendirmede tek bir çözülmüş değer döndürmeli; açık bir öncelik sırası olmalı (örn. açık geçersiz kılma > segment kuralları > yüzdelik dağıtım > default).
Zamanlama ekiplerin bir anahtarı çevirme için uyanık kalmasını gerektirmeden koordinasyon yapmasını sağlar. Destekleyin:
Zamanlamaları bayrak konfigürasyonunun parçası olarak ele alın ki değişiklikler denetlenebilir ve canlıya almadan önce önizlenebilir olsun.
Kill switch, her şeyi geçersiz kılan acil bir “zorla kapat”tır. Bunu birinci sınıf kontrol olarak yapın; UI ve API’de en hızlı yolu sağlayın.
Kesintiler sırasında ne olacağını kararlaştırın:
Bu davranışı açıkça belgeleyin ki ekipler bayrak sistemi bozulduğunda uygulamanın ne yapacağını bilsin. Daha fazla günlük kullanım ayrıntısı için ayrıca bkz. /blog/testing-deployment-and-governance.
Web uygulamanız sistemin yalnızca yarısıdır. Diğer yarı, ürün kodunuzun bayrakları güvenli ve hızlı okuma şeklidir. Temiz bir API ve her platform için küçük bir SDK (Node, Python, mobil vb.) entegrasyonu tutarlı kılar ve her ekibin kendi yaklaşımını icat etmesini engeller.
Uygulamalarınız yazma uçlarına göre çok daha fazla okuma uç noktasını çağırır; bu yüzden önce bunları optimize edin.
Yaygın desenler:
GET /api/v1/environments/{env}/flags — bir ortam için tüm bayrakların listesi (çoğunlukla sadece “etkin” olanlar filtrelenir)GET /api/v1/environments/{env}/flags/{key} — bir bayrağı anahtarla getirGET /api/v1/environments/{env}/bootstrap — yerel değerlendirme için gerekli bayraklar + segmentleri getirYanıtları ETag veya updated_at sürümü gibi mekanizmalarla önbellek-dostu yapın ve payload’ları küçük tutun. Birçok ekip aynı zamanda toplu fetch için ?keys=a,b,c desteği sağlar.
Yazma uç noktaları katı ve öngörülebilir olmalı:
POST /api/v1/flags — oluştur (anahtar benzersizliğini, adlandırma kurallarını doğrula)PUT /api/v1/flags/{id} — taslak konfigürasyonu güncelle (şema doğrulaması)POST /api/v1/flags/{id}/publish — taslağı bir ortama terfi ettirPOST /api/v1/flags/{id}/rollback — son bilinen iyi versiyona geri alDashboard’un neyi düzeltmesi gerektiğini açıklayabilmesi için net doğrulama hataları döndürün.
SDK’nız önbellekleme TTL’si, retry/backoff, zaman aşımı ve çevrimdışı fallback (son önbelleklenen değerleri sun) gibi görevleri halletmeli. Ayrıca ekiplerin veri modelinizi anlamasına gerek kalmadan tek bir “evaluate” çağrısı sunmalı.
Bayraklar fiyatlandırma, haklar veya güvenlikle ilgili davranışları etkiliyorsa tarayıcı/mobil istemcisine güvenmeyin. Sunucu tarafı değerlendirmeyi tercih edin veya istemciye okunabilen ama taklit edilemeyen imzalı bir “bayrak snapshot”u sunun.
Bir özellik bayrağı sistemi, ekiplerin onu gerçek yayınlarda kullanmaya güvenmesiyle çalışır. Yönetici paneli bu güveni inşa eder: net etiketler, güvenli varsayılanlar ve gözden geçirilmesi kolay değişiklikler.
Basit bir bayrak listesi görünümüyle başlayın ve şunları destekleyin:
“Güncel durum”u bir bakışta okunur yapın. Örneğin %10 için Açık, Hedefleme: Beta segmenti veya Kapalı (kill switch etkin) gibi ifadeler gösterin; sadece yeşil nokta değil.
Düzenleyici rehberli bir form gibi hissettirmeli, teknik bir konfigürasyon ekranı gibi değil.
Şunları dahil edin:
Varyantları destekliyorsanız bunları insan-dostu seçenekler olarak gösterin (“Yeni ödeme akışı”, “Eski ödeme akışı”) ve trafiğin doğru toplandığını doğrulayın.
Ekipler toplu etkinleştirme/devre dışı bırakma ve “kuralları başka bir ortama kopyala” ihtiyaçlarına sahip olacak. Koruyucu önlemler ekleyin:
Üretim düzenlemeleri, büyük yüzde sıçramaları, kill switch tetiklemeleri gibi riskli eylemler için uyarılar ve zorunlu notlar kullanın. Kaydetmeden önce ne değiştiğini—nerede ve kimden—gösteren bir değişiklik özeti gösterin ki teknik olmayan onaylayıcılar da güvenle onaylayabilsin.
Bir özellik bayrağı (feature toggle), bir yeteneği yeni kod dağıtmadan çalışma zamanında açıp/kapatmaya yarayan bir kontroldür. "Kodu dağıtmak" ile "davranışı etkinleştirmek" arasındaki ayrımı sağlar; bu da güvenli kademeli dağıtımlara, hızlı geri almalara ve kontrollü deneylere olanak tanır.
Pratik bir kurulum şu iki parçaya ayrılır:
Bu ayrım, “değişiklik iş akışını” güvenli ve denetlenebilir kılarken değerlendirmelerin düşük gecikmeli olmasını sağlar.
Tutarlı kümeleme (consistent bucketing) kullanın: stabil bir tanımlayıcıdan (ör. user_id veya account_id) deterministik bir hash hesaplayın, 0–99 arası bir bucket’a eşleyin ve dağıtım yüzdesine göre dahil/haric edin.
Her istekte rastgele seçim yapmaktan kaçının; aksi halde kullanıcılar deneyler arasında "flip" yapar, metrikler gürültülü olur ve destek sorunları tekrarlanamaz hale gelir.
Başlangıç için önerilen model:
Davranışın açıklanabilir olması için açık bir öncelik sırası tanımlayın:
Ayrıca öznitelik setini küçük ve tutarlı tutun (ör. role, plan, region, app version) ki servisler arası kural sürüklenmesi olmasın.
Ortam-spesifik bayrak konfigürasyonunun parçası olarak zamanlamayı saklayın:
Zamanlanmış değişiklikleri denetlenebilir ve önizlenebilir yapın ki ekipler yayına almadan önce ne olacağını teyit edebilsin.
Okuma-ağır kullanım için optimize edin:
Bu, her bayrak kontrolü için veritabanının sorgulanmasını engeller.
Fiyatlandırma, yetkilendirme veya güvenlikle ilgili davranışlar etkileniyorsa sunucu tarafı değerlendirmeyi tercih edin; istemciler kuralları veya öznitelikleri taklit edemesin.
İstemci tarafında değerlendirme gerekiyorsa:
RBAC + ortam düzeyinde erişim kapsamı kullanın:
Prod için hedefleme/dağıtım/kill switch gibi yüksek etkili değişikliklerde onay akışı isteğe bağlı olarak ekleyin; isteği yapan, onaylayan ve yapılan değişikliği her seferinde kaydedin.
En azından aşağıdakileri yakalayın:
Kesintilerde: SDK’lar son bilinen iyi konfigürasyona düşmeli, yoksa güvenli varsayılan (riskli özellikler için genellikle "kapalı") kullanılmalı. Ayrıca bkz. /blog/auditing-monitoring-alerts ve /blog/testing-deployment-and-governance.
key, tür, isim/açıklama, arşivlenme/soft-delete.on/off gibi).\n- Ortamlar: dev/staging/prod ile ayrı konfigürasyonlar.\n- Segmentler: yeniden kullanılabilir grup tanımları.\n- Kurallar + öncelik + fallback: ilk eşleşen kural uygulanır, aksi halde default.Ayrıca revizyonlar (taslak vs yayınlanmış) ekleyin; yayınlama atomik bir pointer değişikliği olsun ve geri alma "eski bir revizyonu yeniden yayımla" şeklinde yapılsın.