Feature Toggle ایک رن ٹائم میکانزم ہے جو ایپلیکیشن کی فعالیت کو آن اور آف کرنے کے لیے ہے، جس سے ڈویلپرز کوڈ تبدیل کیے یا دوبارہ تعینات کیے بغیر فیچر کی دستیابی کا انتظام کر سکتے ہیں۔ مشروط کمپائلیشن (ifdef) کے برعکس، toggle رن ٹائم کی سطح پر کام کرتا ہے اور متحرک طور پر تبدیل کیا جا سکتا ہے۔ Martin Fowler (2024) کے مطابق، feature toggles ٹرنک پر مبنی ڈویلپمنٹ اور مسلسل ترسیل کا ایک اہم عنصر ہیں۔ Feature toggle ٹیموں کو ریلیز اور تجربات کے انتظام میں لچک فراہم کرتا ہے۔
اہم نکات
Feature Toggle ایک تکنیک ہے جس میں نئے فیچر کے کوڈ کو مشروط تعمیر میں لپیٹا جاتا ہے جو کنفیگریشن پیرامیٹر کی قدر چیک کرتی ہے۔ اگر پیرامیٹر درست ہے — تو نئی فعالیت فعال ہے، اگر غلط ہے — تو پرانا کوڈ چلتا ہے۔ فیچر فلیگ سے بنیادی فرق یہ ہے کہ toggle ایک بائنری سوئچ ہے جو آن/آف اصول پر کام کرتا ہے، بغیر پیچیدہ ہدف بندی کے قواعد یا ٹریفک کی تقسیم کے۔
فیچر ٹوگل کو نئی فعالیت کے گرد ایک سادہ if-تعمیر کے طور پر لاگو کیا جاتا ہے۔ Toggle کی قدر ایپلیکیشن کنفیگریشن — ماحولیاتی متغیرات، JSON فائل یا ڈیٹابیس میں محفوظ کی جاتی ہے۔ جب ایپلیکیشن شروع ہوتی ہے، تو وہ کنفیگریشن لوڈ کرتی ہے اور فیچر کی نمائش کے بارے میں فیصلے کرنے کے لیے استعمال کرتی ہے۔ سادہ ترین صورت میں، toggle کی قدر تبدیل کرنے کے لیے ایپلیکیشن کو دوبارہ شروع کرنے کی ضرورت ہوتی ہے، لیکن پروڈکشن سسٹمز میں toggles عام طور پر بیرونی کنفیگ سرور یا API کے ذریعے ہاٹ ریلوڈ کو سپورٹ کرتے ہیں۔
آئیے JavaScript (Node.js) میں فیچر ٹوگل کے نفاذ کو دیکھتے ہیں۔ Toggle ایک JSON کنفیگ میں محفوظ ہوتا ہے اور سرور شروع ہونے پر لوڈ ہوتا ہے۔ Middleware درخواست کو نئے یا پرانے ہینڈلر پر بھیجنے سے پہلے toggle کی قدر چیک کرتا ہے۔ یہ نفاذ موجودہ API ورژن کو توڑے بغیر مرکزی کوڈ برانچ میں نئی فعالیت شامل کرنے کی اجازت دیتا ہے۔
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);
});
ThoughtWorks کے پیٹ ہوجسن feature toggles کی تین بنیادی اقسام بتاتے ہیں، انہیں زندگی کی مدت اور استعمال کے مقصد کے لحاظ سے درجہ بندی کرتے ہیں۔ Toggle کی قسم کی صحیح شناخت مناسب ذخیرہ کرنے کے طریقہ کار اور انتظامی عمل کو منتخب کرنے میں مدد دیتی ہے۔ آئیے موبائل ڈویلپمنٹ کے تناظر میں ہر قسم کو دیکھتے ہیں۔
Business toggles سب سے طویل عرصے تک چلنے والے سوئچ ہیں۔ وہ کاروباری قواعد کا انتظام کرتے ہیں جو صرف بعض صارف زمروں (پریمیم فیچرز، علاقائی خصوصیات) کے لیے دستیاب ہوتے ہیں۔ ایسے toggles سالوں تک زندہ رہ سکتے ہیں اور عام طور پر بائنری آن/آف سے زیادہ پیچیدہ منطق رکھتے ہیں۔ Release toggles نامکمل فعالیت کو چھپانے کے لیے عارضی سوئچ ہیں۔ ان کا لائف سائیکل چند دنوں سے چند ہفتوں تک ہوتا ہے۔ فعالیت مکمل ہونے کے بعد، release toggle کو کوڈ سے ہٹا دیا جاتا ہے۔ یہ toggles ٹرنک پر مبنی ڈویلپمنٹ کی بنیاد ہیں، جو ڈویلپرز کو تمام فعالیت مکمل ہونے کا انتظار کیے بغیر مرکزی برانچ میں کمٹ کرنے کی اجازت دیتے ہیں۔
Experiment toggles A/B ٹیسٹنگ اور بتدریج رول آؤٹ کے لیے استعمال ہوتے ہیں۔ Release toggles کے برعکس، experiment toggles فیصد پر مبنی صارف کی تقسیم اور تجزیاتی نظاموں کے ساتھ انضمام کی حمایت کرتے ہیں۔ وہ release toggles سے زیادہ عرصہ (کئی مہینوں تک) زندہ رہ سکتے ہیں لیکن تجربہ ختم ہونے کے بعد ہٹا دیے جانے چاہئیں۔ Infrastructure toggles بنیادی ڈھانچے میں تبدیلیوں کے انتظام کے لیے سوئچ ہیں: ڈیٹابیس مائیگریشن، نئے API فراہم کنندہ پر سوئچ کرنا، کیشنگ الگورتھم تبدیل کرنا۔ ان toggles کو ٹیسٹنگ پر خصوصی توجہ درکار ہوتی ہے، کیونکہ ان کا سوئچ کرنا پوری سروس کے استحکام کو متاثر کرتا ہے۔
| Toggle کی قسم | مدت | سامعین | مثال |
|---|---|---|---|
| Business | مہینے-سال | کردار/علاقہ کے مطابق | پریمیم فیچرز |
| Release | دن-ہفتے | ڈویلپرز/QA | نامکمل سکرین |
| Experiment | ہفتے-مہینے | % صارفین | انٹرفیس A/B ٹیسٹ |
| Infrastructure | دن-ہفتے | داخلی | DB مائیگریشن |
اگرچہ “feature toggle” اور “feature flag” کی اصطلاحات اکثر ایک دوسرے کے بدلے استعمال ہوتی ہیں، لیکن ان کے درمیان تصوراتی فرق موجود ہے۔ ان فرقوں کو سمجھنا کسی مخصوص کام کے لیے صحیح آلہ منتخب کرنے اور ٹیم میں الجھن سے بچنے میں مدد دیتا ہے۔ آئیے ہر طریقہ کار کے کلیدی فرق اور استعمال کے معاملات کو دیکھتے ہیں۔
Feature toggle بنیادی طور پر ایک تکنیکی میکانزم ہے: ایپلیکیشن کوڈ میں سرایت شدہ بائنری سوئچ۔ Toggle کنفیگریشن کے ذریعے منظم کیا جاتا ہے اور بیرونی بنیادی ڈھانچے کی ضرورت نہیں ہوتی۔ Feature flag ایک وسیع تر تصور ہے جس میں ایک انتظامی پلیٹ فارم شامل ہے: کنفیگریشن کے لیے UI، انضمام کے لیے SDK، استعمال کی نگرانی، تجزیات اور آڈیٹنگ۔ Flags پیچیدہ ہدف بندی کے قواعد (علاقہ، ورژن، ڈیوائس کے مطابق)، A/B تجربات اور خودکار ہٹانے کی حمایت کرتے ہیں۔ آپ کہہ سکتے ہیں کہ فیچر فلیگ فیچر ٹوگل کا ارتقا ہے: ٹیمیں سادہ کنفیگریشن سوئچز سے شروع ہوتی ہیں اور بڑھنے پر ایک خصوصی پلیٹ فارم پر منتقل ہوتی ہیں۔
چھوٹی ٹیموں اور ایک ہی سروس یا یک سنگی والے پروجیکٹس کے لیے، سادہ کنفیگریشن toggles مکمل طور پر کافی ہیں۔ اگر آپ کے پاس 5–10 ڈویلپرز اور ایک وقت میں 1–2 فعال toggles ہیں، تو بیرونی پلیٹ فارم ضرورت سے زیادہ ہوگا۔ Feature flag پلیٹ فارمز (LaunchDarkly، Unleash) اس وقت ضروری ہو جاتے ہیں جب فعال flags کی تعداد 20–30 سے تجاوز کر جائے، ٹیم میں 20+ ڈویلپرز ہوں، یا مختلف صارف حصوں کے لیے باریک بینی سے رسائی کنٹرول درکار ہو۔ موبائل ایپلیکیشنز کے لیے، جہاں کلائنٹ اپ ڈیٹس میں دن لگتے ہیں، فیچر فلیگ پلیٹ فارمز ایک اضافی فائدہ دیتے ہیں — نیا ورژن شائع کیے بغیر ایپلیکیشن کے رویے کو تبدیل کرنے کی صلاحیت۔
Feature toggle انتظامی آلے کا انتخاب ٹیم کے سائز، ٹیکنالوجی اسٹیک اور سیکیورٹی کی ضروریات پر منحصر ہے۔ آئیے سادہ کنفیگریشن فائلوں سے لے کر انٹرپرائز گریڈ انتظامی پلیٹ فارمز تک، اوپن سورس متبادلات سمیت اختیارات کو دیکھتے ہیں۔
Feature toggles کو CI/CD پائپ لائن کا اول درجہ شہری ہونا چاہیے۔ بلڈ مرحلے میں، پائپ لائن چیک کرتی ہے کہ موجودہ اسپرنٹ میں ہٹانے کے لیے طے شدہ تمام release toggles واقعی کوڈ سے ہٹا دیے گئے ہیں۔ ٹیسٹنگ مرحلے میں، مختلف toggle مجموعات کے ساتھ میٹرکس ٹیسٹ چلائے جاتے ہیں۔ ڈیپلائے مرحلے میں، سسٹم خود بخود toggle کنفیگریشن کو پروڈکشن ماحول کے ساتھ ہم آہنگ کرتا ہے۔ PagerDuty یا Opsgenie کے ساتھ انضمام stale toggles کی نشاندہی ہونے پر یا فعال toggles کی اجازت شدہ تعداد سے تجاوز کرنے پر الرٹ بنانے کی اجازت دیتا ہے۔
سادہ منظرناموں کے لیے، تبدیلیوں پر کوڈ جائزہ کے ساتھ Git میں ایک JSON کنفیگ کافی ہے۔ زیادہ اعلیٰ اختیار Togglz (Java) یا Gofeature (Go) ہے — لائبریریاں جو toggle انتظام کے لیے کم سے کم UI شامل کرتی ہیں۔ پروڈکشن سسٹمز کے لیے، تمام زبانوں کے لیے SDK اور ایکٹیویشن حکمت عملی کی حمایت کے ساتھ Unleash (اوپن سورس)، یا بلٹ ان A/B ٹیسٹنگ کے ساتھ Flagsmith تجویز کیا جاتا ہے۔ LaunchDarkly اعلی آڈٹ اور تعمیل کی ضروریات والے انٹرپرائز پروجیکٹس کے لیے معیار بنی ہوئی ہے۔ موبائل ایپلیکیشنز کے لیے، تمام حل کیشنگ اور آف لائن موڈ کے ساتھ مقامی SDK فراہم کرتے ہیں۔
Feature toggles دو دھاری تلوار ہیں۔ انتظامی نظم و ضبط کے بغیر، یہ تکنیکی قرض میں تبدیل ہو جاتے ہیں جو ترقی کو سست کرتا ہے اور کوڈ کی پیچیدگی بڑھاتا ہے۔ CodeScene تحقیق (2024) کے مطابق، 35–50% کوڈ بیسز میں stale toggles — سوئچ جو رول آؤٹ مکمل ہونے کے بعد بھی کوڈ میں رہتے ہیں — پائے جاتے ہیں۔ آئیے اس طرح کے قرض کو روکنے اور ختم کرنے کی حکمت عملیوں کو دیکھتے ہیں۔
فیچر ٹوگل ہٹانے کا عمل چار مراحل پر مشتمل ہے۔ پہلا: یقینی بنائیں کہ toggle 100% سامعین کے لیے فعال یا 0% کے لیے غیر فعال ہے (اس بات پر منحصر ہے کہ کوڈ کی کون سی شاخ رہنی چاہیے)۔ دوسرا: کوڈ سے تمام مشروط toggle جانچیں ہٹا دیں، صرف وہی شاخ چھوڑیں جو پروڈکشن کا رویہ ہونی چاہیے۔ تیسرا: ذخیرہ کرنے کے نظام (کنفیگ، ڈیٹابیس یا پلیٹ فارم) سے toggle کی تعریف ہٹا دیں۔ چوتھا: اس بات کی تصدیق کے لیے ٹیسٹ چلائیں کہ ہٹانے نے فعالیت کو نہیں توڑا۔ ہر toggle کا ایک مالک اور منصوبہ بند ہٹانے کی تاریخ ہونی چاہیے، جو سوئچ بناتے وقت ریکارڈ کی جائے۔
دستی toggle آڈٹ 50 سوئچ سے زیادہ کے پیمانے پر غیر موثر ہے۔ آٹومیشن تین اصولوں پر مبنی ہے: CI جانچ (stale toggles مرج کو روکتے ہیں)، نگرانی (ایک ڈیش بورڈ جو ہر toggle کی عمر اور حیثیت دکھاتا ہے)، الرٹس (مالک کو مطلع کرنا اگر toggle N دنوں میں تبدیل نہیں ہوا)۔ جامد کوڈ تجزیہ کے اوزار (SonarQube، ESLint پلگ ان) کوڈ میں ہمیشہ آن یا ہمیشہ آف رہنے والے toggles کا پتہ لگا سکتے ہیں — stale toggle کی واضح علامت۔ حتمی جانچ کوڈ کا جائزہ ہے، جہاں جائزہ لینے والے کو یہ تصدیق کرنی چاہیے کہ نیا toggle واقعی ضروری ہے اور پرانی کوڈ شاخ ہٹا دی جائے گی۔
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 کوڈ میں ایک بائنری سوئچ ہے (ایک if-شرط جو کنفیگ ویلیو چیک کرتی ہے)۔ Feature flag ایک وسیع تر تصور ہے جس میں UI، SDK، تجزیات اور پیچیدہ ہدف بندی کے قواعد کے ساتھ ایک انتظامی پلیٹ فارم شامل ہے۔ Toggle کو بیرونی بنیادی ڈھانچے کی ضرورت نہیں؛ flag کو عام طور پر ہوتی ہے۔
Release toggles کو رول آؤٹ مکمل ہونے کے 1–2 ہفتوں کے اندر ہٹا دینا چاہیے۔ Experiment toggles — A/B ٹیسٹ ختم ہونے کے فوراً بعد۔ Business toggles کو باقاعدہ آڈٹ (سہ ماہی) کی ضرورت ہوتی ہے۔ یہ سفارش کی جاتی ہے کہ CI جانچ قائم کی جائے جو مرج کو روکے اگر PR ٹاسک ٹریکر میں ہٹانے کے کام کے بغیر نیا toggle شامل کرے۔
ہاں، feature toggles موبائل ڈویلپمنٹ میں فعال طور پر استعمال ہوتے ہیں۔ بنیادی آلہ Firebase Remote Config ہے، جو ایپلیکیشن کا نیا ورژن شائع کیے بغیر سوئچز کو متحرک طور پر منظم کرنے کی اجازت دیتا ہے۔ متبادل: iOS/Android کے لیے LaunchDarkly SDK، Unleash SDK، REST API کے ساتھ حسب ضرورت toggle سرور۔ آف لائن موڈ میں کام کرنے کے لیے قدروں کی کیشنگ کو لاگو کرنا ضروری ہے۔
بنیادی طریقہ میٹرکس ٹیسٹنگ ہے: toggle آن اور آف دونوں حالتوں میں تمام ٹیسٹ چلانا۔ N toggles کے لیے، مکمل میٹرکس ٹیسٹنگ کے لیے 2^n رنز درکار ہوتے ہیں، لہذا عملی طور پر اہم مجموعے منتخب کیے جاتے ہیں۔ یونٹ ٹیسٹ کو toggle ویلیو کو موک کرنا چاہیے۔ انٹیگریشن ٹیسٹ مخصوص منظرناموں کی تصدیق کرتے ہیں۔ CI میں ایک مرحلہ شامل کیا جاتا ہے جو غیر متوقع تعاملات کا پتہ لگانے کے لیے بے ترتیب toggle مجموعہ کے ساتھ ٹیسٹ چلاتا ہے۔
بنیادی خطرات: 1) stale toggles — دونوں شاخوں (آن/آف) والا کوڈ پیچیدہ اور برقرار رکھنا مشکل ہو جاتا ہے؛ 2) ٹیسٹنگ کی مجموعاتی پیچیدگی — ہر toggle حالتوں کی تعداد کو دگنا کر دیتا ہے؛ 3) مردہ کوڈ — پرانی شاخ کوڈ میں رہ جاتی ہے جب toggle مستقل طور پر فعال ہو جاتا ہے؛ 4) سیکیورٹی — رسائی کو کنٹرول کرنے والے سوئچ غلط کنفیگریشن پر کمزوریاں پیدا کرتے ہیں۔ تمام خطرات نظم و ضبط اور آٹومیشن سے قابل انتظام ہیں۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں