Feature Flag: یہ کیسے کام کرتا ہے، فلیگ کی اقسام اور انتظامی اصول
Feature Flag ایک ڈیولپمنٹ تکنیک ہے جس میں ایپلیکیشن کی فعالیت کو رن ٹائم پر مشروط سوئچز کے ذریعے فعال یا غیر فعال کیا جاتا ہے، بغیر نیا کوڈ ڈیپلائے کیے۔ روایتی طریقہ «commit — deploy» کے بجائے، feature flags ڈیپلائے کے لمحے کو فعالیت کو فعال کرنے کے لمحے سے الگ کرنے کی اجازت دیتے ہیں۔ LaunchDarkly (2024) کے مطابق، feature flags استعمال کرنے والی ٹیمیں نئی خصوصیات کے رول آؤٹ وقت کو 40% تک کم کرتی ہیں۔ Feature flags جدید موبائل اور ویب ایپلیکیشنز کے لیے CI/CD کا ایک لازمی عنصر بن گئے ہیں۔
اہم نکات
- Feature Flag — ایک مشروط سوئچ جو رن ٹائم پر فعالیت کی دستیابی کو کنٹرول کرتا ہے
- چار اقسام کے فلیگ: release، experiment، ops اور permission toggles مختلف مقاصد اور زندگی کے چکر کے ساتھ
- فلیگ کا انتظام اسٹوریج سسٹم، کنفیگریشن UI اور استعمال کی نگرانی کی ضرورت ہے
- پلیٹ فارم LaunchDarkly، Unleash اور Split تمام مشہور زبانوں اور پلیٹ فارمز کے لیے SDK فراہم کرتے ہیں
- تکنیکی قرض صاف نہ کیے گئے فلیگ سے — اہم خطرہ: پرانے فلیگ کو باقاعدہ آڈٹ اور ہٹانے کی ضرورت ہے
Feature Flag کیا ہے
Feature Flag (فیچر ٹوگل) ایک میکانزم ہے جو کوڈ میں تبدیلی کیے بغیر ایپلیکیشن کے رویے کو تبدیل کرنے کی اجازت دیتا ہے۔ اپنی سادہ ترین شکل میں، یہ ایک مشروط تعمیر ہے جو نئی فعالیت کو انجام دینے سے پہلے فلیگ کی قدر کو چیک کرتی ہے۔ فلیگ کو کنفیگریشن فائل، ڈیٹا بیس یا بیرونی سروس میں محفوظ کیا جا سکتا ہے اور حقیقی وقت میں تبدیل کیا جا سکتا ہے۔ یہ نقطہ نظر ٹیموں کو نامکمل کوڈ کو مین برانچ میں کمٹ کرنے کی صلاحیت دیتا ہے بغیر اس خوف کے کہ یہ ڈیولپمنٹ مکمل ہونے سے پہلے صارفین تک پہنچ جائے گا۔
تعریف اور مقصد
Feature flags کا بنیادی مقصد ڈیپلائے کو ریلیز سے الگ کرنا ہے۔ ڈیپلائے سرور یا ایپ اسٹور پر کوڈ رکھنے کا عمل ہے۔ ریلیز وہ لمحہ ہے جب فعالیت صارف کے لیے دستیاب ہوتی ہے۔ Feature flags کے بغیر، یہ واقعات ایک ساتھ ہوتے ہیں: کوڈ پروڈکشن میں جاتا ہے — صارف اسے دیکھتے ہیں۔ Feature flags کے ساتھ، کوڈ ریلیز سے ہفتوں پہلے پروڈکشن میں ڈیپلائے کیا جا سکتا ہے، اندرونی جانچ کے لیے فعال کیا جا سکتا ہے، یا بتدریج صارفین تک پہنچایا جا سکتا ہے۔ یہ trunk-based development اور مسلسل ترسیل کے لیے اہم ہے۔
سادہ فلیگ کی مثال
موبائل Kotlin ایپلیکیشن میں بنیادی feature flag کے نفاذ پر غور کریں۔ فلیگ Firebase Remote Config میں محفوظ ہوتا ہے اور ایپ شروع ہونے پر لوڈ ہوتا ہے۔ فلیگ کی قدر پر منحصر ہے، پرانی یا نئی پروفائل اسکرین دکھائی جاتی ہے۔ یہ نفاذ App Store میں اپ ڈیٹ شائع کیے بغیر پروفائل کا نیا ورژن جاری کرنے کی اجازت دیتا ہے — بس Firebase کنسول میں قدر تبدیل کریں۔
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 Flags کی اقسام
تمام feature flags ایک جیسے نہیں ہوتے۔ مارٹن فاؤلر کی درجہ بندی چار اقسام کے فلیگ کی نشاندہی کرتی ہے، جو استعمال کے مقصد، زندگی کی مدت اور انتظامی ضروریات میں مختلف ہوتے ہیں۔ صحیح فلیگ کی درجہ بندی مناسب انفراسٹرکچر منتخب کرنے اور عام مسائل سے بچنے میں مدد دیتی ہے۔
Release Toggles
Release toggles فلیگ کی سب سے عام قسم ہیں۔ یہ پروڈکشن میں نامکمل فعالیت کو چھپانے کے لیے استعمال ہوتے ہیں۔ ڈیولپر ایک فلیگ میں لپٹے کوڈ کو مین برانچ میں کمٹ کرتا ہے اور آہستہ آہستہ فعالیت مکمل کرتا ہے۔ مکمل ہونے اور جانچ کے بعد، فلیگ تمام صارفین کے لیے فعال کر دیا جاتا ہے۔ اس طرح کے فلیگ کی زندگی کا چکر چند دنوں سے دو ہفتوں تک ہوتا ہے۔ مکمل رول آؤٹ کے بعد، فلیگ کو کوڈ سے ہٹا دیا جاتا ہے۔ Release toggles trunk-based development کی بنیاد ہیں۔
Experiment اور Ops Toggles
Experiment toggles A/B جانچ کے ساتھ مل کر کام کرتے ہیں۔ وہ صرف فعالیت کو آن/آف نہیں کرتے بلکہ صارف کو تجرباتی گروپوں میں سے ایک میں لے جاتے ہیں۔ اس طرح کے فلیگ اکثر پیچیدہ ہدف بندی کے قوانین (علاقے، OS ورژن، سبسکرپشن کے مطابق) اور تجزیاتی نظاموں کے ساتھ انضمام کی حمایت کرتے ہیں۔ Ops toggles آپریشنل کنٹرول کے لیے استعمال ہوتے ہیں — مثال کے طور پر، زیادہ بوجھ کے تحت کسی بھاری خصوصیت کو غیر فعال کرنا یا فوری ڈیپلائے کے بغیر کسی مسئلے والے ماڈیول کو عارضی طور پر بند کرنا۔ Ops toggles کو زیادہ سے زیادہ تیز اور قابل بھروسہ ہونا چاہیے، کیونکہ سروس کا استحکام ان پر منحصر ہے۔
| قسم | مدت | متحرک | مقصد |
|---|---|---|---|
| Release | دن-ہفتے | جامد | نامکمل کوڈ چھپانا |
| Experiment | دن-مہینے | متحرک | A/B جانچ اور رول آؤٹ |
| Ops | گھنٹے-دن | متحرک | آپریشنل کنٹرول |
| Permission | مہینے+ | جامد | رسائی کنٹرول |
Feature Flags کا انتظام
Feature flags کا انتظام ایک علیحدہ شعبہ ہے جس میں فلیگ کا ذخیرہ، ترتیب، نگرانی اور آڈٹ شامل ہے۔ انتظامی نظام کے بغیر، فلیگ بے قابو تکنیکی قرض میں بدل جاتے ہیں جو ترقی کو سست کر دیتا ہے۔ آئیے ایک پروڈکشن سسٹم کی مثال کا استعمال کرتے ہوئے انتظام کے اہم پہلوؤں کو دیکھتے ہیں۔
فلیگ کی زندگی کا چکر
ہر feature flag چار مراحل سے گزرتا ہے: تخلیق، استعمال، استحکام اور ہٹانا۔ تخلیق کے مرحلے میں، فلیگ کی کلید، قسم اور ڈیفالٹ قدر متعین کی جاتی ہے۔ استعمال کے دوران، ٹیم نگرانی کرتی ہے کہ کس نے فلیگ کو فعال کیا، کس سامعین کے لیے اور کس مقصد سے۔ استحکام کے بعد (فعالیت مکمل طور پر تیار اور جانچی گئی)، فلیگ کو کوڈ سے ہٹانا ضروری ہے۔ ہٹانے کا عمل کوڈ کے جائزے کے ذریعے خودکار ہوتا ہے: CI چیک کرتا ہے کہ 100% صارفین کے لیے فعال تمام فلیگ کے پاس ہٹانے کا کام ہے۔
مرکزی ذخیرہ
Feature flags کو مرکزی طور پر ذخیرہ کیا جانا چاہیے، نہ کہ ہر سروس کی کنفیگریشن فائلوں میں بکھرا ہوا۔ مثالی طور پر — UI کے ساتھ ایک وقف شدہ سروس (LaunchDarkly, Unleash)۔ کم از کم قابل قبول آپشن ذخیرہ میں ایک JSON کنفیگریشن ہے جس میں تبدیلیوں کے لیے کوڈ کا جائزہ لیا جائے۔ فلیگ ذخیرہ کرنے کے لیے ڈیٹا بیس کم ترجیحی ہے کیونکہ اسے علیحدہ انتظامی انٹرفیس کی ضرورت ہوتی ہے۔ ہر فلیگ کا ایک مالک (ٹیم یا مخصوص ڈیولپر)، تفصیل اور زندگی کی مدت (TTL) ہونی چاہیے۔ پرانے فلیگ کا باقاعدہ آڈٹ ایک لازمی عمل ہے، جو CI کام کے ذریعے خودکار ہوتا ہے جو N دنوں سے زیادہ عرصے سے تبدیل نہ ہونے والے فلیگ کو چیک کرتا ہے۔
Feature Flags کے اوزار
Feature flags کے انتظامی اوزاروں کی مارکیٹ میں مکمل انتظامی چکر والے تجارتی پلیٹ فارم اور خود ڈیپلائے کے لیے اوپن سورس حل دونوں شامل ہیں۔ اوزار کا انتخاب ٹیم کے سائز، تاخیر کی ضروریات اور تعمیل پر منحصر ہے۔
تجارتی پلیٹ فارم
LaunchDarkly تمام مشہور زبانوں اور پلیٹ فارمز (iOS، Android، Web، Backend) کے لیے SDK کے ساتھ مارکیٹ لیڈر ہے۔ یہ ملٹی ماحول، قواعد پر مبنی ہدف بندی، A/B تجربات اور خودکار فلیگ ہٹانے کی حمایت کرتا ہے۔ Split انٹرپرائز خصوصیات پر مرکوز ایک متبادل ہے: کردار پر مبنی رسائی، آڈٹ لاگز اور تعمیل (SOC2, HIPAA)۔ ConfigCat ایک ہلکا اور سستا حل ہے جو چھوٹی ٹیموں کے لیے موزوں ہے۔ تمام پلیٹ فارم اقدار کو کیش کرنے اور ایپلیکیشن کی تاخیر پر کم سے کم اثر کے ساتھ SDK فراہم کرتے ہیں۔
اوپن سورس حل
Unleash UI، API اور تمام بڑے پلیٹ فارمز کے لیے SDK کے ساتھ سب سے مقبول اوپن سورس حل ہے۔ یہ ایکٹیویشن کی حکمت عملیوں، حسب ضرورت سیاق و سباق اور نگرانی کے لیے Prometheus کے ساتھ انضمام کی حمایت کرتا ہے۔ Flagsmith بلٹ ان A/B جانچ اور ماحول کے انتظام کے ساتھ ایک متبادل ہے۔ اوپن سورس حلوں کے لیے انفراسٹرکچر کی تعیناتی اور دیکھ بھال کی ضرورت ہوتی ہے، لیکن ڈیٹا پر مکمل کنٹرول دیتے ہیں اور ان میں لائسنسنگ کی کوئی پابندی نہیں ہے۔ موبائل ایپلیکیشنز کے لیے، دونوں حل آف لائن فلیگ ویلیو کیشنگ کے ساتھ مقامی SDK فراہم کرتے ہیں۔
بہترین طریقہ کار
Feature flags ایک طاقتور ٹول ہیں، لیکن نظم و ضبط کے بغیر وہ تکنیکی قرض پیدا کرتے ہیں اور کوڈ کو پیچیدہ بناتے ہیں۔ مارٹن فاؤلر اور LaunchDarkly انجینئرز نے طریقوں کا ایک مجموعہ ترتیب دیا ہے جو منفی نتائج کے بغیر feature flags سے زیادہ سے زیادہ فائدہ اٹھانے میں مدد کرتا ہے۔ آئیے پروڈکشن سسٹمز کے لیے اہم سفارشات کا جائزہ لیتے ہیں۔
تکنیکی قرض سے بچنا
ہر feature flag جو رول آؤٹ مکمل ہونے کے بعد نہیں ہٹایا گیا تکنیکی قرض بن جاتا ہے۔ LaunchDarkly (2024) کے ایک مطالعہ سے پتہ چلا کہ اوسطاً 30–40% فلیگ ضرورت نہ ہونے کے بعد بھی کوڈ میں رہ جاتے ہیں۔ حل: «ایک فلیگ — ایک کام» کا اصول نافذ کریں۔ فلیگ بناتے وقت، ٹاسک ٹریکر میں ایک آخری تاریخ کے ساتھ ہٹانے کا کام بنایا جاتا ہے۔ CI چیک کرتا ہے کہ 30 دنوں سے زیادہ عرصے تک 100% فعال کوئی فلیگ نہ ہو۔ کوڈ کے جائزے میں نہ صرف فلیگ شامل کرنے بلکہ ہٹانے کی بھی جانچ کرنی چاہیے۔
فلیگ کے ساتھ جانچ
Feature flags جانچ کے لیے مشترکاتی پیچیدگی پیدا کرتے ہیں: ہر فلیگ ممکنہ ایپلیکیشن حالتوں کی تعداد کو دوگنا کر دیتا ہے۔ اس پیچیدگی کو منظم کرنے کے لیے، میٹرکس ٹیسٹ جو تمام فلیگ امتزاج کی جانچ کرتے ہیں اور فلیگ ٹوگلنگ انٹیگریشن ٹیسٹ استعمال کیے جاتے ہیں۔ CI پائپ لائن میں ایک مرحلہ شامل کیا جاتا ہے جو مختلف فلیگ ویلیو امتزاج کے ساتھ ٹیسٹ چلاتا ہے۔ اہم فلیگ (ops toggles) کے لیے، لوڈ ٹیسٹ لازمی ہیں تاکہ تصدیق کی جا سکے کہ فلیگ سوئچ کرنے سے تاخیر میں اضافہ یا خرابیاں نہیں آتیں۔
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)
)اکثر پوچھے گئے سوالات
Feature flag اور feature toggle میں کیا فرق ہے؟
یہ اصطلاحات اکثر ایک دوسرے کے لیے استعمال ہوتی ہیں، لیکن ایک باریک بینی ہے: Feature flag عام طور پر مرکزی انتظام، UI اور SDK کے ساتھ ایک زیادہ پختہ نظام کو ظاہر کرتا ہے، جبکہ feature toggle کوڈ میں ایک سادہ بائنری سوئچ ہے۔ مارٹن فاؤلر feature toggle کو ایک عام اصطلاح کے طور پر استعمال کرتے ہیں، لیکن صنعت میں feature flag زیادہ تر تجارتی پلیٹ فارمز (LaunchDarkly, Split) سے منسلک ہوتا ہے۔
Feature flags کارکردگی کو کیسے متاثر کرتے ہیں؟
مناسب نفاذ کے ساتھ کارکردگی پر اثر کم سے کم ہوتا ہے۔ بہترین طریقہ کار: فلیگ کی اقدار کو 30–60 سیکنڈ کے TTL کے ساتھ میموری میں کیش کریں، فلیگ چیک کرتے وقت ہم آہنگ HTTP کالز سے گریز کریں، مقامی کیش اور پس منظر میں ہم آہنگی والے SDK استعمال کریں۔ LaunchDarkly کے مطابق، ان کے SDK کی p99 تاخیر 5 ms سے کم ہے، جو زیادہ تر ایپلیکیشنز کے لیے نہ ہونے کے برابر ہے۔
Feature flags کب استعمال نہیں کرنے چاہئیں؟
Feature flags کا استعمال اہم مالیاتی کارروائیوں میں کاروباری منطق کو تبدیل کرنے کے لیے تجویز نہیں کیا جاتا جہاں یہ جاننا ضروری ہے کہ کون سا کوڈ چل رہا ہے۔ سیکیورٹی فنکشنز (اختیار، خفیہ کاری) کے لیے بھی فلیگ سے گریز کریں — اس طرح کے فلیگ کو غیر فعال کرنا ایک کمزوری پیدا کرتا ہے۔ انفراسٹرکچر تبدیلیوں (ڈیٹا بیس مائیگریشن، نئے آرکیٹیکچر میں تبدیلی) کے لیے، feature flags مفید ہیں لیکن خاص طور پر مکمل جانچ کی ضرورت ہے۔
Feature flags کے ساتھ کوڈ کی جانچ کیسے کریں؟
بنیادی طریقہ میٹرکس ٹیسٹنگ ہے: تمام فلیگ امتزاج کے ساتھ ٹیسٹ چلانا۔ CI/CD کے لیے یہ بہت مہنگا ہو سکتا ہے (2^n امتزاج)، لہٰذا عملی طور پر تمام فلیگ کو انفرادی طور پر دونوں حالتوں (آن/آف) میں جانچا جاتا ہے، اور صرف اہم امتزاج کی جانچ کی جاتی ہے۔ یونٹ ٹیسٹ کو فلیگ کی قدر کا نقلی ہونا چاہیے۔ انٹیگریشن ٹیسٹ معروف فلیگ اقدار کے ساتھ مخصوص منظرناموں کی جانچ کرتے ہیں۔ E2E ٹیسٹ سب سے زیادہ ممکنہ امتزاج کا احاطہ کرتے ہیں۔
پرانے feature flags کو کیسے ہٹایا جائے؟
ہٹانے کا عمل: 1) یقینی بنائیں کہ فلیگ تمام صارفین کے لیے 100% فعال ہے اور تجرباتی موڈ میں استعمال نہیں ہو رہا؛ 2) کوڈ سے فلیگ کی تمام مشروط جانچیں ہٹائیں، صرف «نیا» برانچ رکھیں؛ 3) انتظامی نظام سے فلیگ کی تعریف ہٹائیں؛ 4) ہٹائے گئے فلیگ کے نقلی ہٹا کر ٹیسٹ اپ ڈیٹ کریں۔ اس عمل کو CI کے ذریعے خودکار کرنے کی سفارش کی جاتی ہے: N دنوں سے زیادہ عرصے سے تبدیل نہ ہونے والے فلیگ کو پرانے کے طور پر نشان زد کیا جاتا ہے اور ہٹانے کی تصدیق کی ضرورت ہوتی ہے۔
خلاصہ
- Feature Flag — ایک مشروط سوئچ جو ڈیپلائے کے لمحے کو فعالیت کی ریلیز کے لمحے سے الگ کرتا ہے
- چار اقسام کے فلیگ (release, experiment, ops, permission) کے مختلف مقاصد، مدتیں اور ضروریات ہیں
- فلیگ کا انتظام مرکزی ذخیرہ، کنفیگریشن UI اور پرانے فلیگ کا باقاعدہ آڈٹ چاہتا ہے
- اوزار: انٹرپرائز کے لیے LaunchDarkly اور Split، اوپن سورس منصوبوں کے لیے Unleash اور Flagsmith
- تکنیکی قرض صاف نہ کیے گئے فلیگ سے اہم خطرہ ہے؛ ہر فلیگ بناتے وقت ہٹانے کے کام لازمی ہیں
- جانچ فلیگ کے ساتھ میٹرکس نقطہ نظر اور یونٹ ٹیسٹ میں فلیگ اقدار کا نقلی ہونا چاہیے
- کارکردگی کیشنگ اور مقامی SDK استعمال کرنے پر کم سے کم متاثر ہوتی ہے
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں