ایپ ڈیویلپمنٹ میں ہاٹ فکس: ماہیت، میکانزم اور لاگو کرنے کا طریق

ہاٹ فکس کیا ہے اور کب ضرورت ہوتی ہے؟

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

ہاٹ فکس کے لیے عام منظرنامے: مخصوص آلات پر شروع ہوتے وقت کریش (آخری ریلیز کے بعد ریگریشن)، غلط اجازت کی وجہ سے ذاتی ڈیٹا کا اخراج، ٹوٹا ہوا ادائیگی انٹیگریشن (آمدنی کا نقصان)، GDPR/CCPA تعمیل کی خلاف ورزیاں۔ ان تمام حالات کی واقعات کی درجہ بندی میں سنگینی P0 یا P1 ہے۔ منصوبہ بند کام — اصلاح، ری فیکٹرنگ، نئی اسکرینز — کبھی hotfix کے ذریعے نہیں کیے جاتے۔

ایک اہم قاعدہ: ہاٹ فکس میں کم سے کم تبدیلیاں ہوتی ہیں (1–2 فائلیں، 10–20 لائن کوڈ)۔ ڈیف جتنا چھوٹا ہوگا، نیا بگ متعارف کرانے کا خطرہ اتنا ہی کم ہوگا۔ اگر مسئلہ حل کرنے کے لیے آرکیٹیکچر تبدیل کرنے یا نیا ماڈیول شامل کرنے کی ضرورت ہو — یہ hotfix نہیں ہے، بلکہ ایک ہنگامی ریلیز ہے جس کے لیے مکمل کوڈ ریویو اور QA کی ضرورت ہے۔

ہاٹ فکس عام ریلیز سے کیسے مختلف ہے

ہاٹ فکس اور منصوبہ بند ریلیز کے درمیان بنیادی فرق رفتار، تبدیلیوں کا دائرہ اور جانچ کی سطح ہیں۔ ایک منصوبہ بند ریلیز میں درجنوں فیچرز شامل ہو سکتے ہیں، مکمل QA سائیکل (ریگریشن + انٹیگریشن + UI ٹیسٹ) سے گزر سکتے ہیں، اور کوڈ فریز سے تعیناتی تک 1–2 ہفتے لگ سکتے ہیں۔ ہاٹ فکس میں ایک یا دو اصلاحات شامل ہوتی ہیں، تیز رفتار ریویو (3 کے بجائے 2 منظوری) اور کم سے کم اسموک ٹیسٹ سے گزرتا ہے۔

Git عمل کے نقطہ نظر سے، ہاٹ فکس ایک ریلیز ٹیگ سے بنایا جاتا ہے، develop برانچ سے نہیں۔ یہ یقینی بناتا ہے کہ صرف مسئلہ حل کرنے کے لیے ضروری تبدیلیاں hotfix میں شامل ہوں، بغیر develop سے نامکمل فیچرز کو غلطی سے کھینچے۔ تعیناتی کے بعد، ہاٹ فکس کو main اور develop میں واپس ضم کیا جاتا ہے (cherry-pick یا merge کے ذریعے)۔

منصوبہ بند ریلیز اور ہاٹ فکس کا موازنہ

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

ہاٹ فکس کا عمل: دریافت سے تعیناتی تک

کسی سنگین مسئلے کی دریافت پر پہلا قدم ٹرائیج ہے — سنگینی کا فوری جائزہ۔ آن کال انجینئر بگ کی تصدیق کرتا ہے، لاگز اور کریش رپورٹس چیک کرتا ہے، اور طے کرتا ہے کہ مسئلہ آخری ریلیز کا ریگریشن ہے یا دیرینہ بگ۔ اگر سنگینی P0 ہے — hotfix پائپ لائن شروع کی جاتی ہے۔ ٹرائیج مرحلہ 15 منٹ سے زیادہ نہیں لینا چاہیے۔

دوسرا مرحلہ — تازہ ترین ریلیز ٹیگ (v2.5.0 → hotfix/v2.5.1) سے برانچ بنانا۔ ڈویلپر کم سے کم اصلاح کرتا ہے، پیغام میں HOTFIX سابقہ کے ساتھ کمٹ کرتا ہے، پش کرتا ہے اور [HOTFIX] لیبل کے ساتھ PR کھولتا ہے۔ فاسٹ ٹریک کوڈ ریویو: CODEOWNERS کے ذریعے دو ریویور خودکار طور پر مقرر کیے جاتے ہیں، ریویو کا وقت 30 منٹ سے زیادہ نہیں۔ اگر 20 منٹ میں کوئی ریویو نہ ہو — ریویور کو چھوڑ دیا جاتا ہے اور اگلا مقرر کیا جاتا ہے۔

تیسرا مرحلہ — CI/CD کے ذریعے بلڈ اور تعیناتی۔ ہاٹ فکس پائپ لائن عام سے مختلف ہوتی ہے: لمبے انٹیگریشن ٹیسٹ (جن میں گھنٹے لگتے ہیں) چھوڑ دیے جاتے ہیں، صرف اسموک سوٹ چلتا ہے (10–15 سنگین منظرنامے، 5–10 منٹ)۔ تعیناتی کے بعد: کریش ریٹ، ایرر ریٹ، API لیٹنسی — 30 منٹ تک مانیٹرنگ۔ ہاٹ فکس کے لیے DORA میٹرکس: اوسط بحالی کا وقت (MTTR) 1 گھنٹے سے کم ہونا چاہیے۔

# .github/workflows/hotfix-deploy.yml
name: Hotfix Deploy Pipeline
on:
  pull_request:
    types: [labeled]
    branches: [hotfix/*]

jobs:
  hotfix-checks:
    runs-on: ubuntu-latest
    if: contains(github.event.label.name, 'hotfix-critical')
    steps:
      - uses: actions/checkout@v4
      - name: Validate diff size
        run: bash .github/scripts/diff-check.sh 30
      - name: Build
        run: ./gradlew assembleRelease
      - name: Smoke test
        run: ./gradlew smokeTest
      - name: Deploy to staging
        run: fastlane deploy_staging
      - name: Approve & deploy to production
        if: success()
        run: fastlane deploy_production
        env:
          HOTFIX_MODE: true

اس پائپ لائن میں اہم اصلاحات: ڈیف چیک (30 لائنوں سے زیادہ نہیں)، انٹیگریشن ٹیسٹ چھوڑنا، اسموک ٹیسٹ کامیاب ہونے پر اسٹیجنگ اور پروڈکشن پر خودکار تعیناتی۔ HOTFIX_MODE ماحولی متغیر رن ٹائم میں اضافی چیک فعال کرتا ہے — مثال کے طور پر، فوری مسئلہ تشخیص کے لیے توسیعی لاگنگ۔

Git میں ہاٹ فکس برانچز

ہاٹ فکس برانچز کے ساتھ کام کرنے کی حکمت عملی Gitflow Workflow میں بیان کی گئی ہے۔ بنیادی قاعدہ: ہاٹ فکس برانچ تازہ ترین ریلیز ٹیگ (git checkout -b hotfix/v2.5.1 tags/v2.5.0) سے بنائی جاتی ہے، develop یا main سے نہیں۔ یہ یقینی بناتا ہے کہ hotfix اسی کوڈ کی حالت پر مبنی ہے جو فی الحال پروڈکشن میں ہے اور develop سے نامکمل تبدیلیاں نہیں کھینچتا۔

اصلاح مکمل ہونے کے بعد، ہاٹ فکس برانچ main (یا master) اور develop میں ضم کی جاتی ہے۔ main میں — نئے پیچ ریلیز ٹیگ (v2.5.1) کے ساتھ ایک عام مرج کمٹ۔ develop میں — ٹیم پالیسی کے مطابق مرج یا cherry-pick۔ اگر develop میں main سے زیادہ تبدیلیاں ہوں تو تصادم سے بچنے کے لیے مخصوص ہاٹ فکس کمٹ کا cherry-pick کرنے کی سفارش کی جاتی ہے۔ GitFlow پہلے hotfix کو main میں ضم کرنے اور پھر main کو develop میں ضم کرنے کی سفارش کرتا ہے۔

# تازہ ترین ریلیز ٹیگ سے ہاٹ فکس برانچ بنائیں
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# اصلاح نفذ کریں
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# main میں ضم کریں اور ریلیز ٹیگ کریں
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# develop میں بھی ضم کریں
git checkout develop
git merge --no-ff hotfix/v2.5.1

# عارضی برانچ صاف کریں
git branch -d hotfix/v2.5.1

اہم: اگر ہاٹ فکس موجودہ develop برانچ میں موجود بگ کو ٹھیک کرتا ہے (بگ کئی سپرنٹ پہلے متعارف کرایا گیا تھا)، تو hotfix کو main اور develop میں ضم کرنے کے بعد، develop میں پہلے سے ہی اصلاح موجود ہے۔ اگر بگ صرف ریلیز برانچ میں متعارف کرایا گیا تھا (cherry-pick کے ذریعے غلطی جمع ہوئی)، تو develop میں اصلاح کی ضرورت نہیں ہو سکتی۔ بنیادی وجہ کا تجزیہ یہ طے کرنے میں مدد کرتا ہے کہ develop میں cherry-pick ضروری ہے یا نہیں۔

ہاٹ فکس کے خطرات اور انہیں کیسے کم کیا جائے

ہاٹ فکس کا بنیادی خطرہ عجلت کی وجہ سے ایک نیا، زیادہ سنگین بگ متعارف کرانا ہے۔ Stripe (2021) کے ایک مطالعے کے مطابق، 15% ہاٹ فکس ریگریشن کا سبب بنتے ہیں اور دوسرے hotfix کی ضرورت ہوتی ہے۔ یہ ستم ظریفی کا قانون ہے: جتنی تیزی سے ہم ٹھیک کریں گے، غلطی کرنے کا امکان اتنا ہی زیادہ ہوگا۔ خطرے میں کمی ڈیف سائز کی سخت حد (30 لائنوں سے زیادہ نہیں) اور لازمی خودکار اسموک ٹیسٹ کے ذریعے حاصل کی جاتی ہے۔

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

تیسرا خطرہ — نفسیاتی۔ باقاعدہ ہاٹ فکس ٹیم کو تھکا دیتے ہیں: آن کال ڈویلپر مسلسل دباؤ میں رہتے ہیں، کوڈ ریویو ایک رسم بن جاتا ہے (ہر کوئی تیز کرنا چاہتا ہے)، اور معیار کی ثقافت گر جاتی ہے۔ ایک پختہ ٹیم کے لیے عام ہاٹ فکس فریکوئنسی 1–2 فی سہ ماہی ہے۔ اگر زیادہ — مسئلہ hotfix میں نہیں، بلکہ منصوبہ بند ریلیز کے معیار میں ہے۔

ہاٹ فکس کے بعد کیا کریں

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

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