Feature flag: أطلق دون حبس أنفاسك

يتم النشر عندما يصل الكود إلى مرحلة الإنتاج. الإصدار هو عندما يمكن لشخص ما استخدامه بالفعل. يعد الخلط بين الاثنين أحد أسرع الطرق لجعل كل عملية نشر لحظة متوترة بعض الشيء.

يعمل feature flag على وضع مسافة بين هاتين اللحظتين. يمكنك النشر اليوم، والبدء غدًا للفريق الداخلي، ثم للعميل التجريبي، ثم لـ 10% من المستخدمين. إذا حدث خطأ ما، قم بإيقاف تشغيل العلم. ليس عليك بالضرورة التراجع عن الإصدار بأكمله.

العلم ليس مجرد حالة

من الناحية الفنية غالبًا ما يكون if. ثقافيا هو أكثر من ذلك بكثير.

if (await flags.isEnabled('checkout.v2.enabled', context)) {
  return newCheckout(input);
}

return oldCheckout(input);

يمكن أن يمثل هذا if الصغير طرحًا تدريجيًا أو تجربة أو ترحيلًا أو تصريح مؤسسة أو تشغيل kill switch. المشكلة هي أنه إذا لم تقم بإدارتها بشكل جيد، فقد تصبح أيضًا ديونًا فنية تبقى في الكود لمدة عامين.

أين يأتي OpenFeature

OpenFeature هي مواصفات مفتوحة لتقييم feature flag مع API مشترك. الفكرة بسيطة: لا ينبغي أن يعتمد رمز التطبيق الخاص بك بشكل مباشر على البائع أو النظام الداخلي الذي تستخدمه للأعلام.

التطبيق يسأل:

const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
  targetingKey: user.id,
  plan: user.plan,
  country: user.country,
});

يقرر الموفر مصدر القواعد: SaaS، الملف، الخدمة الداخلية، العلامة، تكوين GitOps. إذا قمت يومًا ما بتغيير الواجهة الخلفية لميزة وضع العلامات، فلن يلزم إعادة كتابة التطبيق في كل مكان.

يبدو هذا الانفصال وكأنه تفصيل معماري، ولكن يتم الشعور به مع نمو المشروع.

السياق هو نصف المعركة

يعد وضع العلم أو إيقافه مفيدًا للجميع، ولكنه محدود. يعيش التسليم التدريجي في السياق:

• مستخدم داخلي أو خارجي؛
• خطة مجانية أو خطة المؤسسة؛
• قرية؛
• منظمة؛
• نسخة التطبيق؛
• نسبة مستقرة من حركة المرور.

المفتاح المهم هو targetingKey: يجب أن يكون مستقرًا. إذا تغير مع كل طلب، يمكن أن ينتهي الأمر بالمستخدم مرة واحدة في المتغير (أ) ومرة ​​في المتغير (ب). بالنسبة للتجربة، يكون الأمر فظيعًا، وبالنسبة لعملية الدفع يمكن أن يكون كارثيًا.

طرح معقول

التدفق الذي يعجبني هو هذا:

1. النشر مع رفع العلم؛
2. الاشتعال للمطورين وضمان الجودة.
3. التشغيل للعميل التجريبي أو المستأجر. 4.5% طرح؛
4. الطرح بنسبة 25%؛
5. طرح بنسبة 100%؛
6. إزالة الرمز والعلم القديمين.

النقطة المنسية في كثير من الأحيان هي النقطة الأخيرة. يجب أن يكون للعلم المؤقت تاريخ وفاة. إذا بقي إلى الأبد، فسيتعين على كل معيد بناء مستقبلي أن يتساءل: "ولكن هل لا يزال هذا الفرع مفيدًا؟".

Kill switch: جهزهم أولاً

kill switch هي العلامة التي تنقذك عندما تبدأ تبعية خارجية في العبث بك، أو عندما تستهلك المهمة الكثير من الموارد، أو عندما ينتج المنطق الجديد أخطاء غريبة.

يجب أن يكون kill switch جيدًا:

• من السهل العثور عليها؛
• موثق في كتاب التشغيل؛
• يتم اختباره من حين لآخر؛
• يمكن ملاحظتها عند تفعيلها؛
• الاستقلال قدر الإمكان عن الجزء الذي يمكن أن ينكسر.

أسوأ ما في الأمر هو أن تكتشف أثناء الحادث أن العلم موجود، لكن لا أحد يعرف ما إذا كان لا يزال يعمل أم لا.

قابلية الملاحظة أو التسليم غير التدريجي

إن تشغيل الميزة بنسبة 10% دون النظر إلى المقاييس هو مجرد تفاؤل بخطوات متعددة.

يجب أن تجيب كل عملية طرح على أسئلة بسيطة:

• هل زادت الأخطاء؟
• هل تغير الكمون؟
• هل يكمل المستخدمون التدفق؟
• هل هناك المزيد من التذاكر أو إعادة المحاولة؟
• هل يؤثر البديل على شريحة واحدة فقط؟

OpenFeature يدعم الخطافات حول تقييم العلم. وهي مفيدة لتسجيل الأخطاء أو إضافة مقاييس أو ربط التقييم بـ trace.

التسمية والملكية

الأسماء مهمة. new_ui لا يقول شيئًا. checkout.v2.enabled يقول أكثر من ذلك بكثير.

لكل علم أود أن أضع علامة على الأقل:

• الاسم؛
• وصف؛
• مالك؛
• الافتراضي الآمن؛
• سبب وجودها؛
• تاريخ أو حالة الإزالة.

العلم الذي لا مالك له هو دائمًا علم لن يقوم أحد بإزالته.

مكان تقييمها

الواجهة الأمامية أم الخلفية أم الحافة؟ يعتمد على.

إذا كانت العلامة للتخطيط أو النسخ أو الإعداد، فإن الواجهة الأمامية جيدة. إذا كان الأمر يتعلق بالأذونات أو الفوترة أو الحدود أو البيانات الحساسة، فيجب أن يكون ذلك على الواجهة الخلفية. إذا كان الأمر يتضمن توجيهًا أو تجارب ذات حركة مرور عالية، فقد تكون الحافة منطقية.

القاعدة البسيطة: يمكن للواجهة الأمامية تحسين التجربة، لكن لا ينبغي أن تكون الحاجز الأمني ​​الوحيد.

الخلاصة

لقد قام feature flag بعمل جيد لتغيير العلاقة مع الإنتاج. إنها لا تقضي على المخاطر، لكنها تجعلها أصغر حجمًا وأكثر قابلية للإدارة. يمكنك تحريرها على شكل شرائح، والمراقبة، والتوقف، والعودة، والتعلم.

OpenFeature يضيف أساسًا نظيفًا: API مشترك، ومقدمي خدمات قابلين للتبديل، وطريقة أكثر ترتيبًا لتنمية النظام. لكن الانضباط يظل ملكك: الإعدادات الافتراضية الآمنة، والأسماء الواضحة، والمقاييس، والمالكون، والنظافة.

العلم الأفضل هو الذي يساعدك على التحرر بهدوء ثم يختفي عندما لا تكون هناك حاجة إليه.

المصادر

• OpenFeature: Introduction
• OpenFeature: Node.js SDK
• OpenFeature Specification: Flag Evaluation API
• OpenFeature: Hooks
• CNCF: OpenFeature