Feature Toggle — الأساسيات وأنواع المفاتيح والتطبيق
Feature Toggle هي آلية تشغيل في وقت التنفيذ لتبديل وظائف التطبيق، تتيح للمطورين إدارة توفر الميزات دون تغيير الكود أو إعادة النشر. على عكس التجميع الشرطي (ifdef)، يعمل toggle على مستوى وقت التشغيل ويمكن تغييره ديناميكيًا. وفقًا لـ Martin Fowler (2024)، فإن feature toggles هي عنصر رئيسي في trunk-based development والتسليم المستمر. Feature toggle يمنح الفرق مرونة في إدارة الإصدارات والتجارب.
الرئيسية
- Feature Toggle «مفتاح ديناميكي يتحكم في سلوك التطبيق من خلال التكوين»
- الأنواع الرئيسية: business toggles، release toggles، experiment toggles و infrastructure toggles
- Feature Toggle vs Flag «يشير toggle عادةً إلى المفاتيح الثنائية البسيطة، بينما flag إلى منصات كاملة»
- التكامل مع CI/CD يتيح التحقق الآلي واختبار toggles في كل مرحلة من مراحل pipeline
- المشكلة الرئيسية «تراكم stale toggles، التي يجب مراجعتها وإزالتها بانتظام»
ما هو Feature Toggle
Feature Toggle هي تقنية يتم فيها تغليف كود الميزة الجديدة في بناء شرطي يتحقق من قيمة معامل التكوين. إذا كانت قيمة المعامل صحيحة «فالميزة الجديدة نشطة، وإذا كانت خاطئة «يتم تشغيل الكود القديم. الفرق الرئيسي عن feature flag هو أن toggle هو مفتاح ثنائي يعمل على مبدأ تشغيل/إيقاف، دون قواعد استهداف معقدة أو توزيع حركة المرور.
التعريف ومبدأ العمل
يتم تنفيذ feature toggle كبناء if بسيط حول الميزة الجديدة. يتم تخزين قيمة toggle في تكوين التطبيق «متغيرات البيئة، ملف JSON، أو قاعدة بيانات. عند بدء تشغيل التطبيق، يقوم بتحميل التكوين واستخدامه لاتخاذ قرارات حول رؤية الميزات. في أبسط الحالات، يتطلب تغيير قيمة toggle إعادة تشغيل التطبيق، ولكن في أنظمة الإنتاج، تدعم toggles عادة إعادة التحميل الساخن عبر خادم تكوين خارجي أو API.
مثال على toggle بسيط
دعنا نلقي نظرة على تنفيذ feature toggle في JavaScript (Node.js). يتم تخزين toggle في ملف تكوين JSON ويتم تحميله عند بدء تشغيل الخادم. يتحقق الوسيط (middleware) من قيمة toggle قبل توجيه الطلب إلى المعالج الجديد أو القديم. يسمح هذا التنفيذ بإضافة ميزات جديدة إلى الفرع الرئيسي للكود دون التأثير على الإصدار الحالي من API.
js
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});أنواع Feature Toggles
بيت هودجسون من ThoughtWorks يحدد ثلاثة أنواع رئيسية من feature toggles، مصنفة حسب عمرها الافتراضي والغرض من الاستخدام. يساعد التحديد الصحيح لنوع toggle في اختيار آلية التخزين المناسبة وعملية الإدارة. دعنا نلقي نظرة على كل نوع في سياق تطوير التطبيقات المحمولة.
Business و Release Toggles
Business toggles هي المفاتيح الأطول عمرًا. تدير قواعد العمل المتاحة فقط لفئات معينة من المستخدمين (الميزات المميزة، الخصائص الإقليمية). يمكن أن تعيش هذه toggles لسنوات وعادة ما يكون لها منطق أكثر تعقيدًا من التشغيل/الإيقاف الثنائي. Release toggles هي مفاتيح مؤقتة لإخفاء الميزات غير المكتملة. دورة حياتها تتراوح من بضعة أيام إلى بضعة أسابيع. بمجرد اكتمال الميزة، يتم إزالة release toggle من الكود. هذه toggles هي أساس trunk-based development، مما يسمح للمطورين بالدمج في الفرع الرئيسي دون انتظار اكتمال جميع الميزات.
Experiment و Infrastructure Toggles
Experiment toggles تستخدم لاختبارات A/B والتوزيع التدريجي. على عكس release toggles، تدعم experiment toggles التوزيع النسبي للمستخدمين والتكامل مع أنظمة التحليلات. يمكن أن تعيش لفترة أطول من release toggles (حتى عدة أشهر)، ولكن يجب أيضًا إزالتها بعد انتهاء التجربة. Infrastructure toggles هي مفاتيح لإدارة تغييرات البنية التحتية: ترحيل قواعد البيانات، الانتقال إلى مزود API جديد، تغيير خوارزميات التخزين المؤقت. تتطلب هذه toggles اهتمامًا خاصًا بالاختبار، لأن تبديلها يؤثر على استقرار الخدمة بأكملها.
| نوع toggle | المدة | الجمهور | مثال |
|---|---|---|---|
| Business | أشهر-سنوات | حسب الأدوار/المناطق | ميزات مميزة |
| Release | أيام-أسابيع | مطورون/QA | شاشة غير مكتملة |
| Experiment | أسابيع-أشهر | % من المستخدمين | اختبار A/B للواجهة |
| Infrastructure | أيام-أسابيع | داخلي | ترحيل قاعدة البيانات |
Feature Toggle vs Feature Flag
على الرغم من أن المصطلحين «feature toggle» و «feature flag» يستخدمان غالبًا بالتبادل، إلا أن هناك اختلافات مفاهيمية بينهما. يساعد فهم هذه الاختلافات في اختيار الأداة المناسبة لمهمة محددة وتجنب الارتباك في الفريق. دعنا نلقي نظرة على الاختلافات الرئيسية وحالات استخدام كل نهج.
الاختلافات في النهج
Feature toggle هو في المقام الأول آلية تقنية: مفتاح ثنائي مضمن في كود التطبيق. يتم إدارة toggle من خلال التكوين ولا يتطلب بنية تحتية خارجية. Feature flag هو مفهوم أوسع يشمل منصة إدارة: واجهة مستخدم للتكوين، SDK للتكامل، مراقبة الاستخدام، تحليلات وتدقيق. تدعم flags قواعد استهداف معقدة (حسب المنطقة، الإصدار، الجهاز)، تجارب A/B، والإزالة التلقائية. يمكن القول أن feature flag هو تطور feature toggle: تبدأ الفرق بمفاتيح تكوين بسيطة وتنتقل إلى منصة متخصصة مع نموها.
متى يكون toggle كافيًا
للفرق الصغيرة والمشاريع ذات خدمة واحدة أو بنية متجانسة، فإن toggles التكوين البسيطة كافية تمامًا. إذا كان لديك 5–10 مطورين و1–2 toggles نشطة في وقت واحد، فإن منصة خارجية ستكون مبالغًا فيها. تصبح منصات feature flags (LaunchDarkly، Unleash) ضرورية عندما يتجاوز عدد flags النشطة 20–30، أو كان الفريق يضم 20+ مطورًا، أو كان هناك حاجة للتحكم الدقيق في الوصول لشرائح مختلفة من المستخدمين. بالنسبة للتطبيقات المحمولة، حيث تستغرق تحديثات العميل أيامًا، توفر منصات feature flags ميزة إضافية «القدرة على تغيير سلوك التطبيق دون نشر إصدار جديد.
أدوات الإدارة
يعتمد اختيار أداة إدارة feature toggles على حجم الفريق، مجموعة التقنيات المستخدمة ومتطلبات الأمان. دعنا نلقي نظرة على الخيارات من ملفات التكوين البسيطة إلى منصات الإدارة على مستوى المؤسسات، بما في ذلك البدائل مفتوحة المصدر.
التكامل مع CI/CD
يجب أن تكون feature toggles مواطنين من الدرجة الأولى في pipeline CI/CD. في مرحلة البناء، يتحقق pipeline من أن جميع release toggles المقرر إزالتها في السباق الحالي قد تمت إزالتها بالفعل من الكود. في مرحلة الاختبار، يتم تشغيل اختبارات مصفوفية بمجموعات مختلفة من toggles. في مرحلة النشر، يقوم النظام تلقائيًا بمزامنة تكوين toggles مع بيئة الإنتاج. يتيح التكامل مع PagerDuty أو Opsgenie إنشاء تنبيهات عند اكتشاف stale toggles أو عند تجاوز العدد المسموح به من toggles النشطة.
الحلول الشائعة
للسيناريوهات البسيطة، يكفي ملف تكوين JSON في Git مع مراجعة الكود على التغييرات. خيار أكثر تقدمًا هو Togglz (Java) أو Gofeature (Go) «مكتبات تضيف واجهة مستخدم بسيطة لإدارة toggles. لأنظمة الإنتاج، يوصى باستخدام Unleash (مفتوح المصدر) مع SDK لجميع اللغات ودعم استراتيجيات التنشيط، أو Flagsmith مع اختبار A/B مدمج. يظل LaunchDarkly هو المعيار للمشاريع المؤسسية ذات متطلبات التدقيق والامتثال العالية. للتطبيقات المحمولة، توفر جميع الحلول SDK أصلية مع التخزين المؤقت والوضع دون اتصال.
الديون التقنية والإزالة
تعتبر feature toggles أداة ذات حدين. بدون انضباط في الإدارة، تتحول إلى ديون تقنية تبطئ التطوير وتزيد من تعقيد الكود. وفقًا لدراسة CodeScene (2024)، 35–50% من قواعد الكود تحتوي على stale toggles «مفاتيح تبقى في الكود بعد اكتمال التوزيع. دعنا نلقي نظرة على استراتيجيات منع وإزالة هذه الديون.
إزالة toggles
تتكون عملية إزالة feature toggle من أربع خطوات. الأولى: التأكد من أن toggle مفعل لـ 100% من الجمهور أو معطل لـ 0% (اعتمادًا على فرع الكود الذي يجب أن يبقى). الثانية: إزالة جميع الفحوص الشرطية لـ toggle من الكود، مع ترك الفرع الذي يجب أن يكون سلوك الإنتاج فقط. الثالثة: إزالة تعريف toggle من نظام التخزين (التكوين، قاعدة البيانات، أو المنصة). الرابعة: تشغيل الاختبارات للتأكد من أن الإزالة لم تكسر الوظيفة. يجب أن يكون لكل toggle مالك وتاريخ إزالة مخطط له، مسجلين عند إنشاء المفتاح.
أتمتة التدقيق
التدقيق اليدوي لـ toggles غير فعال عند النطاق الذي يتجاوز 50 مفتاحًا. تعتمد الأتمتة على ثلاثة مبادئ: التحقق في CI (stale toggles تمنع الدمج)، المراقبة (لوحة بيانات تظهر عمر كل toggle وحالته)، التنبيهات (إخطار المالك إذا لم يتغير toggle لمدة N يومًا). يمكن لأدوات التحليل الثابت للكود (SonarQube، إضافة ESLint) اكتشاف toggles التي تكون دائمًا مفعلة أو دائمًا معطلة في الكود «علامة واضحة على stale toggle. الفحص النهائي هو مراجعة الكود، حيث يجب على المراجع التأكد من أن toggle الجديد ضروري بالفعل وأن فرع الكود القديم سيتم إزالته.
go
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}الأسئلة الشائعة
كيف يختلف feature toggle عن feature flag؟
غالبًا ما يُستخدم المصطلحان بالتبادل، ولكن تقنيًا feature toggle هو مفتاح ثنائي في الكود (شرط if يتحقق من قيمة التكوين). Feature flag هو مفهوم أوسع يشمل منصة إدارة بواجهة مستخدم، SDK، تحليلات وقواعد استهداف معقدة. لا يتطلب toggle بنية تحتية خارجية؛ بينما flag يتطلبها عادةً.
كم مرة يجب إزالة toggles القديمة؟
يجب إزالة release toggles خلال 1–2 أسبوع بعد اكتمال التوزيع. experiment toggles «مباشرة بعد انتهاء اختبار A/B. business toggles تتطلب تدقيقًا منتظمًا (ربع سنوي). يوصى بإعداد فحص CI يمنع الدمج إذا أضاف PR toggle جديدًا دون مهمة إزالة في متتبع المهام.
هل يمكن استخدام toggles للتطبيقات المحمولة؟
نعم، تُستخدم feature toggles بنشاط في تطوير التطبيقات المحمولة. الأداة الرئيسية هي Firebase Remote Config، التي تتيح إدارة المفاتيح ديناميكيًا دون نشر إصدار جديد من التطبيق. البدائل: SDK لـ LaunchDarkly لأنظمة iOS/Android، SDK لـ Unleash، خادم toggle مخصص مع REST API. من المهم تنفيذ التخزين المؤقت للقيم للعمل في وضع عدم الاتصال.
كيفية اختبار الكود باستخدام feature toggles؟
الطريقة الرئيسية هي الاختبار المصفوفي: تشغيل جميع الاختبارات مع toggle مفعل ومعطل. لـ N toggles، يتطلب الاختبار المصفوفي الكامل 2^n تشغيل، لذلك في الممارسة العملية يتم اختيار المجموعات الحرجة. يجب أن تحاكي اختبارات الوحدة قيمة toggle. تتحقق اختبارات التكامل من سيناريوهات محددة. يتم إضافة خطوة في CI تشغل الاختبارات بمجموعة عشوائية من toggles لاكتشاف التفاعلات غير المتوقعة.
ما هي مخاطر feature toggles؟
المخاطر الرئيسية: 1) stale toggles «الكود بكلتا الفرعين (مفعل/معطل) يصبح معقدًا ويصعب صيانته؛ 2) التعقيد التوافقي للاختبار «كل toggle يضاعف عدد الحالات؛ 3) كود ميت «الفرع القديم يبقى في الكود بعد أن يصبح toggle مفعلًا بشكل دائم؛ 4) الأمان «المفاتيح التي تتحكم في الوصول تخلق ثغرات عند التكوين الخاطئ. جميع المخاطر قابلة للإدارة مع الانضباط والأتمتة.
الخلاصة
- Feature Toggle «مفتاح وظيفي ثنائي يتم التحكم فيه من خلال تكوين التطبيق»
- الأنواع الرئيسية: business (أشهر-سنوات)، release (أيام-أسابيع)، experiment (أسابيع-أشهر)، infrastructure (أيام-أسابيع)
- Feature Toggle vs Flag «toggle أبسط (شرط if + تكوين)، flag يشمل منصة إدارة كاملة»
- التكامل مع CI/CD إلزامي: التحقق من stale toggles، الاختبارات المصفوفية، مزامنة التكوين
- Stale toggles «الخطر الرئيسي: 35–50% من قواعد الكود تحتوي على مفاتيح غير مستخدمة»
- إزالة toggle تتطلب عملية: تأكيد الحالة، إزالة الكود، إزالة التكوين، تشغيل الاختبارات
- أتمتة التدقيق عبر CI، لوحات البيانات والتحليل الثابت للكود تمنع تراكم الديون التقنية
سنقوم بتطوير تطبيق جوال جاهز
تقدم IT Sectr تطبيقات iOS وAndroid للشركات الناشئة والشركات منذ عام 2017. سوف نقدم لك النصح ونقترح أفضل حل.
اقرأ أيضًا