تعیناتی اس وقت ہوتی ہے جب کوڈ پیداوار میں آتا ہے۔ ریلیز تب ہوتی ہے جب کوئی اسے اصل میں استعمال کر سکتا ہو۔ دونوں کو الجھانا ہر تعیناتی کو تھوڑا تناؤ والا لمحہ بنانے کے تیز ترین طریقوں میں سے ایک ہے۔
feature flag ان دو لمحوں کے درمیان جگہ ڈالنے کا کام کرتا ہے۔ آپ آج تعینات کر سکتے ہیں، داخلی ٹیم کے لیے کل برطرف کر سکتے ہیں، پھر پائلٹ کسٹمر کے لیے، پھر 10% صارفین کے لیے۔ اگر کچھ غلط ہو جائے تو جھنڈا بند کر دیں۔ ضروری نہیں کہ آپ کو پوری ریلیز کو رول بیک کرنا پڑے۔
جھنڈا صرف ایک اگر نہیں ہے۔
تکنیکی طور پر یہ اکثر if ہوتا ہے۔ ثقافتی طور پر یہ بہت زیادہ ہے۔
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
یہ چھوٹا if بتدریج رول آؤٹ، ایک تجربہ، ایک ہجرت، ایک انٹرپرائز پرمٹ یا آپریشنل kill switch کی نمائندگی کر سکتا ہے۔ مسئلہ یہ ہے کہ اگر آپ اسے اچھی طرح سے منظم نہیں کرتے ہیں، تو یہ تکنیکی قرض بھی بن سکتا ہے جو کوڈ میں دو سال تک رہتا ہے۔
OpenFeature کہاں آتا ہے۔
OpenFeature ایک عام API کے ساتھ feature flag کا جائزہ لینے کے لیے ایک کھلی تصریح ہے۔ خیال آسان ہے: آپ کے ایپلیکیشن کوڈ کا انحصار براہ راست وینڈر یا اندرونی سسٹم پر نہیں ہونا چاہیے جسے آپ جھنڈوں کے لیے استعمال کرتے ہیں۔
ایپ پوچھتی ہے:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
فراہم کنندہ فیصلہ کرتا ہے کہ قواعد کہاں سے آتے ہیں: SaaS، فائل، انٹرنل سروس، فلیگڈ، GitOps کنفیگریشن۔ اگر ایک دن آپ فیچر فلیگنگ بیک اینڈ کو تبدیل کرتے ہیں، تو درخواست کو ہر جگہ دوبارہ لکھنے کی ضرورت نہیں ہے۔
یہ علیحدگی ایک آرکیٹیکچرل تفصیل کی طرح لگتا ہے، لیکن یہ پروجیکٹ بڑھتے ہی محسوس ہوتا ہے۔
سیاق و سباق آدھی جنگ ہے۔
سب کے لیے آن یا آف جھنڈا مفید ہے، لیکن محدود ہے۔ پروگریسو ڈیلیوری سیاق و سباق میں رہتی ہے:
- اندرونی یا بیرونی صارف؛
- مفت یا انٹرپرائز پلان؛
- گاؤں؛
- تنظیم؛
- ایپ ورژن؛
- ٹریفک کا مستحکم فیصد۔
اہم کلید targetingKey ہے: اسے مستحکم ہونا چاہیے۔ اگر یہ ہر درخواست کے ساتھ تبدیل ہوتا ہے، تو صارف ایک بار ویرینٹ A میں اور ایک بار ویرینٹ B میں ختم ہو سکتا ہے۔ ایک تجربہ کے لیے یہ خوفناک ہے، چیک آؤٹ کے لیے یہ تباہ کن ہو سکتا ہے۔
ایک سمجھدار رول آؤٹ
ایک بہاؤ جو مجھے پسند ہے وہ یہ ہے:
- پرچم بند کے ساتھ تعینات؛
- ڈویلپرز اور QA کے لیے اگنیشن؛
- پائلٹ کسٹمر یا کرایہ دار کے لیے سوئچ آن؛
- 5% رول آؤٹ؛
- 25% پر رول آؤٹ؛
- 100% رول آؤٹ؛
- پرانے کوڈ اور پرچم کو ہٹانا۔
اکثر بھول جانے والا نقطہ آخری ہے۔ ایک عارضی پرچم میں موت کی تاریخ ہونی چاہیے۔ اگر یہ ہمیشہ کے لیے رہتا ہے، تو مستقبل کے ہر ریفیکٹر سے پوچھنا پڑے گا: "لیکن کیا یہ شاخ اب بھی کارآمد ہے؟"۔
Kill switch: پہلے انہیں تیار کریں۔
kill switch وہ جھنڈا ہے جو آپ کو بچاتا ہے جب کوئی بیرونی انحصار آپ کے ساتھ گڑبڑ کرنے لگتا ہے، کوئی کام بہت زیادہ وسائل استعمال کرتا ہے، یا نئی منطق عجیب غلطیاں پیدا کرتی ہے۔
ایک اچھا kill switch ہونا چاہیے:
- تلاش کرنے کے لئے آسان؛
- رن بک میں دستاویزی؛
- کبھی کبھار تجربہ کیا؛
- چالو ہونے پر قابل مشاہدہ؛ ١ - خود مختار، جہاں تک ممکن ہو، اس حصے سے جو ٹوٹ سکتا ہے۔
سب سے بری چیز حادثے کے دوران دریافت کرنا ہے کہ جھنڈا موجود ہے، لیکن کوئی نہیں جانتا کہ یہ اب بھی کام کرتا ہے یا نہیں۔
مشاہدہ یا ترقی پسند ترسیل نہیں۔
میٹرکس کو دیکھے بغیر کسی خصوصیت کو 10% پر آن کرنا متعدد مراحل کے ساتھ صرف پر امید ہے۔
ہر رول آؤٹ کو آسان سوالات کا جواب دینا چاہئے:
- کیا غلطیاں بڑھ گئی ہیں؟
- کیا تاخیر بدل گئی ہے؟
- کیا صارف بہاؤ مکمل کرتے ہیں؟
- کیا مزید ٹکٹیں ہیں یا دوبارہ کوششیں؟
- کیا متغیر صرف ایک طبقہ کو متاثر کرتا ہے؟
OpenFeature پرچم کی تشخیص کے ارد گرد ہکس کی حمایت کرتا ہے۔ وہ لاگ ان غلطیوں، میٹرکس کو شامل کرنے یا درجہ بندی کو trace سے جوڑنے کے لیے مفید ہیں۔
نام اور ملکیت
نام اہم ہیں۔ new_ui کچھ نہیں کہتا۔ checkout.v2.enabled بہت کچھ کہتا ہے۔
ہر جھنڈے کے لیے میں کم از کم نشان زد کروں گا:
- نام؛
- تفصیل؛
- مالک؛
- محفوظ ڈیفالٹ؛
- اس کے موجود ہونے کی وجہ؛
- ہٹانے کی تاریخ یا شرط۔
ایک مالک کے بغیر جھنڈا تقریبا ہمیشہ ایک جھنڈا ہے جسے کوئی بھی صاف نہیں کرے گا۔
ان کا اندازہ کہاں سے کیا جائے۔
فرنٹ اینڈ، بیک اینڈ یا ایج؟ انحصار کرتا ہے۔
اگر جھنڈا لے آؤٹ، کاپی، یا آن بورڈنگ کے لیے ہے تو فرنٹ اینڈ ٹھیک ہے۔ اگر اس کا تعلق اجازتوں، بلنگ، حدود یا حساس ڈیٹا سے ہے، تو اسے بیک اینڈ پر ہونا چاہیے۔ اگر اس میں روٹنگ یا زیادہ ٹریفک کے تجربات شامل ہیں، تو کنارے کا مطلب ہو سکتا ہے۔
سادہ اصول: فرنٹ اینڈ تجربے کو بہتر بنا سکتا ہے، لیکن یہ واحد حفاظتی رکاوٹ نہیں ہونا چاہیے۔
نتیجہ
feature flag اچھی طرح سے پیداوار کے ساتھ تعلقات کو تبدیل کرتا ہے۔ وہ خطرے کو ختم نہیں کرتے ہیں، لیکن وہ اسے چھوٹا اور زیادہ قابل انتظام بناتے ہیں۔ آپ سلائسوں میں چھوڑ سکتے ہیں، مشاہدہ کر سکتے ہیں، روک سکتے ہیں، واپس جا سکتے ہیں، سیکھ سکتے ہیں۔
OpenFeature ایک صاف فاؤنڈیشن کا اضافہ کرتا ہے: ایک عام API، قابل تبادلہ فراہم کرنے والے، اور نظام کو بڑھانے کا ایک صاف طریقہ۔ لیکن نظم و ضبط آپ کا رہتا ہے: محفوظ ڈیفالٹس، واضح نام، میٹرکس، مالکان اور صفائی۔
بہترین جھنڈا وہ ہے جو آپ کو سکون کے ساتھ چھوڑنے میں مدد کرتا ہے اور پھر اس وقت غائب ہوجاتا ہے جب اس کی مزید ضرورت نہ ہو۔