1 
2يتم النشر عندما يصل الكود إلى مرحلة الإنتاج. الإصدار هو عندما يمكن لشخص ما استخدامه بالفعل. يعد الخلط بين الاثنين أحد أسرع الطرق لجعل كل عملية نشر لحظة متوترة بعض الشيء.
3 
4يعمل feature flag على وضع مسافة بين هاتين اللحظتين. يمكنك النشر اليوم، والبدء غدًا للفريق الداخلي، ثم للعميل التجريبي، ثم لـ 10% من المستخدمين. إذا حدث خطأ ما، قم بإيقاف تشغيل العلم. ليس عليك بالضرورة التراجع عن الإصدار بأكمله.
5 
6## العلم ليس مجرد حالة
7 
8من الناحية الفنية غالبًا ما يكون `if`. ثقافيا هو أكثر من ذلك بكثير.
9 
10```typescript
11if (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 هي مواصفات مفتوحة لتقييم feature flag مع API مشترك. الفكرة بسيطة: لا ينبغي أن يعتمد رمز التطبيق الخاص بك بشكل مباشر على البائع أو النظام الداخلي الذي تستخدمه للأعلام.
23 
24التطبيق يسأل:
25 
26```typescript
27const 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`: يجب أن يكون مستقرًا. إذا تغير مع كل طلب، يمكن أن ينتهي الأمر بالمستخدم مرة واحدة في المتغير (أ) ومرة ​​في المتغير (ب). بالنسبة للتجربة، يكون الأمر فظيعًا، وبالنسبة لعملية الدفع يمكن أن يكون كارثيًا.
50 
51## طرح معقول
52 
53التدفق الذي يعجبني هو هذا:
54 
551. النشر مع رفع العلم؛
562. الاشتعال للمطورين وضمان الجودة.
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 
118لقد قام feature 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