spinny:~/writing $ vim openfeature-feature-flags-progressive-delivery.md
1~2تعیناتی اس وقت ہوتی ہے جب کوڈ پیداوار میں آتا ہے۔ ریلیز تب ہوتی ہے جب کوئی اسے اصل میں استعمال کر سکتا ہو۔ دونوں کو الجھانا ہر تعیناتی کو تھوڑا تناؤ والا لمحہ بنانے کے تیز ترین طریقوں میں سے ایک ہے۔3~4feature flag ان دو لمحوں کے درمیان جگہ ڈالنے کا کام کرتا ہے۔ آپ آج تعینات کر سکتے ہیں، داخلی ٹیم کے لیے کل برطرف کر سکتے ہیں، پھر پائلٹ کسٹمر کے لیے، پھر 10% صارفین کے لیے۔ اگر کچھ غلط ہو جائے تو جھنڈا بند کر دیں۔ ضروری نہیں کہ آپ کو پوری ریلیز کو رول بیک کرنا پڑے۔5~6## جھنڈا صرف ایک اگر نہیں ہے۔7~8تکنیکی طور پر یہ اکثر `if` ہوتا ہے۔ ثقافتی طور پر یہ بہت زیادہ ہے۔9~10```typescript11if (await flags.isEnabled('checkout.v2.enabled', context)) {12 return newCheckout(input);13}14~15return oldCheckout(input);16```17~18یہ چھوٹا `if` بتدریج رول آؤٹ، ایک تجربہ، ایک ہجرت، ایک انٹرپرائز پرمٹ یا آپریشنل kill switch کی نمائندگی کر سکتا ہے۔ مسئلہ یہ ہے کہ اگر آپ اسے اچھی طرح سے منظم نہیں کرتے ہیں، تو یہ تکنیکی قرض بھی بن سکتا ہے جو کوڈ میں دو سال تک رہتا ہے۔19~20## OpenFeature کہاں آتا ہے۔21~22OpenFeature ایک عام API کے ساتھ feature flag کا جائزہ لینے کے لیے ایک کھلی تصریح ہے۔ خیال آسان ہے: آپ کے ایپلیکیشن کوڈ کا انحصار براہ راست وینڈر یا اندرونی سسٹم پر نہیں ہونا چاہیے جسے آپ جھنڈوں کے لیے استعمال کرتے ہیں۔23~24ایپ پوچھتی ہے:25~26```typescript27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {28 targetingKey: user.id,29 plan: user.plan,30 country: user.country,31});32```33~34فراہم کنندہ فیصلہ کرتا ہے کہ قواعد کہاں سے آتے ہیں: SaaS، فائل، انٹرنل سروس، فلیگڈ، GitOps کنفیگریشن۔ اگر ایک دن آپ فیچر فلیگنگ بیک اینڈ کو تبدیل کرتے ہیں، تو درخواست کو ہر جگہ دوبارہ لکھنے کی ضرورت نہیں ہے۔35~36یہ علیحدگی ایک آرکیٹیکچرل تفصیل کی طرح لگتا ہے، لیکن یہ پروجیکٹ بڑھتے ہی محسوس ہوتا ہے۔37~38## سیاق و سباق آدھی جنگ ہے۔39~40سب کے لیے آن یا آف جھنڈا مفید ہے، لیکن محدود ہے۔ پروگریسو ڈیلیوری سیاق و سباق میں رہتی ہے:41~42- اندرونی یا بیرونی صارف؛43- مفت یا انٹرپرائز پلان؛44- گاؤں؛45- تنظیم؛46- ایپ ورژن؛47- ٹریفک کا مستحکم فیصد۔48~49اہم کلید `targetingKey` ہے: اسے مستحکم ہونا چاہیے۔ اگر یہ ہر درخواست کے ساتھ تبدیل ہوتا ہے، تو صارف ایک بار ویرینٹ A میں اور ایک بار ویرینٹ B میں ختم ہو سکتا ہے۔ ایک تجربہ کے لیے یہ خوفناک ہے، چیک آؤٹ کے لیے یہ تباہ کن ہو سکتا ہے۔50~51## ایک سمجھدار رول آؤٹ52~53ایک بہاؤ جو مجھے پسند ہے وہ یہ ہے:54~551. پرچم بند کے ساتھ تعینات؛562. ڈویلپرز اور QA کے لیے اگنیشن؛573. پائلٹ کسٹمر یا کرایہ دار کے لیے سوئچ آن؛584. 5% رول آؤٹ؛595. 25% پر رول آؤٹ؛606. 100% رول آؤٹ؛617. پرانے کوڈ اور پرچم کو ہٹانا۔62~63اکثر بھول جانے والا نقطہ آخری ہے۔ ایک عارضی پرچم میں موت کی تاریخ ہونی چاہیے۔ اگر یہ ہمیشہ کے لیے رہتا ہے، تو مستقبل کے ہر ریفیکٹر سے پوچھنا پڑے گا: "لیکن کیا یہ شاخ اب بھی کارآمد ہے؟"۔64~65## Kill switch: پہلے انہیں تیار کریں۔66~67kill switch وہ جھنڈا ہے جو آپ کو بچاتا ہے جب کوئی بیرونی انحصار آپ کے ساتھ گڑبڑ کرنے لگتا ہے، کوئی کام بہت زیادہ وسائل استعمال کرتا ہے، یا نئی منطق عجیب غلطیاں پیدا کرتی ہے۔68~69ایک اچھا kill switch ہونا چاہیے:70~71- تلاش کرنے کے لئے آسان؛72- رن بک میں دستاویزی؛73- کبھی کبھار تجربہ کیا؛74- چالو ہونے پر قابل مشاہدہ؛75١ - خود مختار، جہاں تک ممکن ہو، اس حصے سے جو ٹوٹ سکتا ہے۔76~77سب سے بری چیز حادثے کے دوران دریافت کرنا ہے کہ جھنڈا موجود ہے، لیکن کوئی نہیں جانتا کہ یہ اب بھی کام کرتا ہے یا نہیں۔78~79## مشاہدہ یا ترقی پسند ترسیل نہیں۔80~81میٹرکس کو دیکھے بغیر کسی خصوصیت کو 10% پر آن کرنا متعدد مراحل کے ساتھ صرف پر امید ہے۔82~83ہر رول آؤٹ کو آسان سوالات کا جواب دینا چاہئے:84~85- کیا غلطیاں بڑھ گئی ہیں؟86- کیا تاخیر بدل گئی ہے؟87- کیا صارف بہاؤ مکمل کرتے ہیں؟88- کیا مزید ٹکٹیں ہیں یا دوبارہ کوششیں؟89- کیا متغیر صرف ایک طبقہ کو متاثر کرتا ہے؟90~91OpenFeature پرچم کی تشخیص کے ارد گرد ہکس کی حمایت کرتا ہے۔ وہ لاگ ان غلطیوں، میٹرکس کو شامل کرنے یا درجہ بندی کو trace سے جوڑنے کے لیے مفید ہیں۔92~93## نام اور ملکیت94~95نام اہم ہیں۔ `new_ui` کچھ نہیں کہتا۔ `checkout.v2.enabled` بہت کچھ کہتا ہے۔96~97ہر جھنڈے کے لیے میں کم از کم نشان زد کروں گا:98~99- نام؛100- تفصیل؛101- مالک؛102- محفوظ ڈیفالٹ؛103- اس کے موجود ہونے کی وجہ؛104- ہٹانے کی تاریخ یا شرط۔105~106ایک مالک کے بغیر جھنڈا تقریبا ہمیشہ ایک جھنڈا ہے جسے کوئی بھی صاف نہیں کرے گا۔107~108## ان کا اندازہ کہاں سے کیا جائے۔109~110فرنٹ اینڈ، بیک اینڈ یا ایج؟ انحصار کرتا ہے۔111~112اگر جھنڈا لے آؤٹ، کاپی، یا آن بورڈنگ کے لیے ہے تو فرنٹ اینڈ ٹھیک ہے۔ اگر اس کا تعلق اجازتوں، بلنگ، حدود یا حساس ڈیٹا سے ہے، تو اسے بیک اینڈ پر ہونا چاہیے۔ اگر اس میں روٹنگ یا زیادہ ٹریفک کے تجربات شامل ہیں، تو کنارے کا مطلب ہو سکتا ہے۔113~114سادہ اصول: فرنٹ اینڈ تجربے کو بہتر بنا سکتا ہے، لیکن یہ واحد حفاظتی رکاوٹ نہیں ہونا چاہیے۔115~116## نتیجہ117~118feature flag اچھی طرح سے پیداوار کے ساتھ تعلقات کو تبدیل کرتا ہے۔ وہ خطرے کو ختم نہیں کرتے ہیں، لیکن وہ اسے چھوٹا اور زیادہ قابل انتظام بناتے ہیں۔ آپ سلائسوں میں چھوڑ سکتے ہیں، مشاہدہ کر سکتے ہیں، روک سکتے ہیں، واپس جا سکتے ہیں، سیکھ سکتے ہیں۔119~120OpenFeature ایک صاف فاؤنڈیشن کا اضافہ کرتا ہے: ایک عام API، قابل تبادلہ فراہم کرنے والے، اور نظام کو بڑھانے کا ایک صاف طریقہ۔ لیکن نظم و ضبط آپ کا رہتا ہے: محفوظ ڈیفالٹس، واضح نام، میٹرکس، مالکان اور صفائی۔121~122بہترین جھنڈا وہ ہے جو آپ کو سکون کے ساتھ چھوڑنے میں مدد کرتا ہے اور پھر اس وقت غائب ہوجاتا ہے جب اس کی مزید ضرورت نہ ہو۔123~124## ذرائع125~126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)131~
NORMAL · openfeature-feature-flags-progressive-delivery.md [readonly]131 lines · :q to close