ایپلی کیشن ڈویلپمنٹ میں feature freeze اور code freeze: جوہر، فرق اور کردار

Feature freeze کیا ہے؟

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

Feature freeze ان زیر تکمیل (work-in-progress) فیچرز کے مسئلے کو حل کرتا ہے جو ریلیز میں شامل نہیں ہوتے لیکن پہلے ہی مین برانچ میں جزوی طور پر ضم ہو چکے ہوتے ہیں۔ اگر نئے فیچرز ضم ہوتے رہیں تو ریگریشن کا خطرہ بڑھ جاتا ہے: ہر نئے انٹیگریشن میں پہلے سے مکمل ماڈیولز کی دوبارہ جانچ ضروری ہوتی ہے۔ Feature freeze ریلیز کے دائرہ کار کو مقرر کرتا ہے، اسے ایک متحرک ہدف سے فعالیت کے ایک مستحکم سیٹ میں تبدیل کرتا ہے۔

ایک اہم وضاحت: feature freeze ≠ code freeze۔ Feature freeze کے دوران، بگ فکسز، ری فیکٹرنگ، انحصار اپ ڈیٹس اور دستاویزات کی اجازت ہے۔ صرف نئی صارف پر مبنی خصوصیات ممنوع ہیں — کوئی بھی کوڈ جو صارف کے نقطہ نظر سے ایپلی کیشن کے رویے کو بدلتا ہے۔ کوڈ ریویو چیک: اگر PR نیا اسکرین، بٹن یا API طریقہ شامل کرتا ہے — تو اسے فریز ہٹنے تک مسترد کر دیا جاتا ہے۔

Code freeze کیا ہے اور یہ feature freeze سے کیسے مختلف ہے

Code freeze ایک سخت تر طرز عمل ہے جس میں کوڈ میں تمام تبدیلیاں مکمل طور پر ممنوع ہوتی ہیں۔ بگ فکسز بھی اس وقت تک اجازت نہیں جب تک وہ اہم نہ ہوں۔ Code freeze ایک مختصر مدت (عام طور پر 24-48 گھنٹے) کے لیے متعارف کرایا جاتا ہے اور یہ یقینی بناتا ہے کہ ریلیز بلڈ کمٹس کے ایک مقررہ سیٹ سے بنائی گئی ہے۔

Feature freeze اور code freeze کے درمیان فرق کنٹرول کی سطح میں ہے۔ Feature freeze دائرہ کار کو منظم کرتا ہے: ریلیز میں بالکل کیا شامل ہوگا۔ Code freeze معیار کو منظم کرتا ہے: ریلیز سے ایک دن پہلے نئی بگ متعارف کرانے کے خطرے کو ختم کرتا ہے۔ عملی طور پر، بہت سی ٹیمیں دو مرحلے کا ماڈل استعمال کرتی ہیں: ریلیز سے 1-2 ہفتے پہلے — feature freeze، 24-48 گھنٹے پہلے — code freeze۔ Code freeze خاص طور پر موبائل ایپس کے لیے اہم ہے، جہاں منصوبہ بند ریلیز تاریخ سے کئی دن پہلے بلڈ اسٹور پر اپ لوڈ کرنی ہوتی ہے۔

Code freeze کی استثنا اہم کمزوریوں (CVE سکور 9+) کے لیے سیکیورٹی فکسز ہیں۔ ایسی تبدیلیاں لازمی فاسٹ ٹریک کوڈ ریویو اور ٹیم اطلاع کے ساتھ ہنگامی عمل سے گزرتی ہیں۔ باقی تمام تبدیلیاں اگلے ریلیز سائیکل تک ملتوی کر دی جاتی ہیں۔

Feature freeze بمقابلہ code freeze: موازنہ

Feature freeze اور code freeze کے درمیان انتخاب ٹیم کی پختگی اور ریلیز فریکوئنسی پر منحصر ہے۔ CI/CD اور فیچر فلیگ والی ٹیمیں صرف 24 گھنٹے کے code freeze کی ضرورت پڑ سکتی ہے، جبکہ ماہانہ ریلیز والی ٹیمیں اکثر دونوں فریز کو ترتیب وار استعمال کرتی ہیں۔

فریز کی اقسام: مکمل، جزوی اور BAU فریز

مکمل feature freeze اور code freeze کے علاوہ، مزید لچکدار اختیارات بھی ہیں۔ جزوی feature freeze نئی فعالیت کو صرف مخصوص ماڈیولز میں روکتا ہے — مثال کے طور پر، ادائیگی کے ماڈیول یا اجازت نامے کے ماڈیول میں، دیگر اجزاء کو تبدیلیوں کے لیے کھلا چھوڑتا ہے۔

BAU فریز (business as usual freeze) ایک سمجھوتہ کا اختیار ہے جس میں صرف بڑی خصوصیات جن کی تبدیلی کا حجم ایک خاص حد (مثلاً 500 کوڈ لائنز) سے زیادہ ہو، ممنوع ہوتی ہیں۔ چھوٹی بہتری، UI ایڈجسٹمنٹ اور بگ فکسز ضم ہوتی رہتی ہیں۔ BAU فریز مسلسل ترسیل والے منصوبوں کے لیے آسان ہے، جہاں ایک ہفتے کی مکمل ترقی روکنا معاشی طور پر مناسب نہیں ہے۔

تعیناتی فریز (deployment freeze) کا تصور بھی ہے — پروڈکشن پر تمام تعیناتیوں کا مکمل بند، جو چھٹیوں کے موسم (کرسمس کی چھٹیاں، بلیک فرائیڈے) کی خصوصیت ہے۔ اس عرصے کے دوران، ہاٹ فکسز بھی اس وقت تک روک دی جاتی ہیں جب تک وہ سیکیورٹی سے متعلق نہ ہوں۔ تعیناتی فریز عام طور پر 1-2 ہفتے رہتا ہے اور کمپنی کی سطح پر مربوط ہوتا ہے۔

فریز کب متعارف کرایا جائے اور یہ کتنا عرصہ چلتا ہے

Feature freeze متعارف کرانے کا بہترین وقت کوڈ مکمل ہونے کے بعد ہے، جب تمام منصوبہ بند فیچرز ضم ہو چکے ہوں اور QA سے گزر رہے ہوں۔ صحیح وقت ریلیز سائیکل پر منحصر ہے: دو ہفتے کے سپرنٹ کے لیے، feature freeze ریلیز تاریخ سے 3-4 دن پہلے متعارف کرایا جاتا ہے؛ ماہانہ ریلیز کے لیے، 7-10 دن پہلے۔ Code freeze منصوبہ بند ریلیز بلڈ وقت سے 24-48 گھنٹے پہلے متعارف کرایا جاتا ہے۔

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

تجویز کردہ عمل یہ ہے کہ فریز کو کیلنڈر تاریخ کے بجائے کوڈ بیس کی حالت کے مطابق مقرر کیا جائے۔ Feature freeze متعارف کرایا جاتا ہے جب ریلیز کے لیے کھلی بگز کی تعداد ایک حد (مثلاً 10 اہم بگز) سے تجاوز کر جائے۔ Code freeze — جب بلڈ اسموک ٹیسٹ اور ریگریشن سوٹ کو کامیابی سے پاس کر لے۔ وقت پر مبنی فریز (مقررہ تاریخ) ریگولیٹڈ صنعتوں (فنٹیک، میڈٹیک) میں معیار رہتا ہے جہاں ریلیز تاریخ ایک ریگولیٹر کے ذریعے منظور شدہ ہوتی ہے۔

CI/CD اور Git کے ذریعے فریز کا آٹومیشن

دستی فریز کنٹرول غلطیوں کا ذریعہ ہے: ایک ڈویلپر غلطی سے اس PR کو ضم کر سکتا ہے جسے فریز ہٹنے تک انتظار کرنا چاہیے۔ آٹومیشن Git برانچ پروٹیکشن قوانین اور CI/CD پائپ لائنز کے ذریعے اسے حل کرتا ہے۔ Git فراہم کنندہ (GitHub, GitLab, Bitbucket) میں، ایسے قوانین ترتیب دیے جاتے ہیں جو خصوصی ٹیگ یا ریلیز مینیجر کی منظوری کے بغیر ریلیز برانچ میں ضم ہونے کو روکتے ہیں۔

CI/CD پائپ لائن بلڈ بنانے سے پہلے فریز کی حیثیت چیک کرتی ہے۔ Jenkins، GitLab CI یا GitHub Actions میں، ایک مرحلہ شامل کیا جاتا ہے جو فریز شیڈول کے ساتھ ایک کنفیگریشن فائل پڑھتا ہے اور اگر موجودہ تاریخ فریز کی مدت میں آتی ہے تو بلڈ کو مسترد کرتا ہے۔ ایک متبادل ایڈمن پینل میں فیچر فلیگ ہے جو پروڈکشن پر تعیناتی کو روکتا ہے۔

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

مثال freeze-check.js اسکرپٹ ریپوزٹری روٹ سے فریز شیڈول کے ساتھ JSON پڑھتی ہے۔ اگر موجودہ تاریخ مخصوص برانچ کے لیے start_date اور end_date کے درمیان آتی ہے تو پائپ لائن فریز حیثیت کے پیغام کے ساتھ ناکام ہو جاتی ہے۔ Git برانچ پروٹیکشن دوسری رکاوٹ شامل کرتا ہے: چاہے پائپ لائن متحرک نہ ہوئی ہو، قاعدہ منظوری کے بغیر PR کو ضم کرنے کی اجازت نہیں دے گا۔

فریز لاگو کرتے وقت عام غلطیاں

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

دوسری غلطی فریز میں بہت زیادہ استثنائیں ہیں۔ ہر استثنا (“یہ PR کوئی خصوصیت نہیں، یہ تکنیکی قرض ہے”) فریز کی حد کو دھندلا کرتا ہے۔ اگر استثنائیں عام PR بہاؤ کے 20% سے تجاوز کریں تو فریز کام نہیں کرتا۔ ٹیم روک کو نظرانداز کرنے کے لیے خصوصیات کو بگ فکسز کا نام دیتی ہے۔

تیسری غلطی ریلیز امیدواروں کو نظرانداز کرنا ہے۔ اگر ٹیم ریلیز امیدوار بلڈز نہیں بناتی اور code freeze کے بعد براہ راست پروڈکشن پر تعینات کرتی ہے تو فریز کا مقصد ختم ہو جاتا ہے: صارفین بگز دریافت کرتے ہیں۔ ریلیز امیدوار کو code freeze سے پہلے بنایا جانا چاہیے، QA اور سٹیجنگ پر ٹیسٹ کیا جانا چاہیے، اور صرف معیار کی تصدیق کے بعد code freeze متعارف کرایا جانا چاہیے۔

چوتھی غلطی دستی کنٹرول میں انسانی عنصر ہے۔ ایک ڈویلپر ضم کرنے سے پہلے فریز کی حیثیت چیک کرنا بھول سکتا ہے، ایک ریلیز مینیجر اطلاع سے محروم ہو سکتا ہے۔ واحد قابل اعتماد حل Git فراہم کنندہ یا CI/CD کی سطح پر خودکار روک ہے، جو انسانی غلطی کو ختم کرتا ہے۔