التصليح السريع في تطوير التطبيقات: الماهية، الآلية وكيفية التطبيق

ما هو hotfix ومتى يحتاج إليه؟

Hotfix (تصليح سريع) هو تصميمة لنسخة الإنتاج من التطبيق تُطلق خارج الدور لإصلاح مشكلة حرجة. يتم توصيل hotfix إلى المستخدمين في ساعات، ليس في أيام، وهو مصمم فقط للحالات التي يكون فيها التطبيق غير متاح أو يفقد البيانات أو يعرض أمان المستخدم للخطر.

السيناريوهات النموذجية لاستخدام hotfix: تعطل عند البدء على أجهزة معينة (انتكاس بعد آخر إصدار)، تسريب البيانات الشخصية بسبب ترخيص غير صحيح، تكامل الدفع المعطل (فقدان الإيرادات)، انتهاكات الامتثال لـ GDPR/CCPA. تمتلك كل هذه الحالات خطورة P0 أو P1 في تصنيف الحوادث. المهام المخططة — التحسين، إعادة الهندسة، شاشات جديدة — لا تتم أبداً عبر hotfix.

قاعدة مهمة: يحتوي hotfix على عدد أدنى من التغييرات (ملف 1–2، 10–20 سطر من الكود). كلما كان الفرق أصغر، قل خطر إدخال خطأ جديد. إذا كان إصلاح المشكلة يتطلب تغيير الهندسة أو إضافة وحدة جديدة — فهذا ليس hotfix، بل إصدار طارئ يتطلب مراجعة كاملة للكود واختبارات QA شاملة.

ما الفرق بين hotfix والإصدار العادي

الاختلافات الرئيسية بين hotfix والإصدار المخطط هي السرعة، حجم التغييرات ومستوى الاختبارات. قد يشمل الإصدار المخطط عشرات الميزات، ويمر بدورة كاملة لضمان الجودة (اختبارات الانتكاس + التكامل + واجهة المستخدم)، ويستغرق من أسبوع إلى أسبوعين من تجميد الكود إلى النشر. Hotfix يشمل إصلاحاً أو اثنين، ويمر بمراجعة متسارعة (موافقتان بدلاً من 3) واختبار smoke أدنى.

من وجهة نظر عملية Git، يتم إنشاء hotfix من وسم إصدار، ليس من فرع develop. يضمن ذلك عدم تضمين التغييرات غير المكتملة من develop في hotfix بالإضافة إلى التغييرات الضرورية فقط. بعد النشر، يتم دمج hotfix مرة أخرى في main و develop (عبر cherry-pick أو merge).

مقارنة بين الإصدار المخطط و hotfix

مهم: ليست كل مهمة عاجلة هي hotfix. إذا قال المدير «نحتاج بشكل عاجل لإضافة زر» — هذا ليس hotfix، بل تغيير أولوية. يتم تحديد hotfix الحقيقي من خلال الخطورة على المستخدم، ليس العجلة للأعمال. المعيار: إذا لم يكن التطبيق يتعطل والبيانات لا تتسرب — تنتظر المهمة الإصدار المخطط.

عملية hotfix: من الاكتشاف إلى النشر

الخطوة الأولى عند اكتشاف مشكلة حرجة هي الفرز — تقييم سريع للخطورة. يؤكد مهندس المناوبة الخطأ، ويتحقق من السجلات وتقارير التعطل، ويحدد ما إذا كانت المشكلة انتكاساً من آخر إصدار أو خطأ قديماً. إذا كانت الخطورة P0 — يتم تشغيل خط أنابيب hotfix. مرحلة الفرز لا يجب أن تستغرق أكثر من 15 دقيقة.

الخطوة الثانية — إنشاء فرع من أحدث وسم إصدار (v2.5.0 → hotfix/v2.5.1). يقوم المطور بإجراء أدنى إصلاح، وينشئ كوميت ببادئة HOTFIX في الرسالة، ويدفع ويفتح PR بوسم [HOTFIX]. مراجعة الكود fast-track: يتم تعيين مراجعين تلقائياً عبر CODEOWNERS، وقت المراجعة لا يتجاوز 30 دقيقة. إذا لم يتم المراجعة خلال 20 دقيقة — يتم تجاوز المراجع وتعيين التالي.

الخطوة الثالثة — البناء والنشر عبر CI/CD. يختلف خط أنابيب hotfix عن العادي: يتم تخطي اختبارات التكامل الطويلة (التي تستغرق ساعات)، يتم تشغيل مجموعة smoke فقط (10–15 سيناريو حرج، 5–10 دقائق). بعد النشر: مراقبة معدل التعطل ومعدل الأخطاء وزمن استجابة API — لمدة 30 دقيقة. مقاييس DORA للهوتفيكس: متوسط وقت الاستعادة (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

التحسينات الرئيسية في هذا الخط الأنابيب: التحقق من الفرق (لا يتجاوز 30 سطراً)، تخطي اختبارات التكامل، النشر التلقائي على بيئة الاختبار والإنتاج عند نجاح اختبار smoke. 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 — كوميت دمج عادي مع وسم إصدار تصميخ جديد (v2.5.1). في develop — دمج أو cherry-pick، حسب سياسة الفريق. إذا كان develop يحتوي على تغييرات أكثر من main، فينصح باستخدام cherry-pick لكوميت 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. تحليل السبب الجذري يساعد في تحديد ما إذا كان cherry-pick في develop ضرورياً.

مخاطر hotfix وكيفية تقليلها

الخطر الرئيسي لـ hotfix هو إدخال خطأ جديد أكثر خطورة بسبب العجلة. وفقاً لدراسة Stripe (2021)، 15% من الهوتفيكسات تسبب انتكاساً وتتطلب hotfix ثانياً. هذه قاعدة السخرية: كلما أصلحنا بسرعة أكبر، زادت احتمالية ارتكاب خطأ. تقليل المخاطر يتحقق عن طريق التقييد الصارم لحجم الفرق (لا يتجاوز 30 سطراً) واختبارات smoke تلقائية إلزامية.

الخطر الثاني — تراكم الدين التقني. إذا كان الفريق يستخدم hotfix بانتظام بدلاً من الإصدارات المخططة، فإن قاعدة الكود تتدهور: لا تمر كوميتات hotfix بإعادة الهندسة، لا يتم استبدال الحلول المؤقتة بحلول صحيحة، لا يتم تحديث الوثائق. فحص الصحة: إذا كانت hotfix تصدر أكثر من مرة في الشهر — فإن عملية الإصدار تتطلب المراجعة.

الخطر الثالث — نفسي. الهوتفيكسات المنتظمة تستنزف الفريق: مهندسو المناوبة يعيشون تحت ضغط مستمر، تصبح مراجعة الكود شكلية (الجميع يريدون الإسراع)، وتتراجع ثقافة الجودة. تردد hotfix الطبيعي لفريق ناضج هو 1–2 في الربع. إذا كان أكثر — فالمشكلة ليست في hotfix، بل في جودة الإصدارات المخططة.

ماذا تفعل بعد hotfix

بعد نشر hotfix واستقرار المقاييس، يتم إجراء تحليل بعد الحادثة (post-mortem) خالٍ من اللوم. يجيب الفريق على أربعة أسئلة: ماذا حدث، لماذا لم تكتشف الفحوصات الخطأ، ماذا تم لإصلاحه، وكيف يمنع تكراره. يتم إجراء post-mortem خلال 24–48 ساعة بعد hotfix، بينما التفاصيل لا تزال حاضرة. ثقافة عدم اللوم هي مبدأ أساسي: يتم مناقشة العمليات، ليس الأشخاص.

نتيجة post-mortem هي بنود فعل محددة مع أصحاب المسؤولية والمواعيد. بنود الفعل النموذجية: إضافة اختبار وحدة للحالة التي تم تفويتها، توسيع مجموعة اختبارات smoke، تحسين المراقبة (إضافة تنبيه على المقياس)، تحديث runbook للحوادث المماثلة. بنود الفعل يجب أن تكتمل قبل الإصدار المخطط التالي.