تبديل الميزات: طرق العرض والفوائد والعمل معها في .NET

مفتاح الوظيفة هو أداة تتيح لك التبديل من الوظيفة القديمة إلى الوظيفة الجديدة دون إعادة إنشاء التطبيق وإطلاقه مرة أخرى. يتم تطبيقه عن طريق إضافة عامل تشغيل شرطي ( if ) إلى الكود ، مما يتيح التحكم في سلوك البرنامج عن طريق تغيير القيمة المطلوبة في ملف التكوين أو قاعدة البيانات. إذا سبق لك أن قمت بتحرير الإعدادات في ملف ini ، فأنت على دراية بهذه التقنية.

بالعمق ، يمكنك العثور على عدد كبير من الخيارات المختلفة للمفاتيح والميزات الجديدة التي توفرها. هذا يثير العديد من الأسئلة. أين تضع التكوين؟ ولكن ماذا لو أصبح غير متوفر؟ ربما يمكنك كتابة إطار بسيط للعمل مع مفاتيح نفسك؟ ربما من الأفضل اتخاذ حل جاهز؟ هل هذا يناسب كل من متراصة و microservices؟

تحتوي هذه المادة على معلومات أساسية حول مفاتيح الوظائف في سياق التطوير على النظام الأساسي .NET. الجزء الأول يحتوي على معلومات عامة حول رموز التبديل ؛ تكون مستقلة تمامًا عن التنفيذ المحدد وقد تكون مفيدة للمهنيين العاملين مع مجموعة متنوعة من الأنظمة الأساسية. يناقش الجزء الثاني أدوات حديثة محددة تسهل استخدام رموز التبديل عند تطويره لـ .NET.

حاولت أن أكتب مقالًا يساعدك في تحديد ما إذا كنت ستقوم بتنفيذ رموز تبديل الوظائف في حالتك المحددة ، وإذا لزم الأمر ، كيف. في قسمنا ، يتم استخدام المحولات حتى الآن فقط لحل مشكلات معينة. على سبيل المثال ، يحتاج طلبنا غالبًا إلى طلب معلومات قانونية ومحاسبية من كتالوج ، يمكن تقديمه في شكلين: كتالوج كامل عن بعد ونسخته المحلية الجزئية. في إعدادات التطبيق ، يمكن للمستخدمين اختيار نوع الدليل الذي يجب أن يعمل عليه التطبيق في الوقت الحالي. تتضمن الخطط إدخال المحولات كبنية أساسية مشتركة للمشروع بالكامل. بناءً عليه ، سيتم بناء عمليات مشابهة لتلك المذكورة أعلاه.

وظيفة التبديل نظرة عامة

ما هذا

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


نتيجة لذلك ، فإن المنفذ ينفذ إما على فرع واحد أو على طول فرع آخر ، وفي حالة التدهور يكون الفرع الآخر فارغًا. في أبسط الحالات ، يأخذ المحول إحدى القيمتين ("تشغيل" و "إيقاف") تحت سيطرة الشخص المسؤول الذي يحتفظ بالسجل. ويمكنك التوصل إلى شيء أكثر تعقيدًا ، على سبيل المثال ، تضمين وظائف فقط لمستخدمين محددين أو لمستخدمين من بلدان معينة ، أو في وقت معين.

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

هل هذا مهم حتى؟

في مقالها ، يدعي مؤسس featureflag.tech أن المحولات أصبحت ممارسة قياسية في تطوير البرمجيات. هناك المزيد والمزيد من المواد حول رموز التبديل: مقالات نظرية ، قصص حول ممارسة تطبيق رموز التبديل ، تقارير في مؤتمرات. لقد قمت بتضمين روابط إلى المواد الأكثر إثارة للاهتمام في نص هذه المقالة ؛ يتم جمع جميع الروابط في قسم "الخاتمة" .

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

بالنسبة للأدوات التي تساعد على العمل مع المحولات ، فهناك عدد كبير جدًا منها ، ومجموعة متنوعة من الأنظمة الأساسية. ربما ، يفسر ظهور عدد كبير من الأدوات بالبساطة التي يمكنك من خلالها تنفيذ القدرات الأساسية للمفاتيح. لكن إضافة الكعك الأكثر تعقيدًا و "اللذيذ" قد يتطلب تكاليف كبيرة للعمالة ، لذا فإن العديد من المشاريع مفتوحة المصدر التي تنفذ مفاتيح الوظائف تتوقف عن التطوير والدعم. ومع ذلك ، فإن عددًا كبيرًا من المشروعات ، سواء المدفوعة أو المجانية ، لا تزال قائمة. الأكثر إثارة للاهتمام منهم (من وجهة نظر .NET) موصوفة في الجزء الثاني من المقال .

أكثر قليلا

تحتوي هذه المقالة على مخطط جيد يوضح كيفية عمل المفاتيح ؛ أدعوك لتتعرف على ذلك.


نبدأ نظرنا في الدائرة مع رمز. دع في مثالنا وظيفة جديدة - التحقق من صحة ملء المستند. نتأكد من فحص المستند فقط إذا تم تمكين هذه الوظيفة. لنجعل نقطة التحول:

 var document = GetDocument(); if (feature.IsEnabled("Feature #123. Document validation")) { Validate(document); } 

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

يستخدم جهاز التوجيه المعلومات المتاحة له: اسم الوظيفة التي مررنا بها كوسيطة ، وما يمكننا استخلاصه من الفئات الثابتة التي يعرفها لتحديد ما إذا كانت الوظيفة المطلوبة يجب أن تعمل في هذه الحالة. يكتشف الموجه كيفية تكوين المفاتيح في السجل. في حالة عدم توفر السجل ، يجب عليك إما استخدام البيانات المخزنة مؤقتًا مسبقًا ، أو اللجوء إلى استراتيجية أخرى لهذه الحالة. يمكنك أيضًا تخيل جهاز توجيه يتلقى صراحة معلومات إضافية (السياق) من خلال وسيطات الطريقة التي تساعده في تحديد ما إذا كان سيتم تمكين الوظيفة في الوقت الحالي.

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

لذلك ، بمعنى القطع الأثرية ، يتكون نظام التبديل من جزأين. من ناحية ، هذه هي بنية أساسية للمبرمجين لمعرفة ما إذا كان يجب أن تعمل الوظيفة في هذه الحالة وتوجيه التنفيذ على طول فرع الرمز المناسب. من ناحية أخرى ، إنها آلية تسمح للموظف المسؤول باختيار الوظيفة التي يجب تمكينها وإيقافها. في الحالات المتدهورة (عندما يتم تسجيل السجل في الكود ، انظر أدناه) ، يمكن أن تتزامن كلتا القطعتين ، ويمكن للمبرمج التحكم في وظيفة التشغيل والإيقاف.

ممكن متطلبات نظام التبديل

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

1. الاعتماد على وظيفة وخارجها من المعلمات المختلفة. أمثلة على المعلمات: المستخدم (الدور ، المعرف ، الموقع الجغرافي) ، الوقت (ضوء النهار أو الظلام ، أيام العمل أو أيام الأسبوع ، فترات زمنية محددة) ، البيئة (للتطوير ، الاختبار ، التشغيل الصناعي).
2. مجموعة من إحصاءات الاستخدام عند تحليل عمليات المجال: أي مستخدم في ظل أي ظروف شاهد أو لا يرى وظيفة ، كم مرة استخدموا الوظيفة الجديدة.
3. مراجعة ما يحدث مع المفاتيح نفسها: من يضغط عليها ، ومتى ، وما الذي يتغير.
4. توفير اختيار مرن بين وظائف التسجيل المحلية والبعيدة أو بعض الاستراتيجيات في حالة عدم توفر السجل البعيد.
5. تكوين الوصول إلى نظام التبديل لفئات مختلفة من الموظفين في كل من العميل والمقاول: المتخصصين الفنيين والمتخصصين في مجال الموضوع ، وكذلك مستخدمي التطبيق أنفسهم.

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

شجرة التكنولوجية

نلخص المعلومات المدروسة حول مفاتيح الوظائف ، ونلجأ إلى استعارة الشجرة التكنولوجية من ألعاب الفيديو. دعنا نتخيل أن المحولات هي تقنية تتيح للشركة طرح وظائف جديدة دون ربطها بلحظات التجميع ونشر التطبيق. هذه التكنولوجيا لها تكلفة معروفة (تكلفة الحفاظ على دورات حياة المحولات والتسجيل) والمتطلبات الأساسية للتنفيذ: منهجية تطوير مرنة بالإضافة إلى التكامل المستمر. بالطبع ، التكامل المستمر ليس شرطًا أساسيًا ، ولكنه يجعل المفاتيح أكثر فاعلية ويسمح بالتوصيل المستمر للتطبيق. بالإضافة إلى ذلك ، فإن "البحث" الخاص بالمفاتيح "يفتح" تقنيات أخرى - اختبار A / B وإطلاق الكناري. سيتم مناقشتها أدناه.

حيث قد يكون السجل الوظيفي

النظر في العديد من الخيارات لوضع سجل الوظائف ، ووضعها في زيادة تعقيد التنفيذ.

1. خياطة التكوين مباشرة في التعليمات البرمجية ، على سبيل المثال ، التعليق خارج التعليمات البرمجية غير الضرورية وإلغاء uncomment التعليمات البرمجية الضرورية أو استخدام توجيهات الترجمة الشرطية. من الواضح أن هذا الخيار يقتل جوهر إدخال المحولات ، لأنك ستحتاج إلى إعادة تجميع التطبيق ونشره لرؤية الوظيفة الجديدة. ينبغي أيضا ملاحظة اثنين من الصعوبات. أولاً ، مع هذا النهج ، سيتطلب الموظف الذي يتضمن وظائف مهارات فنية إضافية: تحرير الكود المصدري والقدرة على العمل مع نظام التحكم في الإصدار (SLE). الله يعلم ما هي المهارات ، بطبيعة الحال ، ولكن على الأرجح ، سيتعين على المبرمجين أنفسهم تضمين الوظائف. ثانياً ، ستكون الوظيفة هي نفسها في جميع العقد التي نُشر فيها هذا الإصدار من التطبيق - للاختيار بين الوظيفة القديمة والجديدة ، ستحتاج إلى موازن وعُقد متعددة مع التطبيق.
2. ضع التكوين في بيئة التطبيق ، على سبيل المثال ، في متغيرات البيئة. يبدو هذا الخيار باهظًا بعض الشيء ، لأنه محفوف بظهور التبعيات المفرطة في وقت التشغيل أو على نظام التشغيل.
3. استخدم ملفات التكوين ، والتي تعد مكانًا قياسيًا إلى حد ما لتخزين إعدادات التطبيق. سيكون عيب هذا الخيار هو الحاجة إلى الاحتفاظ بملفات التكوين بشكل منفصل بجوار كل مثيل من التطبيق. هذا العيب متأصل في الإصدار السابق.
4. الحفاظ على جدول في قاعدة البيانات التي تصف رموز التبديل للوظيفة. سيتم ضرب مثيلات التطبيق على قاعدة البيانات هذه لمعرفة ما إذا كانت الوظيفة التي تهمهم تعمل أم لا. في هذا الخيار ، يكون السجل مركزيًا (على عكس الإصدار السابق) ، لكنه يترك إمكانية تضمين الوظيفة بشكل منفصل لكل عقدة ، إذا كان هذا مدعومًا بواسطة البنية الأساسية للمحول المحدد.
5. ارفع خدمة الشبكة التي ستصل إليها مثيلات التطبيق عبر بروتوكول الشبكة المحدد. إذا كان من المفترض في الإصدار السابق أن يتم تخزين رموز التبديل على الأرجح مع كيانات مجال الموضوع ، وبالتالي فإن تكلفة الاقتراع على المفاتيح ستكون قابلة للتنبؤ بها ، فسنحصل هنا على وصول إضافي عبر الشبكة. تمثل تكلفة المعالجة الإضافية وإمكانية رفض الخدمة عيوبًا خطيرة في هذا الخيار ، ولكن بطبيعة الحال ، لا يتم حظر التخزين المؤقت. وبالنسبة للفشل ، يجب عليك توفير السلوك الافتراضي.

توصيات

فيما يتعلق باستخدام رموز التبديل ، يمكن تقديم التوصيات العامة التالية.

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

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

استخدم الاستراتيجيات بدلاً من العبارات الشرطية . إذا كان المحول سوف يعيش لفترة طويلة ، فيمكن تحسين المشغل الشرطي إلى استراتيجية وعزل المنطق القابل للتحويل صراحةً إلى شيء يتبع بشكل منفصل ويتم اختباره.

لا تجمع مفاتيح . يجب ألا تشكل تبعيات بين المفاتيح ، وقم بتجميعها وتجميعها في التسلسلات الهرمية. سيؤدي ذلك إلى تسهيل الحفاظ على الكود من خلال وظائف جديدة ودورة حياة المحولات نفسها.

دمج نقاط التبديل لوظيفة واحدة . قد يتضح أن سلوك عدة كتل برنامج في آن واحد يعتمد على نفس التبديل. إذا كان التطوير منسقًا بشكل سيئ ، فيمكن تكرار نقاط التبديل في أماكن مختلفة ، مما يؤدي إلى مزيد من الاختبارات والدعم. إذا كنت منضبطًا لمحاولة "دفع" نقاط التبديل إلى مدخل التطبيق ، فعادةً ما يتم تنفيذ هذه التوصية - لا تنتشر النقاط عبر النظام - تلقائيًا.

الفئات الرئيسية للمفاتيح

النظر في تصنيف التبديل الواردة في هذه المقالة . يعتمد على مدة "التبديل" وعدد المرات التي تتغير حالتها. تساعد مهمة التبديل إلى فئة معينة في تحديد كيفية استخدام رمز التبديل في التعليمات البرمجية وكيفية تخزين حالة رمز التبديل.

الافراج عن مفاتيح

هذا هو الرأي الرئيسي للمفاتيح. إنها تسمح لك بتركيز التطوير في فرع رئيسي واحد ، والذي ، علاوة على ذلك ، يمتد بشكل منتظم إلى عملية تجارية. بدلاً من التطوير في فرع منفصل وحقنه في الفرع الرئيسي لإصدار الإصدار المطلوب ، نقدم نقطة تبديل في الكود ، والتي تخفي الوظائف التي لم تصبح جاهزة بعد من المستخدمين. عندما تصبح جاهزة ، تقوم المفاتيح ببدء تشغيل وظائف جديدة.

تعمل مفاتيح التبديل هذه لعدة أيام أو أسابيع - بينما يستمر تطوير وتنفيذ وظائف جديدة. عند اختبار الوظيفة واعتبارها مناسبة ، يمكن إزالة المفتاح ونقطة التبديل في الكود. تتغير حالة التبديل عادةً عند إصدار إصدار جديد أو عندما يتغير تكوين التطبيق. يجوز تخزين هذا المفتاح في ملف التكوين. هناك احتمال كبير أن تكون نقطة التبديل للوظيفة الجديدة هي النقطة الوحيدة ؛ من المنطقي عدم حفرها ووضعها في شكل بيان شرطي تقليدي.

مفاتيح التجربة

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



, . , , . «», , , .

, , . , , , . , .



— . ( ), , .

, (, , ) . . - .

,

, ( , ), . .

A/B-. , .

. , .

- . , .

.إدراج وظيفة لفترة قصيرة من الوقت ، على سبيل المثال أثناء الترقية.

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

تغييرات البنية التحتية الرئيسية. على سبيل المثال ، الانتقال إلى طريقة أخرى لتخزين البيانات.

اختبار أشياء جديدة من قبل المستخدمين. تزويد المستخدمين بالقدرة على تشغيل وإيقاف الوظيفة الجديدة ، وتخصيص التطبيق لأنفسهم.

A/B-

, A/B-. A/B- - . : 1) , 2) , , 3) , . , , . ? ? «»?

, A/B-, , — . , , - - . , . , , - , .

. , . , A/B-. .

, «», «Feature Toggles, » , A/B- .

-

? : , , . . , , , . ( ).

, , « ». , (. . ), , , , , , . , , , : « ». -, , , . , .

. : - , «» — , - , ( «»). . . , , . , — , . , .

, . . : , 1 %. , , , , , , . , . , .

- , . , . , . , , .

- , , , . , . .

, - . - , , . , , , .

- — «», . - — . - .



, , , : , , , , . . , , , , , , , .

, , . , , . , ( ), .

. , () . , , — . : , !

- , . , . , . ( ) , .




«Feature Toggles, » ( !) , . .

, . , - ( , ), , . — , . , , API «» . , , — .

, . , . , « ».

. , .

.NET

. -, (), , , , , . ( ). -, , , REST API. ( ) , API .NET. -, ( ) .NET. , .

, , . , . Apache ZooKeeper , Consul etcd , Spring Cloud Config Server, .NET . , , . - , , . .

LaunchDarkly

, «» . , , , . , , Jira Visual Studio Code. . , , , 30- .

Catamorphic Co., , - .

Microsoft.FeatureManagement

Microsoft .NET Core, : -, , , -, , Azure. , , Azure App Configuration, API .

ASP.NET Core, , .

, Microsoft.FeatureManagement.

Rollout

, . , , , . ( , 14- ) REST API. , , . .

Optimizely

Optimizely — - . Rollouts , . , , («» ), . , . , . — .

Bullet train

. - — . .

Split

, . «» (A/B-).

ConfigCat

, . . , REST API. .NET . , .

Moggles

, . SQL Server. .

Unleash

, . . . ; PostgreSQL.

.NET , . , API, , .

GitLab feature flags

GitLab Unleash, GitLab , Unleash. Unleash , ( GitLab), : GitLab Premium ( GitLab ) GitLab Silver ( GitLab ).

Feature flags API in Go

API ( ), . , . Go; , , , . . : 20 2019.

Bandiera

. API . Ruby; MySQL PostgreSQL, Docker. Ruby, Node, Scala, PHP, .NET. .

Flagr

مشروع مفتوح المصدر آخر على الذهاب. المثبتة من عامل الميناء. هناك واجهة رسومية ، وكذلك عملاء لـ Ruby و Go و JavaScript و Python. إنه يوفر أدوات بسيطة مدمجة للمحاسبة من أجل استخدام الوظيفة والتجريب. يمكن تكوين كل مفتاح بمرونة وتجهيزه بتكوينه الخاص.

مكتبات العملاء

.NET , . . , 2019 . . .

Esquio

, . — , EF Core. ASP.NET Core ( Microsoft.FeatureManagement); , Azure .

FeatureSwitch

, ( FeatureSwitch.Strategies ). , . , , «/».

Toggle.Net

, . , «/».

RimDev.FeatureFlags

ASP.NET Core. , , , . — SQL Server.

استنتاج

, . . , , A/B-.

, , , .

( ) .

1. , — , , .
2. , . , .
3. , . , , , , .
4. , . . , «» .
5. , . , . , .

1. . , . : , . , , .
2. . , , . : , , , , . : ( ), .
3. . ? , ? . , , . ? ? : , .
4. — , . , . : (); ( ); .
5. — , . : (); «/».
6. , . : ; (, ).
7. . , ? : , , , ( ).