Bir Özellik Bayrağı ve Dağıtım Yönetim Web Uygulaması Nasıl İnşa Edilir

Ne İnşa Ediyorsunuz ve Neden Önemli

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.

Neden ekipler özellik bayraklarına güveniyor

Ekipler özellik bayraklarını şu yüzden kullanır: riskleri azaltır ve esnekliği artırır:

• Aşamalı yayınlar: değişikliği %1 kullanıcıya açın, sorunları izleyin, sonra genişletin.
• Deneyler: farklı gruplara A vs. B varyantını gösterin ve sonuçları karşılaştırın.
• Acil kapatma (kill switch): bir şey bozulduğunda problemli özelliği anında devre dışı bırakın.

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 rehberle ne inşa edeceksiniz

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:

1. Yönetici paneli: teknik olmayan ekip üyelerinin bayrak oluşturabileceği, hedef kitle tanımlayabileceği ve dağıtımları başlatıp durdurabileceği alan.
2. Arka uç API: bayrak konfigürasyonlarını saklayan, izinleri uygulayan ve uygulamalara bayrak değerleri sunan servis.
3. Hafif değerlendirme yolu (SDK veya basit API çağrısı aracılığıyla): uygulamalar içinde hangi kullanıcıların hangi varyantı gördüğüne karar veren küçük yol.

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.

Gereksinimleri ve Kullanım Senaryolarını Tanımlayın

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.

Kimler kullanacak (ve neye ihtiyaçları var)

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.

Olmazsa olmaz yetenekler

Kademeli dağıtım ve geri alma sağlayan sıkı bir çekirdeğe odaklanın:

• Bayrak oluşturma ve yönetme (aç/kapa, varyantlar, açıklamalar, sahipler)
• Hedefleme kurallarını tanımlama (kimin özelliği aldığı)
• Yüzdelik dağıtımlar (örn. %1 → %10 → %50 → %100)
• Zamanlama (belirli zamanlarda başlat/durdur, zaman dilimi netliği)

Bunlar “güzel eklemeler” değil—bir dağıtım aracını benimseten özelliklerdir.

İyi-olur yetenekler (planlayın, önce engellemeyin)

Bunları şimdi yakalayın ama önce inşa etmeyin:

• Deneyler ve A/B testleri
• Yaygın bayrak tipleri için şablonlar (kill switch, beta erişimi)
• Büyük lansmanlar için toplu düzenlemeler (çok sayıda bayrak, çok ortam)

“Güvenli” ne demek, tanımlayın

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.

Yüksek Seviyeli Mimari (Basit ve Pratik)

Ö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.

Temel bileşenler

Yüksek seviyede, dört yapı taşı istersiniz:

• Yönetici UI (panel): insanların bayrak oluşturduğu, hedefleme kuralları tanımladığı, dağıtımları planladığı ve kill switch’i çevirdiği yer.
• Bayrak API (kontrol düzlemi): panelin bayrakları, ortamları, segmentleri ve onayları okumak/yazmak için kullandığı kimlikli uç noktalar.
• Değerlendirme servisi + SDK’lar (veri düzlemi): uygulamalarınızın “bu kullanıcı için bu bayrak şu anda açık mı?” sorusunu sorduğu parça.
• Veri deposu: bayrak tanımları, kurallar, segmentler ve denetim geçmişini tutar.

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.

Uygulamalar bayrakları nasıl sorgulamalı

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.

Monolit mi, küçük servisler mi

Başlangıç için modüler monolit genelde en pratik olandır:

• Auth/RBAC, Flags, Segments, Audit ve “Publish config” gibi net modüllere sahip tek bir backend uygulama.
• Tek bir veritabanı.
• Tek bir deployable.

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.

Gecikmeyi düşük tutmak: önbellekleme ve yerel değerlendirme

Bayrak kontrolleri sıcak yollar üzerinde gerçekleşir, bu yüzden okumaları optimize edin:

• Snapshot gönderme veya poll: SDK’lar konfigürun yerel önbelleğini N saniyede bir yeniler veya streaming ile günceller.
• Yerel değerlendir: konfigür önbelleğe alındıktan sonra çoğu kontrol işlem içi fonksiyon çağrısına dönüşür.
• Konfig teslimi için CDN/kent kenarı kullanın (istemci tarafı için) ve hızlı bir önbellek (sunucu tarafı için) kullanın ki veritabanınız her istekte sorgulanmasın.

Hedef, panel kapalıyken bile uygulamaların son bilinen iyi konfigürasyonu kullanarak tutarlı davranmasıdır.

Bayraklar, Segmentler ve Ortamlar için Veri Modeli

Ö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.

Temel varlıklar

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.

Kurallar, öncelikler ve yedekler

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.

Versiyonlama: taslak vs yayınlanmış

Her değişikliği bir FlagRevision olarak ele alın:

• status: draft veya published
• created_by, created_at, opsiyonel comment

Yayı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 geçmişi ve geri alma

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ştirdi
• before/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 ve Segmentasyon Kuralları

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.

Neyi hedefleyebilirsiniz (kullanıcı öznitelikleri)

Her değerlendirmeyle uygulamalarınızın güvenilir şekilde gönderebileceği küçük, tutarlı bir öznitelik setiyle başlayın:

• Role: admin, staff, member (dahili-öncelikli yayınlar için ideal)
• Plan: free, pro, enterprise (paraya dayalı özellikler için kullanışlı)
• Region: ülke/pazar veya veri ikamet bölgesi
• App version: eski istemcilere özelliği açmamak için

Ö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: kaydedilmiş gruplar

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:

• Kural tabanlı segmentler: “plan = enterprise AND role = admin”
• Açık izin/engelleme listeleri (opsiyonel): “VIP müşteriler” veya destek yönlendirmeli dağıtımlar için kullanışlı

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.

Kural mantığı ve öncelik

Sonuçların panoda açıklanabilir olmasını sağlamak için net bir değerlendirme sırası tanımlayın:

1. Sert geçersiz kılmalar (örn. deny/allow listesi)
2. Hedefleme kuralları (öncelik sırasına göre, ilk eşleşen)
3. Fall-through (varsayılan kapalı veya bir dağıtıma varsayılan)

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).

Gizlilik notu

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ım Stratejileri: Yüzdeler, Varyantlar, Zamanlama, Kill Switch

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ımlar (ve neden tutarlı kümeleme önemlidir)

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:

• Kullanıcı bazlı dağıtımlar tüketici uygulamaları için iyidir.
• Hesap/kiracı bazlı dağıtımlar aynı şirketteki farklı kullanıcıların çelişen davranışlar görmesini önler.

Varyantlar: boolean ve çoklu varyant

İ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: başlangıç/bitiş zamanları, ramp adımları ve zaman dilimleri

Zamanlama ekiplerin bir anahtarı çevirme için uyanık kalmasını gerektirmeden koordinasyon yapmasını sağlar. Destekleyin:

• Başlangıç zamanı / bitiş zamanı (süre dolduğunda otomatik devre dışı)
• Ramp adımları (örn. %1 → %10 → %25 → %50 belirli aralıklarla)
• Zaman dilimleri (zamanları UTC olarak saklayın, ama kullanıcı tercihine göre gösterin/düzenleyin)

Zamanlamaları bayrak konfigürasyonunun parçası olarak ele alın ki değişiklikler denetlenebilir ve canlıya almadan önce önizlenebilir olsun.

Kill switch davranışı (kesintiler dahil)

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:

• Bayrak servisine ulaşılamazsa, SDK’lar son bilinen iyi konfigürasyona (cached) geri dönmeli, sonra güvenli bir varsayılan kullanmalı.
• Riskli özellikler için varsayılanların "kapalı" (fail closed) olması tercih edilir.

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.

Uygulamalarınız için API’ler ve SDK Entegrasyonu

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.

Okuma API’leri (hızlı, önbellek-dostu)

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 getir
• GET /api/v1/environments/{env}/bootstrap — yerel değerlendirme için gerekli bayraklar + segmentleri getir

Yanı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 API’leri (doğrulamalı, iş akışına duyarlı)

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 ettir
• POST /api/v1/flags/{id}/rollback — son bilinen iyi versiyona geri al

Dashboard’un neyi düzeltmesi gerektiğini açıklayabilmesi için net doğrulama hataları döndürün.

SDK sorumlulukları (sıradan yapı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ı.

İstemci tahrifini önleme

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.

Yönetici Paneli UX (Teknik Olmayan Kullanıcı Dostu)

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.

Bayrak listesi: doğru şeyi hızlı bulun

Basit bir bayrak listesi görünümüyle başlayın ve şunları destekleyin:

• İsim, anahtar, sahip veya etiketle arama
• Duruma göre filtreler (açık/kapalı), tür (boolean/çoklu) ve “son değiştirilen”
• Çıkıntılı bir ortam seçici (Dev / Staging / Prod) ki fark edilmesi zor olmasın

“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.

Bayrak düzenleyici: kullanıcıları güvenli değişikliklere yönlendirin

Düzenleyici rehberli bir form gibi hissettirmeli, teknik bir konfigürasyon ekranı gibi değil.

Şunları dahil edin:

• Düz dilde maddelerle bir kural oluşturucu (örn. “Ülke US ise” VE “Plan Pro ise”)
• Ne olacağını açıklayan bir dağıtım kaydırıcısı (0–100%)
• Mevcut kurallarla eşleşecek örnek kullanıcıları gösteren bir önizleme paneli (veya “Bu kullanıcı neden eşleşiyor” açıklaması)

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.

Toplu işlemler ama yanlış toplu hatalara karşı koruma

Ekipler toplu etkinleştirme/devre dışı bırakma ve “kuralları başka bir ortama kopyala” ihtiyaçlarına sahip olacak. Koruyucu önlemler ekleyin:

• Etkiyi özetleyen onaylar (“Bu işlem Production’da 12 bayrağı etkinleştirecek”)
• Kopyalama işlemleri için kuru çalıştırma (dry-run) önizlemeleri
• Mümkünse açık geri alma rehberliği

Güçlü yolu kolay yol yapın

Ü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.