Feature Toggle — əsasları, keçid növləri və tətbiqi
Feature Toggle — tətbiqin funksionallığını icra zamanı dəyişməyə imkan verən mexanizmdir. Bu, proqramçılara kodu dəyişmədən və yenidən yerləşdirmədən funksiyaların əlçatanlığını idarə etməyə imkan verir. Şərti kompilyasiyadan (ifdef) fərqli olaraq, toggle runtime səviyyəsində işləyir və dinamik olaraq dəyişə bilər. Martin Fowler (2024)-in məlumatlarına görə, feature toggle-lar trunk-based development və fasiləsiz çatdırılmanın əsas elementidir. Feature toggle komandalara buraxılışları və eksperimentləri idarə etməkdə çeviklik verir.
Əsas məqamlar
- Feature Toggle — konfiqurasiya vasitəsilə tətbiqin davranışını idarə edən dinamik keçid
- Əsas növlər: business toggles, release toggles, experiment toggles və infrastructure toggles
- Feature Toggle vs Flag — toggle daha çox sadə ikili keçidləri, flag isə tam platformaları ifadə edir
- CI/CD ilə inteqrasiya pipeline-in hər mərhələsində toggles-ları avtomatik yoxlamağa və test etməyə imkan verir
- Əsas problem — mütəmadi auditoriya və silinməsi lazım olan stale toggles-ların yığılması
Feature Toggle nədir
Feature Toggle (funksionallıq keçidi) — yeni funksiyanın kodunun konfiqurasiya parametrinin dəyərini yoxlayan şərti konstruksiyaya büküldüyü texnikadır. Parametr true olarsa — yeni funksionallıq aktivdir, false olarsa — köhnə kod icra olunur. Feature flag-dan əsas fərq ondadır ki, toggle mürəkkəb hədəfləmə və trafik paylama qaydaları olmadan «aktiv/deaktiv» prinsipi ilə işləyən ikili keçiddir.
Tərif və iş prinsipi
Feature toggle yeni funksionallıq ətrafında adi if konstruksiyası kimi tətbiq edilir. Toggle dəyəri tətbiq konfiqurasiyasında — mühit dəyişənlərində, JSON faylında və ya verilənlər bazasında saxlanılır. Tətbiq işə düşərkən konfiqurasiyanı yükləyir və funksiyaların görünməsi barədə qərarlar qəbul etmək üçün ondan istifadə edir. Ən sadə halda toggle dəyərinin dəyişdirilməsi tətbiqin yenidən başladılmasını tələb edir, lakin production sistemlərində toggles adətən xarici konfiq-server və ya API vasitəsilə isti yeniləməni (hot reload) dəstəkləyir.
Sadə toggle nümunəsi
JavaScript (Node.js)-də feature toggle tətbiqinə baxaq. Keçid JSON konfiqində saxlanılır və server işə düşərkən yüklənir. Middleware sorğunu yeni və ya köhnə handlerə yönləndirməzdən əvvəl toggle dəyərini yoxlayır. Belə tətbiq cari API versiyasının işini pozmadan əsas kod budağına yeni funksionallıq əlavə etməyə imkan verir.
js
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});Feature toggles növləri
ThoughtWorks-dən Pit Hodgson feature toggles-ları yaşama müddəti və istifadə məqsədinə görə təsnif edərək üç əsas növ ayırır. Toggle növünün düzgün müəyyən edilməsi uyğun saxlama mexanizmi və idarəetmə prosesi seçməyə kömək edir. Hər növü mobil inkişaf kontekstində nəzərdən keçirək.
Business və Release toggles
Business toggles — ən uzunömürlü keçidlərdir. Onlar yalnız müəyyən istifadəçi kateqoriyaları (premium funksiyalar, regional xüsusiyyətlər) üçün əlçatan olan biznes qaydalarını idarə edir. Belə toggles-lar illərlə yaşaya bilər və adətən ikili aktiv/deaktivdən daha mürəkkəb məntiqə malikdir. Release toggles — tamamlanmamış funksionallığı gizlətmək üçün müvəqqəti keçidlərdir. Onların həyat dövrü bir neçə gündən bir neçə həftəyə qədərdir. Funksionallıq tamamlandıqdan sonra release toggle koddan silinir. Bu toggles-lar trunk-based development-in əsasını təşkil edir, proqramçılara bütün funksionallığın tamamlanmasını gözləmədən əsas budağa commit etməyə imkan verir.
Experiment və Infrastructure toggles
Experiment toggles A/B testləri və pilləli buraxılış üçün istifadə olunur. Release toggles-dan fərqli olaraq, experiment toggles istifadəçilərin faiz bölgüsünü və analitika sistemləri ilə inteqrasiyanı dəstəkləyir. Onlar release toggles-dan daha uzun (bir neçə aya qədər) yaşaya bilər, lakin eksperiment bitdikdən sonra silinməlidir. Infrastructure toggles — infrastruktur dəyişikliklərini idarə etmək üçün keçidlərdir: verilənlər bazası miqrasiyası, yeni API provayderinə keçid, keşləmə alqoritmlərinin dəyişdirilməsi. Bu toggles-lar test etməyə xüsusi diqqət tələb edir, çünki onların dəyişdirilməsi bütün xidmətin sabitliyinə təsir edir.
| Toggle növü | Müddət | Auditoriya | Nümunə |
|---|---|---|---|
| Business | Aylar-illər | Rollar/regionlar üzrə | Premium funksiyalar |
| Release | Günlər-həftələr | Proqramçılar/QA | Tamamlanmamış ekran |
| Experiment | Həftələr-aylar | % istifadəçilər | İnterfeys A/B testi |
| Infrastructure | Günlər-həftələr | Daxili | VB miqrasiyası |
Feature Toggle vs Feature Flag
“Feature toggle” və “feature flag” terminləri tez-tez bir-birini əvəz edən kimi istifadə olunsa da, onlar arasında konseptual fərqlər var. Bu fərqləri başa düşmək konkret tapşırıq üçün düzgün alət seçməyə və komandada qarışıqlığın qarşısını almağa kömək edir. Hər yanaşmanın əsas fərqlərini və tətbiq sahələrini nəzərdən keçirək.
Yanaşmada fərqlər
Feature toggle — ilk növbədə texniki mexanizmdir: tətbiq koduna quraşdırılmış ikili keçid. Toggle konfiqurasiya vasitəsilə idarə olunur və xarici infrastruktur tələb etmir. Feature flag — daha geniş konsepsiyadır, idarəetmə platformasını əhatə edir: konfiqurasiya üçün UI, inteqrasiya üçün SDK, istifadə monitorinqi, analitika və audit. Flaq mürəkkəb hədəfləmə qaydalarını (region, versiya, cihaz üzrə), A/B eksperimentlərini və avtomatik silməni dəstəkləyir. Feature flag-ın feature toggle-ın təkamülü olduğunu söyləmək olar: komanda əvvəlcə sadə konfiqurasiya keçidləri ilə başlayır, böyüdükcə isə ixtisaslaşmış platformaya keçir.
Toggle nə vaxt kifayətdir
Kiçik komandalar və bir xidməti və ya monolitu olan layihələr üçün sadə konfiqurasiya toggles-ları tamamilə kifayətdir. 5–10 proqramçınız və eyni anda 1–2 aktiv toggles-larınız varsa — xarici platforma artıq olacaq. Feature flag platformaları (LaunchDarkly, Unleash) aktiv flaqların sayı 20–30-u keçdikdə, komandada 20+ proqramçı olduqda və ya müxtəlif istifadəçi seqmentləri üçün funksiyalara dəqiq giriş idarəsi tələb olunduqda zəruri olur. Müştəri yeniləməsi günlər çəkən mobil tətbiqlər üçün feature flag platformaları əlavə üstünlük verir — yeni versiya dərc etmədən tətbiqin davranışını dəyişmək imkanı.
İdarəetmə alətləri
Feature toggles-ları idarə etmək üçün alət seçimi komandanın miqyasından, texnoloji stack-dən və təhlükəsizlik tələblərindən asılıdır. Sadə konfiqurasiya fayllarından sənaye idarəetmə platformalarına qədər variantları, o cümlədən open-source alternativləri nəzərdən keçirək.
CI/CD-yə inteqrasiya
Feature toggles CI/CD pipeline-inin birinci dərəcəli vətəndaşları olmalıdır. Qurma mərhələsində pipeline cari sprintdə silinməsi planlaşdırılan bütün release toggles-ların koddan həqiqətən silindiyini yoxlayır. Test mərhələsində müxtəlif toggle kombinasiyaları ilə matrix testləri icra olunur. Yerləşdirmə mərhələsində sistem toggle konfiqurasiyasını production mühiti ilə avtomatik sinxronlaşdırır. PagerDuty və ya Opsgenie ilə inteqrasiya stale toggles-lar aşkar edildikdə və ya icazə verilən aktiv toggles sayı aşıldıqda alertlər yaratmağa imkan verir.
Məşhur həllər
Sadə ssenarilər üçün dəyişikliklərə code review ilə Git-də JSON konfiq kifayətdir. Daha təkmil variant — Togglz (Java) və ya Gofeature (Go) — toggles-ları idarə etmək üçün minimal UI əlavə edən kitabxanalar. Production sistemləri üçün bütün dillər üçün SDK və aktivləşdirmə strategiyaları dəstəyi ilə Unleash (open-source) və ya daxili A/B testi ilə Flagsmith tövsiyə olunur. LaunchDarkly yüksək audit və uyğunluq tələbləri olan enterprise layihələr üçün standart olaraq qalır. Mobil tətbiqlər üçün bütün həllər keşləmə və oflayn rejimlə native SDK təqdim edir.
Texniki borc və aradan qaldırılması
Feature toggles — ikitərəfli alətdir. İdarəetmə intizamı olmadan onlar inkişafı yavaşladan və kodun mürəkkəbliyini artıran texniki borca çevrilir. CodeScene (2024) tədqiqatına görə, kod bazalarının 35–50%-i stale toggles — buraxılış bitdikdən sonra koddan qalan keçidləri ehtiva edir. Belə borcun qarşısının alınması və aradan qaldırılması strategiyalarını nəzərdən keçirək.
Toggles-ların silinməsi
Feature toggle-in silinməsi prosesi dörd addımdan ibarətdir. Birinci: toggle-in 100% auditoriya üçün aktiv və ya 0% üçün deaktiv olduğuna əmin olun (hansı kod budağının qalmalı olduğundan asılı olaraq). İkinci: bütün şərti toggle yoxlamalarını koddan silin, yalnız production davranışı olmalı budağı buraxın. Üçüncü: toggle tərifini saxlama sistemindən (konfiq, VB və ya platforma) silin. Dördüncü: silmənin funksionallığı pozmadığını təsdiqləmək üçün testləri icra edin. Hər toggle keçid yaradılarkən təyin edilmiş sahibi və planlaşdırılmış silinmə tarixinə malik olmalıdır.
Auditin avtomatlaşdırılması
Əl ilə toggle auditi 50 keçiddən çox miqyasda səmərəsizdir. Avtomatlaşdırma üç prinsipə əsaslanır: CI yoxlaması (stale toggles-ların olması merge-i bloklayır), monitorinq (hər toggle-in yaşı və statusu ilə dashboard), alertlər (toggle N gün ərzində dəyişməyibsə sahibinə bildiriş). Statik kod analizi alətləri (SonarQube, ESLint plugin) koddakı həmişə aktiv və ya həmişə deaktiv toggles-ları aşkar edə bilər — stale toggle-in aşkar əlaməti. Yekun yoxlama — code review, bu zaman rəyçi yeni toggle-in həqiqətən lazım olduğuna və köhnə kod budağının silinəcəyinə əmin olmalıdır.
go
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}Tez-tez verilən suallar
Feature toggle feature flag-dan nə ilə fərqlənir?
Terminlər tez-tez bir-birini əvəz edir, lakin texniki olaraq feature toggle koddakı ikili keçiddir (konfiqi yoxlayan if şərti). Feature flag — UI, SDK, analitika və mürəkkəb hədəfləmə qaydalarını əhatə edən daha geniş konsepsiyadır. Toggle xarici infrastruktur tələb etmir, flag isə adətən tələb edir.
Köhnə toggles-ları nə qədər tez-tez silmək lazımdır?
Release toggles buraxılış bitdikdən sonra 1–2 həftə ərzində silinməlidir. Experiment toggles — A/B testi bitdikdən dərhal sonra. Business toggles mütəmadi audit tələb edir (rübdə bir dəfə). PR-də task tracker-də silmə tapşırığı olmadan yeni toggle əlavə edilərsə, merge-i bloklayan CI yoxlaması qurmaq tövsiyə olunur.
Toggles mobil tətbiqlərdə istifadə edilə bilərmi?
Bəli, feature toggles mobil inkişafda fəal şəkildə istifadə olunur. Əsas alət — tətbiqin yeni versiyasını dərc etmədən keçidləri dinamik idarə etməyə imkan verən Firebase Remote Config-dir. Alternativlər: iOS/Android üçün LaunchDarkly SDK, Unleash SDK, REST API ilə öz toggle serveriniz. Oflayn rejimdə işləmək üçün dəyərlərin keşlənməsini tətbiq etmək vacibdir.
Feature toggles ilə kodu necə test etmək olar?
Əsas metod — matrix testləşdirmə: toggle aktiv və deaktiv vəziyyətdə bütün testlərin icrası. N sayda toggles üçün tam matrix test 2^n icra tələb edir, buna görə praktikada kritik kombinasiyalar seçilir. Vahid testlər toggle dəyərini mock etməlidir. İnteqrasiya testləri konkret ssenariləri yoxlayır. CI-da gözlənilməz qarşılıqlı təsirləri aşkar etmək üçün təsadüfi toggle kombinasiyası ilə testlər icra edən addım əlavə edilir.
Feature toggles-ların riskləri hansılardır?
Əsas risklər: 1) stale toggles — hər iki budağı (aktiv/deaktiv) olan kod mürəkkəb və çətin saxlanılan olur; 2) testlərin kombinator mürəkkəbliyi — hər toggle vəziyyətlərin sayını ikiqat artırır; 3) dead code — toggle həmişə aktiv olduqdan sonra köhnə budaq koddan qalır; 4) təhlükəsizlik — girişi idarə edən keçidlər səhv konfiqurasiyada zəifliklər yaradır. Bütün risklər intizam və avtomatlaşdırma mövcud olduqda idarə olunandır.
Nəticə
- Feature Toggle — tətbiq konfiqurasiyası vasitəsilə idarə olunan ikili funksionallıq keçidi
- Əsas növlər: business (aylar-illər), release (günlər-həftələr), experiment (həftələr-aylar), infrastructure (günlər-həftələr)
- Feature Toggle vs Flag — toggle daha sadədir (if + konfiq), flag tam idarəetmə platformasını əhatə edir
- CI/CD inteqrasiyası məcburidir: stale toggles yoxlaması, matrix testləri, konfiqurasiya sinxronizasiyası
- Stale toggles — əsas risk: kod bazalarının 35–50%-i istifadə olunmayan keçidlər ehtiva edir
- Toggle silinməsi proses tələb edir: vəziyyəti təsdiqlə, kodu sil, konfiqi sil, testləri icra et
- Auditin avtomatlaşdırılması CI, dashboardlar və statik kod analizi vasitəsilə texniki borc yığılmasının qarşısını alır
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