تجميد الميزات وتجميد الكود في تطوير التطبيقات: الجوهر والاختلافات والدور

ما هو تجميد الميزات؟

تجميد الميزات هو حظر مؤقت لإضافة وظائف جديدة إلى قاعدة الكود، يُقدم قبل الإطلاق المخطط له. يتوقف الفريق عن دمج الميزات وينتقل إلى إصلاح الأخطاء والتحسين وصقل الكود الحالي. يكمل المطورون الميزات غير المكتملة فقط ضمن نطاق إصلاحات الأخطاء، دون توسيع النطاق.

يحل تجميد الميزات مشكلة الميزات قيد العمل (work-in-progress) التي لا تصل إلى الإطلاق ولكنها مدمجة جزئياً بالفعل في الفرع الرئيسي. إذا استمر دمج الميزات الجديدة، يزداد خطر الانحدار: كل تكامل جديد يتطلب إعادة اختبار للوحدات المكتملة بالفعل. تجميد الميزات يثبت نطاق الإطلاق، محولاً إياه من هدف متحرك إلى مجموعة مستقرة من الوظائف.

توضيح مهم: تجميد الميزات ≠ تجميد الكود. أثناء تجميد الميزات، يُسمح بإصلاحات الأخطاء وإعادة الهيكلة وتحديث التبعيات والتوثيق. فقط الوظائف الجديدة المرئية للمستخدم محظورة — أي كود يغير سلوك التطبيق من منظور المستخدم. التحقق في مراجعة الكود: إذا أضاف PR شاشة جديدة أو زراً أو طريقة API جديدة — يتم رفضه حتى رفع التجميد.

ما هو تجميد الكود وكيف يختلف عن تجميد الميزات

تجميد الكود هو ممارسة أكثر صرامة حيث تُمنع جميع التغييرات في الكود تماماً. حتى إصلاحات الأخطاء غير مسموحة ما لم تكن حرجة. يُقدم تجميد الكود لفترة قصيرة (عادة 24-48 ساعة) ويضمن أن بناء الإصدار تم تجميعه من مجموعة ثابتة من الالتزامات.

الفرق بين تجميد الميزات وتجميد الكود يكمن في مستوى التحكم. يدير تجميد الميزات النطاق: ما الذي سيدخل بالضبط في الإصدار. يدير تجميد الكود الجودة: يزيل خطر إدخال خطأ جديد في اليوم السابق للإطلاق. عملياً، تستخدم العديد من الفرق نموذجاً من مرحلتين: قبل الإطلاق بأسبوع إلى أسبوعين — تجميد الميزات، قبل 24-48 ساعة — تجميد الكود. تجميد الكود ذو أهمية خاصة للتطبيقات المحمولة، حيث يجب رفع البناء إلى المتجر قبل عدة أيام من تاريخ الإطلاق المخطط له.

الاستثناء من تجميد الكود هو إصلاحات الأمان للثغرات الحرجة (CVE بتقييم 9+). تمر هذه التغييرات عبر عملية طارئة مع مراجعة كود سريعة إلزامية وإخطار الفريق. جميع التغييرات الأخرى تؤجل إلى دورة الإطلاق التالية.

تجميد الميزات مقابل تجميد الكود: مقارنة

الاختيار بين تجميد الميزات وتجميد الكود يعتمد على نضج الفريق وتكرار الإصدارات. الفرق التي تستخدم CI/CD و feature flags قد تحتاج فقط إلى تجميد كود لمدة 24 ساعة، بينما الفرق ذات الإصدارات الشهرية تستخدم كلا التجميدين بالتتابع.

أنواع التجميدات: الكامل والجزئي وتجميد BAU

بالإضافة إلى تجميد الميزات الكامل وتجميد الكود، توجد خيارات أكثر مرونة. التجميد الجزئي للميزات يمنع الوظائف الجديدة فقط في وحدات معينة — على سبيل المثال، في وحدة الدفع أو وحدة التفويض، تاركاً المكونات الأخرى مفتوحة للتغييرات.

تجميد BAU (business as usual freeze) هو خيار وسط حيث تُمنع فقط الميزات الكبيرة التي يتجاوز حجم تغييراتها حداً معيناً (مثلاً 500 سطر من الكود). التحسينات الصغيرة وتعديلات واجهة المستخدم وإصلاحات الأخطاء تستمر في الدمج. تجميد BAU مناسب للمشاريع ذات التسليم المستمر، حيث يكون التوقف الكامل للتطوير لمدة أسبوع غير مجدٍ اقتصادياً.

يوجد أيضاً مفهوم تجميد النشر (deployment freeze) — توقف كامل لنشر الإصدارات على الإنتاج، وهو سمة مميزة لموسم العطلات (عطلات عيد الميلاد، الجمعة السوداء). خلال هذه الفترة، حتى الإصلاحات العاجلة تُمنع ما لم تكن متعلقة بالأمان. يستمر تجميد النشر عادة من أسبوع إلى أسبوعين ويتم التنسيق على مستوى الشركة.

متى يتم تقديم التجميد وكم يستمر

الوقت الأمثل لتقديم تجميد الميزات هو بعد اكتمال الكود، عندما تكون جميع الميزات المخطط لها مدمجة وتخضع لضمان الجودة. يعتمد التوقيت الدقيق على دورة الإطلاق: للسباق ثنائي الأسبوع، يُقدم تجميد الميزات قبل 3-4 أيام من تاريخ الإطلاق؛ للإطلاق الشهري، قبل 7-10 أيام. تجميد الكود يُقدم قبل 24-48 ساعة من وقت بناء الإصدار المخطط.

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

الممارسة الموصى بها هي تحديد التجميد ليس حسب تاريخ التقويم بل حسب حالة قاعدة الكود. يُقدم تجميد الميزات عندما يتجاوز عدد الأخطاء المفتوحة للإصدار حداً معيناً (مثلاً 10 أخطاء حرجة). تجميد الكود — عندما يجتاز البناء اختبارات الدخان ومجموعة اختبارات الانحدار بنجاح. التجميد الزمني (تاريخ ثابت) يظل المعيار للصناعات المنظمة (التقنية المالية، التقنية الطبية) حيث تاريخ الإطلاق معتمد من جهة تنظيمية.

أتمتة التجميدات عبر CI/CD و Git

التحكم اليدوي في التجميدات هو مصدر للأخطاء: قد يقوم المطور بدمج PR عن طريق الخطأ يجب أن ينتظر حتى رفع التجميد. تحل الأتمتة هذه المشكلة عبر قواعد حماية الفروع في Git وخطوط أنابيب CI/CD. في مزود Git (GitHub, GitLab, Bitbucket)، تُكوّن قواعد تمنع الدمج في فرع الإصدار بدون علامة خاصة أو موافقة من مدير الإصدار.

خط أنابيب CI/CD يتحقق من حالة التجميد قبل بناء الإصدار. في Jenkins أو GitLab CI أو GitHub Actions، تُضاف خطوة تقرأ ملف تكوين بجدول التجميدات وترفض البناء إذا كان التاريخ الحالي يقع ضمن فترة التجميد. بديل هو feature flag في لوحة الإدارة يمنع النشر على الإنتاج.

# .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 ليس ميزة، بل دين تقني») يضعف حدود التجميد. إذا تجاوزت الاستثناءات 20% من تدفق PR العادي، لا يعمل التجميد. يقوم الفريق ببساطة بإعادة تسمية الميزات كإصلاحات أخطاء لتجاوز الحظر.

الخطأ الثالث هو تجاهل الإصدارات المرشحة. إذا كان الفريق لا يبني إصدارات مرشحة وينشر مباشرة على الإنتاج بعد تجميد الكود، يُفقد معنى التجميد: يكتشف المستخدمون الأخطاء. يجب بناء الإصدار المرشح قبل تجميد الكود، واختباره من قبل ضمان الجودة وعلى بيئة الاختبار، وفقط بعد تأكيد الجودة يتم تقديم تجميد الكود.

الخطأ الرابع هو العامل البشري في التحكم اليدوي. قد ينسى المطور التحقق من حالة التجميد قبل الدمج، قد يفوت مدير الإصدار إشعاراً. الحل الوحيد الموثوق هو الحظر التلقائي على مستوى مزود Git أو CI/CD، مما يلغي الخطأ البشري.