هات‌فیکس در توسعه برنامه‌ها: ماهیت، مکانیزم و چگونگی استفاده

هوت‌فیکس چیست و چه زمانی نیاز است؟

هوت‌فیکس (اصلاح داغ) — وصله‌ای برای نسخه تولیدی برنامه است که خارج از نوبت برای رفع یک مشکل حیاتی منتشر می‌شود. هوت‌فیکس در عرض ساعت‌ها به کاربران تحویل می‌شود، نه روزها، و صرفاً برای موقعیت‌هایی در نظر گرفته شده که برنامه در دسترس نیست، داده از دست می‌دهد یا امنیت کاربران را نقض می‌کند.

سناریوهای معمول برای hotfix: crash در راه‌اندازی روی دستگاه‌های خاص (رگرسیون پس از آخرین انتشار)، نشت داده‌های شخصی به دلیل احراز هویت نادرست، عدم کارکرد یکپارچه‌سازی پرداخت (از دست دادن درآمد)، نقض انطباق GDPR/CCPA. همه این موقعیت‌ها severity P0 یا P1 در طبقه‌بندی حوادث دارند. وظایف برنامه‌ریزی‌شده — بهینه‌سازی، بازسازی، صفحه جدید — هرگز از طریق hotfix انجام نمی‌شوند.

قاعده مهم: hotfix شامل حداقل تعداد تغییرات است (1-2 فایل، 10-20 خط کد). هرچه diff کوچک‌تر باشد، ریسک ورود خطای جدید کمتر است. اگر برای رفع نیاز به تغییر معماری یا افزودن ماژول جدید باشد — این hotfix نیست، بلکه emergency release است که نیاز به code review کامل و QA دارد.

تفاوت hotfix با انتشار معمولی

تفاوت‌های اصلی بین hotfix و انتشار برنامه‌ریزی‌شده سرعت، حجم تغییرات و سطح آزمایش است. انتشار برنامه‌ریزی‌شده می‌تواند ده‌ها ویژگی را شامل شود، چرخه کامل QA (regression + integration + UI tests) را طی کند و 1-2 هفته از code freeze تا استقرار طول بکشد. Hotfix شامل یک یا دو اصلاح است، از بازبینی سریع (۲ تأیید به جای ۳) و حداقل smoke test عبور می‌کند.

از نظر فرآیند Git، hotfix از تگ انتشار ایجاد می‌شود، نه از شاخه develop. این تضمین می‌کند که فقط تغییرات لازم برای رفع مشکل وارد hotfix شوند، بدون تصادف گرفتن ویژگی‌های ناتمام از develop. پس از استقرار، hotfix به main و develop بازگردانده می‌شود (از طریق cherry-pick یا merge).

مقایسه انتشار برنامه‌ریزی‌شده و hotfix

مهم: هر کار فوری hotfix نیست. اگر مدیر می‌گوید «فوری باید دکمه اضافه شود» — این hotfix نیست، بلکه تغییر اولویت است. hotfix واقعی با severity برای کاربر تعیین می‌شود، نه فوریت برای کسب‌وکار. معیار: اگر برنامه crash نمی‌کند و داده نشت نمی‌کند — کار منتظر انتشار برنامه‌ریزی‌شده می‌ماند.

فرآیند hotfix: از تشخیص تا استقرار

اولین گام پس از تشخیص مشکل حیاتی، triage — ارزیابی سریع severity است. توسعه‌دهنده شیفت (on-call engineer) باگ را تأیید می‌کند، لاگ‌ها و crash reportها را بررسی می‌کند، تعیین می‌کند که آیا مشکل رگرسیون آخرین انتشار است یا یک باگ دیرینه. اگر severity P0 باشد — خط لوله hotfix راه‌اندازی می‌شود. مرحله triage نباید بیش از ۱۵ دقیقه طول بکشد.

گام دوم — ایجاد شاخه از آخرین تگ انتشار (v2.5.0 → hotfix/v2.5.1). توسعه‌دهنده حداقل اصلاح را اعمال می‌کند، با پیشوند HOTFIX در پیام commit می‌کند، push می‌کند و PR با برچسب [HOTFIX] باز می‌کند. Fast-track code review: دو بازبین به طور خودکار از طریق CODEOWNERS تعیین می‌شوند، زمان بازبینی — حداکثر ۳۰ دقیقه. اگر در ۲۰ دقیقه تغییری نباشد — بازبین رد می‌شود، بعدی تعیین می‌شود.

گام سوم — ساخت و استقرار از طریق CI/CD. خط لوله hotfix با معمولی تفاوت دارد: تست‌های یکپارچه‌سازی طولانی (ساعت‌ها) حذف می‌شوند، فقط smoke suite اجرا می‌شود (10-15 سناریوی حیاتی، 5-10 دقیقه). پس از استقرار نظارت: crash rate، error rate، API latency — به مدت ۳۰ دقیقه. DORA metrics برای hotfixها: زمان بازیابی (MTTR) باید کمتر از ۱ ساعت باشد.

# .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

در این خط لوله بهینه‌سازی‌های کلیدی: بررسی diff (حداکثر ۳۰ خط)، حذف تست‌های یکپارچه‌سازی، استقرار خودکار روی staging و production در صورت موفقیت smoke test. HOTFIX_MODE متغیر محیطی بررسی‌های اضافی را در زمان اجرا فعال می‌کند — مثلاً لاگ‌گیری گسترده برای تشخیص سریع مشکلات.

شاخه‌های hotfix در Git: استراتژی صحیح

استراتژی کار با شاخه‌های hotfix در Gitflow Workflow شرح داده شده است. قاعده اصلی: شاخه hotfix از آخرین تگ انتشار ایجاد می‌شود (git checkout -b hotfix/v2.5.1 tags/v2.5.0)، نه از develop یا main. این تضمین می‌کند که hotfix بر اساس همان وضعیت کدی است که در حال حاضر روی تولید است و تغییرات ناتمام از develop را تصادفی نمی‌گیرد.

پس از اتمام اصلاح، شاخه hotfix با main (یا master) و develop ادغام می‌شود. به main — commit merge معمولی با تگ انتشار اصلاحی جدید (v2.5.1). به develop — merge یا cherry-pick، بسته به سیاست تیم. اگر develop تغییرات بیشتری نسبت به main دارد، cherry-pick commit خاص hotfix برای جلوگیری از تداخل توصیه می‌شود. GitFlow ادغام hotfix ابتدا به main و سپس main به develop را توصیه می‌کند.

# ایجاد شاخه hotfix از آخرین تگ انتشار
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

مهم: اگر hotfix باگی را که در شاخه develop فعلی وجود دارد رفع می‌کند (باگ چند اسپرینت قبل وارد شده)، پس از ادغام hotfix به main و develop، develop قبلاً اصلاح را شامل می‌شود. اگر باگ فقط در شاخه انتشار وارد شده (از طریق cherry-pick باگ انباشته شده)، در develop ممکن است اصلاح لازم نباشد. Root cause analysis به تعیین نیاز به cherry-pick در develop کمک می‌کند.

ریسک‌های hotfix و نحوه کاهش آنها

ریسک اصلی hotfix — ورود خطای جدید و جدی‌تر به دلیل عجله. بر اساس تحقیقات Stripe (2021)، ۱۵٪ hotfixها باعث رگرسیون می‌شوند و نیاز به hotfix دوم دارند. این قانون شانس است: هرچه سریع‌تر رفع کنیم، احتمال اشتباه بیشتر است. کاهش ریسک با محدودیت شدید اندازه diff (حداکثر ۳۰ خط) و smoke test خودکار اجباری حاصل می‌شود.

ریسک دوم — انباشت بدهی فنی. اگر تیم به طور منظم از hotfixها به جای انتشارهای برنامه‌ریزی‌شده استفاده کند، پایه کد تنزل می‌یابد: commitهای hotfix بازسازی نمی‌شوند، راه‌حل‌های موقت با راه‌حل‌های صحیح جایگزین نمی‌شوند، مستندات به‌روز نمی‌شوند. Health check: اگر hotfixها بیش از یک بار در ماه منتشر شوند — فرآیند انتشار نیاز به بازبینی دارد.

ریسک سوم — روانی. hotfixهای منظم تیم را فرسوده می‌کنند: توسعه‌دهندگان on-call در استرس دائمی هستند، code review تشریفاتی می‌شود (همه می‌خواهند سریع‌تر)، فرهنگ کیفیت کاهش می‌یابد. فراوانی طبیعی hotfixها برای تیم بالغ 1-2 در هر سهماهه است. اگر بیشتر — مشکل در hotfixها نیست، بلکه در کیفیت انتشارهای برنامه‌ریزی‌شده است.

پس از hotfix چه باید کرد

پس از استقرار hotfix و تثبیت معیارها، post-mortem (retrospective بدون سرزنش) انجام می‌شود. تیم به چهار سؤال پاسخ می‌دهد: چه اتفاقی افتاد، چرا بررسی‌ها باگ را نگرفتند، چه کاری برای رفع انجام شد، چگونه از تکرار جلوگیری کنیم. Post-mortem ظرف ۲۴-۴۸ ساعت پس از hotfix، در حالی که جزئیات در حافظه تازه هستند، انجام می‌شود. Blameless culture — اصل کلیدی: فرآیندها بحث می‌شوند، نه افراد.

نتیجه post-mortem — action items مشخص با افراد مسئول و مهلت‌ها. action items معمولی: افزودن unit test برای موردی که از قلم افتاده، گسترش smoke test suite، بهبود نظارت (افزودن هشدار برای معیار)، به‌روزرسانی runbook برای حوادث مشابه. Action items باید قبل از انتشار برنامه‌ریزی‌شده بعدی انجام شوند.