محفوظ، بتدریج ریلیز کے لیے فیچر فلیگز کو کیسے نافذ کیا جائے۔

فیچر جھنڈے آپ کی ٹیم کے تعیناتی ہتھیاروں میں سب سے زیادہ طاقتور ٹولز میں سے ایک ہیں۔ وہ الگ تعیناتی سے رہائیاس کا مطلب یہ ہے کہ آپ کی CI/CD پائپ لائن ہر انضمام کے ساتھ کوڈ کو پروڈکشن سرورز پر دھکیل سکتی ہے، لیکن آپ کے صارفین کو نیا رویہ تبھی نظر آئے گا جب آپ واضح طور پر سوئچ کو پلٹائیں گے۔

ایک تعیناتی ایک تکنیکی واقعہ ہے، جبکہ رہائی ایک پروڈکٹ کا فیصلہ ہے۔ یہ علیحدگی اس دستاویز میں باقی سب کچھ ممکن بناتی ہے۔

تاہم، ناقص طور پر نافذ کردہ جھنڈے تکنیکی قرض، ڈراؤنے خوابوں کی جانچ اور رن ٹائم پیچیدگی کا سبب بنتے ہیں۔ اس آرٹیکل میں، آپ فیچر فلیگ کو لاگو کرنے کے لیے کلیدی نمونے سیکھیں گے، سادہ بولین ٹوگلز سے لے کر فیصد پر مبنی رول آؤٹس اور یوزر سیگمنٹیشن کے ساتھ ساتھ لائف سائیکل مینجمنٹ اور اس سے بچنے کے لیے اینٹی پیٹرنز۔ صحیح طریقہ یہ ہے:

انڈیکس

ہمیں فیچر جھنڈوں کی ضرورت کیوں ہے؟

بنیادی قدر کی تجویز سادہ ہے۔ جب چاہیں تعینات کریں، اور تیار ہونے پر چھوڑ دیں۔

• تعیناتی کے خطرے کو کم کریں: اپنے کوڈ کو جھنڈے کے پیچھے بھیجیں، X% صارفین کو چالو کریں، اس کی نگرانی کریں، اور اس کی پیمائش کریں۔

• ٹرنک پر مبنی ترقی کو فعال کریں: اڈے سے بہتی ہوئی کوئی طویل مدتی خصوصیت کی شاخیں نہیں ہیں۔

• تائید شدہ تجربات: ارتکاب کرنے سے پہلے حقیقی صارفین کے ساتھ A/B ٹیسٹنگ فنکشن

• کِل سوئچ آفرز: اگر پیداوار میں کوئی مسئلہ پیدا ہوتا ہے، تو ہم فیچر کو فوری طور پر غیر فعال کر دیتے ہیں۔

نمایاں پرچم کی قسم

تمام جھنڈے ایک ہی مقصد کی تکمیل نہیں کرتے۔ اقسام کو سمجھنے سے آپ کو ان کے لائف سائیکل کو منظم کرنے میں مدد ملے گی۔

زمرہ	مقصد	زندگی	ہاں
رہائی	گیٹ کا نامکمل فنکشن	چند دنوں سے چند ہفتوں تک	نئی ادائیگی کا بہاؤ
تجربہ	A/B ٹیسٹنگ کی مختلف حالتیں۔	چند ہفتوں سے چند مہینوں تک	قیمتوں کا تعین صفحہ لے آؤٹ
کام	آپریشنل سلوک کنٹرول	مستقل	شرح کی حد ٹوگل
اجازت	اجازت پر مبنی رسائی	مستقل	پریمیم ٹائر کی خصوصیات

ریلیز کے جھنڈے مختصر مدت کے لیے ہونے چاہئیں۔ اگر ہر کوئی تین مہینوں سے جھنڈا تھامے ہوئے ہے تو یہ جھنڈا نہیں ہے۔ یہ ڈیڈ کوڈ ہے جو کسی کو الجھانے کا انتظار کر رہا ہے۔

پیٹرن 1: سادہ بولین ٹوگل

یہ سب سے بنیادی نمونہ ہے۔ اندرونی خصوصیات یا کِل سوئچز کے لیے بہت اچھا ہے۔

interface FeatureFlags {
  newDashboard: boolean;
  experimentalSearch: boolean;
  maintenanceMode: boolean;
}

function getFlags(userId: string): FeatureFlags {
  // Fetch from your flag provider (LaunchDarkly, Unleash, or similar)
  return flagProvider.evaluate(userId);
}

// Usage
if (flags.newDashboard) {
  return ;
}
return ;

اوپر کے کوڈ میں getFlags فنکشن ہے userId جھنڈا فراہم کرنے والے سے اس صارف کے لیے تمام جھنڈوں کا جائزہ لینے کو کہیں۔ نتیجہ ایک سادہ آبجیکٹ ہے جہاں ہر کلید پرچم کا نام ہے اور ہر قدر یہ ہے: true یا false.

کال سائٹ یہ فیصلہ کرنے سے پہلے جھنڈے کی جانچ کرتی ہے کہ کون سا جزو پیش کرنا ہے۔ اگر newDashboard ہے trueصارفین ایک نیا تجربہ دیکھتے ہیں۔ پھر false یا، اگر رسائی پہلے سے نہیں دی گئی ہے تو میراث تک رسائی دی جائے گی۔

پرچم فراہم کرنے والا تمام اہدافی منطق کو سنبھالتا ہے۔ درخواست کا کوڈ اس کے مطابق نتائج اور شاخوں کو پڑھتا ہے۔

اس پیٹرن کو اندرونی ٹولز، کِل سوئچز، اور تمام یا کچھ بھی نہیں خصوصیات کے لیے استعمال کریں۔

تاہم، یہ بات ذہن میں رکھیں کہ بولین جھنڈے بتدریج رول آؤٹ کنٹرول فراہم نہیں کرتے ہیں۔ آپ یا تو آن یا آف ہیں۔ اس لیے اسے احتیاط کے ساتھ استعمال کریں۔

پیٹرن 2: فیصد پر مبنی رول آؤٹ

اس پیٹرن کو استعمال کرنے والوں کے ایک مخصوص فیصد تک پہنچنے کے لیے استعمال کریں، جیسے جیسے اعتماد میں اضافہ ہوتا ہے رفتہ رفتہ بڑھتا جاتا ہے۔

interface RolloutConfig {
  percentage: number; // 0-100
  sticky: boolean;    // Same user always gets same result
}

function isEnabled(
  flagName: string,
  userId: string,
  config: RolloutConfig
): boolean {
  if (!config.sticky) {
    return Math.random() * 100 < config.percentage;
  }

  // Deterministic hash ensures consistency per user
  const hash = deterministicHash(`${flagName}:${userId}`);
  return (hash % 100) < config.percentage;
}

function deterministicHash(input: string): number {
  let hash = 0;
  for (const char of input) {
    hash = ((hash << 5) - hash + char.charCodeAt(0)) | 0;
  }
  return Math.abs(hash);
}

اوپر والے کوڈ میں، isEnabled پرچم کا نام، صارف ID، اور ریلیز کنفیگریشن لیتا ہے اور بولین لوٹاتا ہے۔ جب sticky ہے falseیہ کال کرتا ہے Math.random()اس کا مطلب ہے کہ ایک ہی صارف کو ہر درخواست سے مختلف نتائج مل سکتے ہیں۔ یہ وہ نہیں ہے جو آپ مسلسل صارف کے تجربے کے لیے چاہتے ہیں۔ جب sticky ہے trueیہ چلتا ہے۔ deterministicHash اس کے بجائے.

deterministicHash معیاری بٹ وائز ہیش کا استعمال کرتے ہوئے اسٹرنگ کو نمبر میں تبدیل کرتا ہے۔ اہم تفصیل یہ ہے کہ ان پٹ پرچم کے ناموں کو جوڑتا ہے۔ اور صارف کی شناخت: "new-checkout:user-123". دونوں کو ایک ساتھ ہیش کرنے کا مطلب یہ ہے کہ صارف 123 کی بالٹی اسائنمنٹ فی پرچم آزاد ہے۔ یعنی، آپ ایک تجربے میں 10% میں ہو سکتے ہیں اور دوسرے تجربے میں 10% میں نہیں۔

اس کے بعد ہم 0 اور 99 کے درمیان نمبر بنانے کے لیے ہیش رزلٹ ماڈیولو 100 لیتے ہیں۔ اگر وہ نمبر رول آؤٹ ریٹ سے نیچے آتا ہے، تو اس صارف کے لیے ایک جھنڈا سیٹ کیا جائے گا۔ ایک ہی سٹرنگ کا ایک ہیش ہمیشہ ایک ہی نمبر پیدا کرے گا، لہذا وہی صارف ہمیشہ دہلیز کے ایک ہی طرف اترے گا۔

فکسڈ ہیشنگ اہم ہے۔ اس خصوصیت کے بغیر، 10% ریلیز والے صارفین کو صرف ایک درخواست میں خصوصیت نظر آئے گی، لیکن اگلی درخواست میں نہیں۔ ڈٹرمینسٹک ہیش استعمال کریں۔ flagName + userId لہذا، ایک ہی صارف ہمیشہ دہلیز کے ایک ہی طرف پہنچ جائے گا۔

تجویز کردہ لیمپ شیڈول:

آگے بڑھنے سے پہلے ہر قدم میں کم از کم 24 گھنٹے کے لیے مستحکم میٹرکس (خرابی کی شرح، لیٹنسی p99، کاروباری KPIs) ہونا ضروری ہے۔ ترقی کا موقع وقت نہیں بلکہ اعتماد ہے۔

1. 1%: مہلک غلطیوں کو پکڑنے کے لیے دھوئیں کی جانچ۔ میں کریشز تلاش کر رہا ہوں، اعداد و شمار نہیں۔ اگر 24 گھنٹوں کے اندر کچھ نہیں پھٹا تو جاری رکھیں۔

2. 5%: چھوٹے پیمانے پر میٹرکس کی توثیق کریں۔ اب اتنی ٹریفک ہے کہ خرابی کی اعلی شرح کو محسوس کیا جا سکے، لیکن کچھ غلط ہونے کی صورت میں وسیع پیمانے پر اثر ڈالنے کے لیے کافی نہیں۔

3. 25%: بوجھ اور کارکردگی پر ایک نظر ڈالیں۔ اس پیمانے پر، دوڑ کے حالات، کیشے کے غلط ہونے والے کیڑے، اور سست سوالات سامنے آنا شروع ہو جاتے ہیں۔

4. 50%: شماریاتی اہمیت کے لیے میٹرکس کا ساتھ ساتھ موازنہ کریں۔ ہمارے پاس بامعنی A/B موازنہ کرنے کے لیے کافی بڑی جماعت ہے۔

5. 100%: مکمل رول آؤٹ کے بعد جھنڈوں کو صاف کریں۔

پیٹرن 3: صارف کے طبقات کو نشانہ بنانا

اس پیٹرن کو مخصوص گروپوں کو نشانہ بنانے کے لیے استعمال کریں، جیسے کہ اندرونی ملازمین، بیٹا صارفین، مخصوص علاقوں، یا اکاؤنٹ کے درجہ بندی۔

interface SegmentRule {
  attribute: string;
  operator: "eq" | "in" | "gt" | "lt" | "contains";
  // Note: "gt" and "lt" operators only make sense with number values.
  // A production system should validate operator-value compatibility
  // at configuration time rather than relying on the caller.
  value: string | string[] | number;
}

interface FlagConfig {
  defaultValue: boolean;
  rules: Array<{
    segments: SegmentRule[];
    value: boolean;
    rolloutPercentage?: number;
  }>;
}

function evaluateFlag(
  flagName: string,
  config: FlagConfig,
  context: Record
): boolean {
  for (const rule of config.rules) {
    if (matchesAllSegments(rule.segments, context)) {
      if (rule.rolloutPercentage !== undefined) {
        // Reuses isEnabled() from Pattern 2
        return isEnabled(flagName, context.userId as string, {
          percentage: rule.rolloutPercentage,
          sticky: true,
        });
      }
      return rule.value;
    }
  }
  return config.defaultValue;
}

اوپر والے کوڈ میں، evaluateFlag ترتیب سے قواعد کے ذریعے اعادہ کرتا ہے اور جیسے ہی اسے کوئی اصول ملتا ہے جہاں صارف کا سیاق و سباق تمام طبقوں کی شرائط سے میل کھاتا ہے واپس آجاتا ہے۔ ہر ایک SegmentRule خصوصیات کی وضاحت کریں، جیسے "accountTier")، آپریٹرز (جیسے "eq" یا "in") اور جس قدر کا موازنہ کرنا ہے۔ matchesAllSegments سیگمنٹ کے تمام اصولوں کی جانچ پڑتال کی جاتی ہے، اور کسی اصول کے مماثل ہونے کے لیے تمام قواعد کو پاس کرنا ضروری ہے۔

اگر آپ کے میچ کے اصول ہیں: rolloutPercentageایک ساتھ پورے حصے کے لیے پرچم کو فعال نہ کریں۔ اس کے بجائے isEnabled پیٹرن 2 میں، آپ اسے تمام بیٹا صارفین کے لیے فعال کرنے سے پہلے اسے اپنے 10% بیٹا صارفین تک پہنچا سکتے ہیں۔

اگر نہیں rolloutPercentageقوانین کے value اسے براہ راست واپس کیا جاتا ہے۔ اگر کوئی اصول بالکل بھی مماثل نہیں ہے تو، جھنڈا اس پر واپس آجاتا ہے: config.defaultValue. قواعد کی ترتیب ترتیب سے کی جاتی ہے، اس لیے مزید مخصوص قواعد (اندرونی ملازمین، بیٹا صارفین) کو وسیع تر قواعد (کل صارفین کا فیصد) سے پہلے آنا چاہیے۔

ایک عام گو ٹو مارکیٹ حکمت عملی طبقات اور تناسب کو یکجا کرتی ہے۔

1. داخلی ملازمین کے لیے فعال کریں (ڈاگ فوڈنگ)

2. بیٹا آپٹ ان صارفین کے لیے فعال کریں۔

3. 10% مفت درجے کے صارفین کے لیے لانچ کیا گیا۔

4. 10% ادا شدہ درجے کے صارفین کے لیے لانچ کریں (اعلیٰ داؤ پر)

5. آہستہ آہستہ دونوں حصوں میں اضافہ کریں۔

پیٹرن 4: متعدد مختلف جھنڈے

یہ A/B/C ٹیسٹنگ یا کنفیگریشن تغیرات کے لیے مفید ہے جب آپ کو اسے آن/آف کرنے کے بجائے مزید فعالیت کی ضرورت ہو۔

type Variant = "control" | "variant_a" | "variant_b";

interface MultiVariantConfig {
  variants: Array<{
    name: Variant;
    weight: number; // Percentage allocation
  }>;
}

// config must be pre-validated with MultiVariantConfigSchema.parse()
function getVariant(
  flagName: string,
  config: MultiVariantConfig,
  userId: string
): Variant {
  // Include flagName in the hash so users land in independent buckets
  // across different experiments, without this, bucket assignment
  // is correlated and undermines statistical independence.
  const hash = deterministicHash(`${flagName}:${userId}`) % 100;
  let cumulative = 0;

  for (const variant of config.variants) {
    cumulative += variant.weight;
    if (hash < cumulative) {
      return variant.name;
    }
  }

  return config.variants[0].name; // Fallback to first variant
}

// Usage
const variant = getVariant("search-experiment", searchConfig, userId);

switch (variant) {
  case "control":
    return ;
  case "variant_a":
    return ;
  case "variant_b":
    return ;
}

نوٹ: یقینی بنائیں کہ تمام وزن کا مجموعہ 100 ہے۔ اس کی توثیق کریں جب آپ اسے ترتیب دیں، نہ کہ جب آپ اس کا جائزہ لیں۔ ایک ناقص تعمیر شدہ تجربہ بالکل بھی تجربہ نہ کرنے سے بدتر ہے۔

اوپر والے کوڈ میں، getVariant یہ ایک وزنی لاٹری کی طرح کام کرتا ہے۔ ہم پرچم کا نام اور صارف ID کو 0 اور 99 کے درمیان نمبر کے ساتھ ہیش کرتے ہیں، پھر وزن جمع کرنے والے مختلف قسموں کی فہرست کو دیکھیں۔

اگر ہیش کی قیمت چلنے والے کل سے نیچے آتی ہے، تو یہ وہ قسم ہے جو آپ کو ملتی ہے۔ مثال کے طور پر، اگر کنٹرول وزن 50 ہے variant_a: 25، variant_b: 25ہیش 60 پہنچ گیا۔ variant_a (مجموعی طور پر اس وقت: 75)، ہیش 30 کو کنٹرول کیا جاتا ہے (مجموعی: 50)۔ چونکہ ہیشز تعییناتی ہیں، اسی لیے ایک ہی صارف کو ہمیشہ ایک ہی جھنڈے کے لیے ایک جیسا تغیر ملے گا اور تجربہ درخواستوں میں تبدیل نہیں ہوگا۔

کال سائٹ پر بیانات کو تبدیل کریں پھر ہر ایک مختلف نام کو مختلف جزو سے نقشہ بنائیں۔ control موازنے کی بنیاد فراہم کرنے کے لیے موجودہ تجربات کو پیش کریں۔ variant_a اور variant_b تجربہ کیا جا رہا متبادل پیش کریں۔ ہر متبادل کے لیے میٹرکس کو ٹریک کریں اور اعدادوشمار کے لحاظ سے اہم نتائج اخذ کرنے کے لیے کافی ٹریفک ہونے کے بعد ان کا موازنہ کریں۔

import { z } from "zod";

const VariantSchema = z.object({
  name: z.string(),
  weight: z.number().min(0).max(100),
});

const MultiVariantConfigSchema = z
  .object({
    variants: z.array(VariantSchema).min(1),
  })
  .refine(
    (config) => {
      const total = config.variants.reduce((sum, v) => sum + v.weight, 0);
      return total === 100;
    },
    { message: "Variant weights must sum to 100" }
  );

// Validates at config load time — bad configs never reach evaluation
const config = MultiVariantConfigSchema.parse(rawConfig);

پرچم زندگی سائیکل

جھنڈے جو اپنے مقصد سے باہر رہتے ہیں وہ تکنیکی قرض بن جاتے ہیں۔ اس کو روکنے کے لیے، آپ لائف سائیکل ترتیب دے سکتے ہیں۔

1. تخلیق

تمام جھنڈوں میں میٹا ڈیٹا ہونا ضروری ہے۔

interface FlagMetadata {
  name: string;
  owner: string;           // Team or person responsible
  createdAt: Date;
  expectedRemovalDate: Date; // Forces planning for cleanup
  type: "release" | "experiment" | "ops" | "permission";
  description: string;
  jiraTicket?: string;      // Link to tracking issue
}

کہ expectedRemovalDate یہ صرف اس صورت میں کام کرتا ہے جب کوئی چیز اسے نافذ کرے۔ مخصوص نقطہ نظر درج ذیل ہے: ایک طے شدہ کام جو روزانہ چلتا ہے اور جھنڈے کی میعاد ختم ہونے پر کلین اپ ٹکٹ بناتا ہے۔

// Run daily via cron or scheduled CI job
async function auditStaleFlags(flags: FlagMetadata[]) {
  const now = new Date();
  const staleFlags = flags.filter(
    (f) =>
      f.type === "release" &&
      f.expectedRemovalDate < now
  );

  for (const flag of staleFlags) {
    const daysOverdue = Math.floor(
      (now.getTime() - flag.expectedRemovalDate.getTime()) / 86_400_000
    );

    // In practice, check for an existing open ticket before creating
    // a duplicate. Use an upsert keyed on the flag name, or skip
    // creation if an open ticket with the [Stale Flag] label exists.
    await createJiraTicket({
      title: `[Stale Flag] Remove "${flag.name}" (${daysOverdue} days overdue)`,
      assignee: flag.owner,
      priority: daysOverdue > 30 ? "high" : "medium",
      labels: ["tech-debt", "feature-flag-cleanup"],
    });

    // Optionally: post to Slack, block deploys, or log warnings
    logger.warn(`Flag "${flag.name}" is ${daysOverdue} days past removal date`);
  }
}

کچھ ٹیمیں مزید آگے بڑھتی ہیں اور CI کو ناکام کرتی ہیں اگر ان کی ہٹانے کی تاریخوں کے بعد رہائی کے جھنڈے موجود ہوں۔ یہ جارحانہ لیکن موثر ہے۔ اس کی وجہ یہ ہے کہ یہ یقینی بناتا ہے کہ جھنڈا کبھی بھی حادثاتی طور پر ثابت قدم نہیں رہے گا۔

2. فعال انتظام

لانچ کے دوران پرچم کے استعمال کی نگرانی کریں۔

• خرابی کی شرح: رپورٹ شدہ اور غیر رپورٹ شدہ گروپوں کا موازنہ

• پوشیدہ: کیا نیا کوڈ پاتھ کوئی اوور ہیڈ شامل کرے گا؟

• بزنس میٹرکس: تبادلوں، مشغولیت، آمدنی فی جماعت

• پرچم کی تشخیص کی تعداد: کیا توقع کے مطابق جھنڈوں کو چیک کیا جا رہا ہے؟

3. منظم کرنا

یہ مشکل حصہ ہے۔ پرانے جھنڈے تیزی سے جمع ہو جاتے ہیں۔

اگر آپ ڈیٹا بیس سے حمایت یافتہ فلیگنگ سسٹم استعمال کرتے ہیں (یا مینیجڈ فراہم کنندہ کے API سے استفسار کر سکتے ہیں)، تو ایک سادہ سوال کلین اپ امیدواروں کو ظاہر کرے گا۔ یہ فرض کرتا ہے: feature_flags کالموں کے ساتھ ایک جدول جس میں ہر پرچم کی موجودہ ریلیز کی شرح، اس شرح تک پہنچنے کی تاریخ، اور اس کی قسم:

-- Find flags that have been at 100% for over 30 days
-- These are candidates for cleanup
SELECT name, enabled_at
FROM feature_flags
WHERE percentage = 100
  AND enabled_at < NOW() - INTERVAL '30 days'
  AND type="release";

آپ پرچم صاف کرنے کی اطلاعات کو خودکار کر سکتے ہیں۔ جب ریلیز کا جھنڈا دو ہفتوں سے زیادہ کے لیے 100% پر ہو تو الرٹ سیٹ کریں۔ خود بخود جیرا ٹکٹ بناتا ہے۔ صحیح کام کرنے میں آسانی پیدا کریں۔

اینٹی پیٹرن سے بچنے کے لیے

نیسٹڈ پرچم انحصار

// Don't do this
if (flags.newCheckout) {
  if (flags.newPaymentProcessor) {
    if (flags.newFraudDetection) {
      // Which combination was tested?
    }
  }
}

تین بولین جھنڈے آٹھ ممکنہ ریاستیں بناتے ہیں۔ ان میں سے زیادہ تر حالات کا تجربہ نہیں کیا گیا ہے۔ اگر جھنڈے ایک دوسرے پر منحصر ہیں، تو انہیں ایک جھنڈے میں یکجا کریں یا واضح طور پر درست امتزاج کی دستاویز کریں۔

پرچم پر مبنی فن تعمیر

// Don't do this
function calculatePrice(item: Item, flags: FeatureFlags) {
  let price = item.basePrice;

  if (flags.newTaxCalculation) price = applyNewTax(price);
  else price = applyOldTax(price);

  if (flags.loyaltyDiscount) price = applyLoyalty(price);

  if (flags.bulkPricing && flags.newBulkTiers) {
    price = applyNewBulkPricing(price);
  } else if (flags.bulkPricing) {
    price = applyOldBulkPricing(price);
  }

  return price;
}

اگر آپ کی کاروباری منطق جھنڈے کی تشخیص کے انجن کی طرح پڑھتی ہے، تو آپ کو ڈیزائن کا مسئلہ ہے۔ جھنڈوں کو باؤنڈری پر رکھنے اور کنڈیشنلز کو ہر طرف چھڑکنے کے بجائے، آپ انہیں بالکل مختلف نفاذ کی طرف لے جاتے ہیں۔

// Do this instead — flag check lives at the boundary
interface PricingStrategy {
  calculate(item: Item): number;
}

const legacyPricing: PricingStrategy = {
  calculate(item) {
    return applyOldTax(applyOldBulkPricing(item.basePrice));
  },
};

const newPricing: PricingStrategy = {
  calculate(item) {
    return applyNewTax(applyLoyalty(applyNewBulkPricing(item.basePrice)));
  },
};

// Single flag check at the entry point — no conditionals in business logic
const pricing = flags.newPricingEngine ? newPricing : legacyPricing;
const finalPrice = pricing.calculate(item);

ہر عمل خود مختار اور آزادانہ طور پر قابل آزمائش ہے۔ جھنڈا فیصلہ کرتا ہے۔ کوئی بھی وہ حکمت عملی نہیں جو آپ استعمال کرتے ہیں۔ کس طرح حکمت عملی کام کرتی ہے۔

کوئی ڈیفالٹ فال بیک نہیں۔

ہمیشہ وضاحت کریں کہ جب فلیگ سروس دستیاب نہ ہو تو کیا ہوتا ہے۔

function getFlag(name: string, defaultValue: boolean): boolean {
  try {
    return flagService.evaluate(name);
  } catch {
    // Flag service is down? Fail safe
    logger.warn(`Flag service unavailable, using default for ${name}`);
    return defaultValue;
  }
}

سیف آپشن ڈیفالٹ ہے۔ نئی خصوصیات کے لیے، محفوظ ڈیفالٹس عام طور پر ہوتے ہیں۔ false (فنکشن آف)۔ کِل سوئچز کے لیے، محفوظ ڈیفالٹس عام طور پر ہوتے ہیں۔ true (نظام چل رہا ہے)۔

خصوصیت کے جھنڈوں کے ساتھ جانچ

خصوصیت کے جھنڈے ٹیسٹ کی سطح کو ضرب دیتے ہیں۔ آپ جس چیز کی جانچ کرتے ہیں اس کے بارے میں احتیاط سے سوچیں۔

describe("checkout flow", () => {
  it("works with new checkout enabled", () => {
    setFlag("newCheckout", true);
    // Test the new path
  });

  it("works with new checkout disabled", () => {
    setFlag("newCheckout", false);
    // Test the old path
  });

  // Only test valid flag combinations
  it("works with new checkout + new payment", () => {
    setFlag("newCheckout", true);
    setFlag("newPaymentProcessor", true);
    // Test the combined path
  });
});

ہر ترتیب کی جانچ نہ کریں۔ ان مجموعوں کی جانچ کریں جنہیں آپ عملی طور پر تعینات کرنا چاہتے ہیں۔

پرچم کا نظام منتخب کریں۔

نقطہ نظر	میرٹ	نقصان	بہترین ہدف
ترتیب فائل	سادہ اور ورژن	دوبارہ تقسیم درکار ہے۔	چھوٹی ٹیم، چند جھنڈے
ماحولیاتی متغیرات	سادہ اور ماحول کے لیے مخصوص	دوبارہ شروع کرنے کی ضرورت ہے۔	آپریشن پرچم
ڈیٹا بیس	متحرک، کوئی دوبارہ شروع نہیں	ایک UI بنانے کی ضرورت ہے۔	بڑھتی ہوئی ٹیم
منظم سروس (لانچ ڈارکلی، انلیش)	مکمل خصوصیات والے تجزیات	لاگت، وینڈر لاک ان	ٹیم کی توسیع

سادہ شروع کریں۔ اگر آپ کے پاس 5 جھنڈے ہیں تو، کنفیگریشن فائل یا ماحولیاتی متغیر ٹھیک ہے۔ اگر آپ کو اپنی تمام سروسز میں اہدافی قوانین، آڈٹ لاگز، اور ریئل ٹائم اپ ڈیٹس کی ضرورت ہے، تو ایک منظم سروس پر جائیں۔

نتیجہ

اس مضمون میں، آپ نے چار بنیادی نمونوں کا استعمال کرتے ہوئے فیچر فلیگز کو لاگو کرنے کا طریقہ سیکھا: سادہ بولین ٹوگلز، سٹکی ہیشنگ کے ساتھ فیصد پر مبنی ریلیزز، یوزر سیگمنٹ ٹارگٹنگ، اور A/B ٹیسٹنگ کے لیے ملٹی ویرینٹ فلیگز۔

آپ نے یہ بھی سیکھا کہ فلیگ لائف سائیکل کو کس طرح منظم کرنا ہے، عام اینٹی پیٹرن سے بچنا ہے، اور جھنڈوں کا استعمال کرتے ہوئے مؤثر طریقے سے جانچ کرنا ہے۔

اہم نکات کا مختصر خلاصہ درج ذیل ہے:

1. ریلیز سے الگ تعیناتیاں۔ جھنڈے کے پیچھے جہاز کا کوڈ، اعتماد ہونے پر جاری کریں۔

2. فکسڈ ہیشنگ کا استعمال کریں۔ صارفین کو مستقل تجربہ حاصل کرنا چاہیے۔

3. تنظیمی منصوبہ: تمام ریلیز جھنڈوں کی میعاد ختم ہونے کی تاریخ ہونی چاہیے۔

4. نیسٹڈ پرچم کے انحصار سے بچیں۔ امتزاج کی حالتوں کی جانچ نہیں کی جاسکتی ہے۔

5. بنیادی محفوظ: اگر فلیگ سروس بند ہے تو یہ محفوظ حالت میں ناکام ہو جائے گی۔

6. جھنڈوں کو نظر میں رکھیں۔ صرف ایک مختلف نفاذ کی طرف بڑھیں اور چاروں طرف کنڈیشنل نہ چھڑکیں۔

7. دونوں گروہوں کی نگرانی کی جائے گی۔ خرابی کی شرح، تاخیر، اور کاروباری میٹرکس کا موازنہ کریں۔

ان تمام نمونوں کی تھرو لائن: فیچر فلیگ رسک مینجمنٹ ٹول ہیں، کوڈ آرگنائزیشن ٹول نہیں۔ اسے نمائش کو کنٹرول کرنے کے لیے استعمال کریں، نہ کہ اپنی منطق کی تشکیل کے لیے۔

اسٹریمرز بھیجیں، اپنے رول آؤٹ کی پیمائش کریں، اپنے میٹرکس کو چیک کریں، اور پھر منظم کریں۔ جس لمحے ایک جھنڈا اپنے چکر کو بند کر دیتا ہے، یہ ایک ذمہ داری ہے۔