Feature Flag: necə işləyir, flag növləri və idarəetmə prinsipləri
Feature Flag — proqram işlənmə texnikasıdır ki, burada tətbiqin funksionallığı şərti açarlar vasitəsilə iş vaxtı aktivləşdirilir və ya söndürülür, yeni kod yerləşdirmədən. Ənənəvi “tövsiyə et — deploy et” yanaşması əvəzinə, feature flag-lar deploy anını funksionallığın aktivləşdirilməsi anından ayırmağa imkan verir. LaunchDarkly (2024) məlumatlarına görə, feature flag-lardan istifadə edən komandalar yeni funksiyaların təqdimatını 40% sürətləndirir. Feature flag-lar müasir mobil və veb tətbiqlər üçün CI/CD-nin məcburi elementinə çevrilmişdir.
Başlıca
- Feature Flag — iş vaxtı funksionallığın əlçatanlığını idarə edən şərti açar
- Dörd növ flag: release, experiment, ops və permission toggles müxtəlif məqsədlər və həyat dövrü ilə
- Flag-ların idarəsi saxlama sistemi, konfiqurasiya üçün interfeys və istifadə monitorinqi tələb edir
- Platformalar LaunchDarkly, Unleash və Split bütün populyar dillər və platformalar üçün SDK təmin edir
- Texniki borc təmizlənməmiş flag-lardan — əsas risk: stale flag-lar mütəmadi audit və silinmə tələb edir
Feature Flag nədir
Feature Flag (xüsusiyyət flag-ı, feature toggle) — kod dəyişdirmədən tətbiqin davranışını dəyişməyə imkan veren mexanizmdir. Ən sadə formada bu, yeni funksionallığı yerinə yetirməzdən əvvəl flag dəyərini yoxlayan şərti konstruksiyadır. Flag konfiqurasiya faylında, verilənlər bazasında və ya xarici xidmətdə saxlanıla və real vaxtda dəyişdirilə bilər. Bu yanaşma komandalara yarımçıq kodu əsas qola tövsiyə etməyə imkan verir, işlənmə tamamlanana qədər istifadəçilərə çatmayacağından qorxmadan.
Tərif və məqsəd
Feature flag-ların əsas məqsədi deploy və release-in ayrılmasıdır. Deploy — kodu serverdə və ya tətbiq mağazasında yerləşdirmə prosesidir. Release — funksionallığın istifadəçiyə əlçatan olduğu andır. Feature flag-lar olmadan bu hadisələr üst-üstə düşür: kod produksiyaya çıxır — istifadəçilər onu görür. Feature flag-lar ilə kod produksiyaya release-dən həftələr əvvəl yerləşdirilə, daxili test üçün aktivləşdirilə və ya tədricən auditoriyaya açıla bilər. Bu, trunk-based development və continuous delivery üçün kritik əhəmiyyət daşıyır.
Sadə flag nümunəsi
Kotlin mobil tətbiqində feature flag-ın əsas tətbiqini nəzərdən keçirək. Flag Firebase Remote Config-də saxlanılır və tətbiq işə düşərkən yüklənir. Flag dəyərindən asılı olaraq köhnə və ya yeni profil ekranı göstərilir. Bu tətbiq profilin yeni versiyasını App Store-da yenilənmə dərc etmədən buraxmağa imkan verir — sadəcə Firebase konsolunda dəyəri dəyişmək kifayətdir.
kotlin
class ProfileFeature {
private val flags = FeatureFlagProvider()
private val profileFlag = FlagKey("new_profile_enabled")
fun getProfileScreen(): Screen {
return if (flags.isEnabled(profileFlag)) {
NewProfileScreen()
} else {
LegacyProfileScreen()
}
}
}
class FeatureFlagProvider {
fun isEnabled(key: FlagKey): Boolean {
val raw = Firebase.remoteConfig.getString(key.name)
return raw.toBoolean()
}
}Feature flag növləri
Bütün feature flag-lar eyni deyil. Martin Fowler öz təsnifatında dörd növ flag ayırır ki, onlar istifadə məqsədi, həyat müddəti və idarəetmə tələblərinə görə fərqlənir. Flag-ların düzgün təsnifatı uyğun infrastruktur seçməyə və tipik problemlərdən qaçmağa kömək edir.
Release toggles
Release toggles — ən geniş yayılmış flag növüdür. Onlar produksiya mühitində yarımçıq funksionallığı gizlətmək üçün istifadə olunur. Proqramçı flag ilə örtülmüş kodu əsas qola tövsiyə edir və tədricən funksionallığı tamamlayır. Tamamlanma və testdən sonra flag bütün istifadəçilər üçün aktivləşdirilir. Belə bir flagın həyat dövrü bir neçə gündən iki həftəyə qədərdir. Tam tətbiqdən sonra flag koddan silinir. Release toggles trunk-based development-in əsasıdır.
Experiment və Ops toggles
Experiment toggles A/B testləri ilə birlikdə işləyir. Onlar sadəcə funksionallığı aktivləşdirib söndürmür, həm də istifadəçini eksperimental qruplardan birinə yönləndirir. Belə flag-lar tez-tez mürəkkəb hədəfləmə qaydalarını (region, OS versiyası, abunə üzrə) və analitika sistemləri ilə inteqrasiyanı dəstəkləyir. Ops toggles operativ nəzarət üçün istifadə olunur — məsələn, yüksək yük zamanı ağır funksiyanı söndürmək və ya problemli modulu dərhal deploy etmədən müvəqqəti olaraq söndürmək. Ops toggles maksimum sürətli və etibarlı olmalıdır, çünki xidmətin sabitliyi onlardan asılıdır.
| Növ | Müddət | Dinamika | Məqsəd |
|---|---|---|---|
| Release | Günlər-həftələr | Sabit | Yarımçıq kodu gizlətmək |
| Experiment | Günlər-aylar | Dinamik | A/B testləri və tətbiq |
| Ops | Saatlar-günlər | Dinamik | Operativ nəzarət |
| Permission | Aylar+ | Statik | Giriş fərqləndirməsi |
Feature flag-ların idarəsi
Feature flag-ların idarəsi flag-ların saxlanması, konfiqurasiyası, monitorinqi və auditini əhatə edən ayrıca bir intizamdır. İdarəetmə sistemi olmadan flag-lar nəzarətsiz texniki borca çevrilir və inkişafı ləngidir. İstehsal sistemindən nümunə ilə idarəetmənin əsas aspektlərini nəzərdən keçirək.
Flag həyat dövrü
Hər bir feature flag dörd mərhələdən keçir: yaradılma, istifadə, stabilləşmə və silinmə. Yaradılma mərhələsində flag açarı, növü və default dəyər müəyyən edilir. İstifadə zamanı komanda flag-ı kimin, hansı auditoriya üçün və hansı məqsədlə aktivləşdirdiyini izləyir. Stabilləşmədən sonra (funksionallıq tam hazır və test olunub) flag koddan silinməlidir. Silinmə prosesi kod icmalı vasitəsilə avtomatlaşdırılır: CI, 100% istifadəçi üçün aktiv olan bütün flag-ların silinmə tapşırığının olduğunu yoxlayır.
Mərkəzləşmiş saxlama
Feature flag-lar mərkəzləşmiş şəkildə saxlanmalı, hər xidmətin konfiqurasiya fayllarına səpələnməməlidir. İdeal — interfeysi olan ayrıca xidmət (LaunchDarkly, Unleash). Minimal qəbuledilən variant — dəyişikliklərə kod icmalı ilə repozitoridə JSON konfiq. Flag saxlamaq üçün verilənlər bazası daha az üstünlük təşkil edir, çünki əlavə idarəetmə interfeysi tələb edir. Hər flag-ın sahibi (komanda və ya konkret proqramçı), təsviri və istifadə müddəti olmalıdır. Müddəti keçmiş flag-ların mütəmadi auditi məcburi təcrübədir, CI tapşırığı vasitəsilə avtomatlaşdırılır: N gündən çox dəyişməyən flag-ları yoxlayır.
Feature flag-lar üçün alətlər
Feature flag idarəetmə alətləri bazarı həm kommersiya platformalarını tam idarəetmə dövrü ilə, həm də müstəqil yerləşdirmə üçün açıq mənbəli həlləri əhatə edir. Alətin seçimi komandanın miqyasından, gecikmə tələblərindən və uyğunluq tələblərindən asılıdır.
Kommersiya platformaları
LaunchDarkly — bütün populyar dillər və platformalar (iOS, Android, Web, Backend) üçün SDK ilə bazar lideridir. Çox mühitli, qayda əsaslı hədəfləmə, A/B eksperimentlər və avtomatik flag silməni dəstəkləyir. Split — korporativ funksiyalara fokuslanan alternativ: rol əsaslı giriş, audit jurnalları və uyğunluq (SOC2, HIPAA). ConfigCat — kiçik komandalar üçün uyğun olan daha yüngül və əlçatan həll. Bütün platformalar dəyərləri keşləyən və tətbiqin gecikməsinə minimal təsir göstərən SDK təmin edir.
Açıq mənbəli həllər
Unleash — interfeysi, API və bütün əsas platformalar üçün SDK ilə ən populyar açıq mənbəli həll. Aktivləşdirmə strategiyalarını, fərdi kontekstlər və monitorinq üçün Prometheus ilə inteqrasiyanı dəstəkləyir. Flagsmith — daxili A/B testi və mühit idarəsi ilə alternativdir. Açıq mənbəli həllər infrastrukturun yerləşdirilməsi və dəstəklənməsini tələb edir, lakin məlumatlar üzərində tam nəzarət verir və lisenziya məhdudiyyətləri yoxdur. Mobil tətbiqlər üçün hər iki həll flag dəyərlərinin oflayn keşlənməsi ilə native SDK təmin edir.
Best practices
Feature flag-lar güclü alətdir, lakin intizam olmadan texniki borc yaradır və kodu mürəkkəbləşdirir. Martin Fowler və LaunchDarkly mühəndisləri feature flag-lardan maksimum fayda ələ etməyə və mənfi nəticələrdən qaçmağa kömək edən təcrübələr toplusunu formalaşdırmışdır. İstehsal sistemləri üçün əsas tövsiyələri nəzərdən keçirək.
Texniki borcdan qaçınma
Tətbiqdən sonra silinməyən hər bir feature flag texniki borca çevrilir. LaunchDarkly (2024) araşdırması göstərdi ki, orta hesabla 30–40% flag ehtiyac qalmadıqdan sonra kodda qalır. Həll: “bir flag — bir tapşırıq” qaydasını tətbiq edin. Flag yaratdıqda tapşırıq izləyicisində silinmə tapşırığı yaradılır. CI, 100% aktiv olan flag-ların 30 gündən çox qalmadığını yoxlayır. Kod icmalı yalnız flag əlavə edilməsini deyil, həm də silinməsini yoxlamalıdır.
Flag-larla test etmə
Feature flag-lar test üçün kombinator mürəkkəblik yaradır: hər flag tətbiqin mümkün vəziyyətlərinin sayını iki qat artırır. Bu mürəkkəbliyi idarə etmək üçün bütün flag kombinasiyalarını yoxlayan matris testləri və feature flag keçid inteqrasiya testləri istifadə olunur. CI pipeline-da flag-ların müxtəlif kombinasiyaları ilə testləri işlədən addım əlavə edilir. Kritik flag-lar (ops toggles) üçün yük testləri məcburidir ki, flag keçidinin gecikmə artımına və ya xətalara səbəb olmadığını yoxlasın.
python
class FeatureFlagService:
def __init__(self, storage):
self.storage = storage
def is_enabled(self, flag_key, user_context):
flag = self.storage.get(flag_key)
if not flag:
return False
for rule in flag["rules"]:
if self._match_rule(rule, user_context):
return rule["value"]
return flag["default"]
def _match_rule(self, rule, context):
return (
rule["percentage"] > self._hash(context.user_id)
)Tez-tez verilən suallar
Feature flag feature toggle-dan nə ilə fərqlənir?
Terminlər tez-tez sinonim kimi istifadə olunur, lakin fərq var: feature flag adətən mərkəzləşmiş idarəetmə, interfeys və SDK ilə daha yetkin sistemi bildirir, feature toggle isə kodda sadə binar açardır. Martin Fowler feature toggle-ı ümumi termin kimi istifadə edir, lakin sənayedə feature flag daha çox kommersiya platformaları ilə (LaunchDarkly, Split) ələqələndirilir.
Feature flag-lar performansa necə təsir edir?
Düzgün tətbiqdə performansa təsir minimaldır. Ən yaxşı təcrübələr: flag dəyərlərini 30–60 saniyə TTL ilə yaddaşda keşləmək, flag yoxlanılarkən sinxron HTTP çağırışlarından qaçmaq, yerli keş və fon sinxronizasiyası ilə SDK istifadə etmək. LaunchDarkly məlumatlarına görə, onların SDK-sının p99 gecikməsi 5 ms-dən azdır ki, bu da əksər tətbiqlər üçün əhəmiyyətsizdir.
Feature flag-lardan nə zaman istifadə etməməli?
Feature flag-lar biznes məntiqini dəyişdirmək üçün kritik maliyyə əməliyyatlarında tövsiyə edilmir, burada hansı kodun işlədiyini dəqiq bilmək vacibdir. Təhlükəsizlik funksiyaları (avtorizasiya, şifrələmə) üçün də flag-lardan qaçınmaq lazımdır — belə bir flag-ı söndürmək zəiflik yaradır. İnfrastruktur dəyişiklikləri üçün (verilənlər bazasının dəyişdirilməsi, yeni arxitekturaya miqrasiya) feature flag-lar faydalıdır, lakin xüsusilə diqqətli test tələb edir.
Feature flag-lar ilə kodu necə test etməli?
Əsas yanaşma matris testidir: testləri bütün flag kombinasiyaları ilə işlətmək. CI/CD üçün bu çox bahalı ola bilər (2^n kombinasiya), ona görə praktikada bütün flag-lar ayrılıqda hər iki halda (aktiv/deaktiv) test olunur, kombinasiyalar üçün isə yalnız kritik olanlar. Vahid testləri flag dəyərini mock etməlidir. İnteqrasiya testləri məlum flag dəyərləri ilə konkret ssenariləri yoxlayır. E2E testləri ən ehtimal olunan kombinasiyaları əhatə edir.
Köhnə feature flag-ları necə silməli?
Silinmə prosesi: 1) flag-ın bütün istifadəçilər üçün 100% aktiv olduğuna və eksperiment rejimində istifadə edilmədiyinə əmin olun; 2) bütün şərti flag yoxlamalarını koddan silin, yalnız “yeni” qolu buraxaraq; 3) flag tərifini idarəetmə sistemindən silin; 4) silinmiş flag üçün mock-ları çıxararaq testləri yeniləyin. Bu prosesi CI vasitəsilə avtomatlaşdırmaq tövsiyə olunur: N gündən çox dəyişməyən flag-lar stale kimi qeyd olunur və silinmə təsdiqi tələb edir.
Nəticə
- Feature Flag — deploy anını funksionallığın buraxılış anından ayıran şərti açar
- Dörd növ flag (release, experiment, ops, permission) müxtəlif məqsədlərə, həyat müddətinə və tələblərə malikdir
- Flag idarəsi mərkəzləşmiş saxlama, konfiqurasiya interfeysi və stale flag-ların mütəmadi auditini tələb edir
- Alətlər: LaunchDarkly və Split korporativlər üçün, Unleash və Flagsmith açıq mənbəli layihələr üçün
- Texniki borc təmizlənməmiş flag-lardan — əsas risk; hər flag yaratdıqda silinmə tapşırığı məcburidir
- Test flag-larla matris yanaşması və vahid testlərdə flag dəyərlərinin mock edilməsini tələb edir
- Performans keşləmə və yerli SDK istifadəsi ilə minimal dərəcədə təsirlənir
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun