يحمل كل إصدار جديد من Odoo تحسينات حقيقية — أداء أفضل وواجهات أوضح وميزات طالما طلبتها فرق عملك. ومع ذلك، ففي كثير من الشركات يُستقبل الإعلان السنوي عن الإصدار الجديد بقلق صامت بدلاً من الترقب. ففي مكان ما داخل النظام يوجد كود مخصص لم يعد أحد يفهمه فهماً كاملاً، والجميع يتوقع أن تؤدي الترقية إلى تعطيله.
نادراً ما يكون هذا الخوف غير مبرر؛ فهو الفاتورة المتوقعة لقرارات اتُّخذت قبل سنوات، وغالباً تحت ضغط المواعيد النهائية: تعديل سريع داخل نواة Odoo، أو رقعة طُبّقت مباشرة على الخادم، أو ميزة أُضيفت دون اختبارات أو نظام للتحكم في الإصدارات. لقد عمل التخصيص في يومه الأول، لكن الدين يُستحق سداده عند وقت الترقية.
نحن نبني التخصيصات انطلاقاً من فرضية واحدة غير قابلة للتفاوض: هذا النظام سيُرقّى مراراً وتكراراً ما دام قائماً. وهذه الفرضية الوحيدة تغيّر تقريباً كل شيء في طريقة إنجاز العمل.
لماذا يُعد تعديل النواة وقتاً مقترضاً
صُمّم Odoo ليُوسَّع لا ليُعدَّل. فعندما يعدّل جهة التكامل ملفات النواة مباشرة، يندمج التخصيص مع إطار العمل في كتلة واحدة لا يمكن فصلها. ثم يأتي الإصدار التالي فيستبدل ملفات النواة تلك — ومعها، بصمت، كل ما تم ترقيعه فيها. وعندها تواجه الشركة خيارات مؤلمة: إعادة بناء التغييرات بأسلوب التنقيب الأثري، أو الدفع لمن يقارن سنوات من التعديلات غير الموثقة، أو ببساطة التوقف عن الترقية.
تجميد الإصدار هو الخيار الأكثر شيوعاً، وهو الأعلى تكلفة أيضاً. فنظام Odoo المجمّد يعني غياب الإصلاحات الأمنية، وانعدام الميزات الجديدة، واحتكاكاً متزايداً مع الموصلات والمكتبات، وتقلّص عدد الأشخاص المستعدين لصيانته. إن العبث بالنواة لا يوفّر الوقت، بل يحوّل بضع ساعات موفَّرة اليوم إلى عبء هيكلي يتفاقم مع كل دورة إصدار.
ما الذي يعنيه فعلاً التخصيص بمستوى الوحدات البرمجية
البديل ليس تقليل التخصيص — بل إنجاز التخصيص كعمل هندسي لا كارتجال. فكل تغيير نسلّمه يعيش في وحدة برمجية مستقلة توسّع Odoo عبر آليات الوراثة الرسمية لإطار العمل. وتبقى النواة دون أي مساس. وتعلن الوحدة عن اعتمادياتها، وتحمل بياناتها وعروضها واختباراتها الخاصة، ويمكن تثبيتها أو ترقيتها أو إزالتها كوحدة واحدة.
قبل كتابة سطر واحد من الكود المخصص، نتحقق مما إذا كان المجتمع قد حلّ المشكلة بالفعل. فنحن نعمل وفق مبدأ المجتمع أولاً ونعتمد على OCA — جمعية مجتمع Odoo — التي تمثّل وحداتها المنشورة وقواعدها البرمجية أقرب ما يملكه هذا النظام البيئي إلى معيار هندسي مشترك. واتباع تلك القواعد ليس بيروقراطية؛ بل هو ما يتيح لأي مطوّر Odoo كفء، بعد سنوات، أن يفتح الكود ويفهمه.
الانضباط المحيط بالكود لا يقل أهمية عن الكود نفسه. فكل وحدة نسلّمها تُدار إصداراتها في Git بسجل تاريخي واضح، وتمر بمراجعة للكود قبل دمجها، وتُشحن مع اختبارات آلية تثبّت السلوك الذي يُفترض أن تضمنه. وعندما يصل إصدار Odoo التالي، تكون تلك الاختبارات هي الفارق بين التحقق من نجاح الترحيل ومجرد التمني بنجاحه.
اختبار الترقية، وما الذي ينبغي أن تطالب به أي جهة تكامل
لا تكتمل الوحدة البرمجية بمجرد عملها على الإصدار الحالي. فمن ضمن ممارساتنا المعتادة اختبار الوحدات المخصصة على إصدار Odoo التالي — بتشغيل حزمة الاختبارات، وتجربة مسارات العمل الحقيقية، وإصلاح حالات عدم التوافق وهي لا تزال صغيرة. وعند حدوث ترحيل فعلي، يخضع للانضباط نفسه: تجارب تنفيذ على نسخة من البيانات، وتقرير مطابقة يثبت ما تم نقله، وخطة تراجع في حال لم يُنقل شيء ما. وتحت كل ذلك تقبع نسخ احتياطية مُختبرة الاستعادة.
إذا كنت بصدد تقييم جهة تكامل — بما في ذلك نحن — فهذه هي الالتزامات التي تستحق أن تطالب بها كتابةً:
- لا تعديلات على النواة، أبداً. فكل التخصيصات تعيش في وحدات برمجية مخصصة توسّع Odoo عبر الآليات المدعومة.
- الاعتماد على المجتمع أولاً. فوحدة OCA مُصانة أفضل من إعادة كتابة الميزة نفسها من الصفر حسب الطلب.
- تحكم في الإصدارات يمكنك الاطلاع عليه. سجل Git كامل، مع منح العميل حق الوصول إلى الكود الخاص به.
- مراجعة الكود والاختبارات الآلية على كل وحدة برمجية، وليس الكبيرة منها فحسب.
- خطة ترقية مكتوبة. تجارب تنفيذ، وتقرير مطابقة، وخطة تراجع لأي عملية ترحيل.
- سعر قابل للتحقق. عروض أسعار ثابتة بعد تحديد النطاق تحديداً سليماً، بحيث يكون الانضباط مدمجاً في الميزانية بدلاً من الفوترة بساعات إطفاء الحرائق.
- دعم بالتزامات حقيقية. اتفاقيات SLA متدرجة بأزمنة استجابة محددة، وتدريب حسب الأدوار حتى يُستخدم النظام فعلياً بالطريقة التي بُني عليها.
الكود المخصص ليس عدو الترقيات — بل الكود المخصص غير المنضبط هو العدو. فحين تُبنى تخصيصاتك بمستوى الوحدات البرمجية وتُراجَع وتُختبَر وتُدار إصداراتها، تتحول إلى أصول ترافقك من إصدار إلى آخر بدلاً من أن تكون مراسي تقيّدك بإصدار واحد. وإذا كانت قفزة إصدار تلوح في أفقك بالفعل مع وجود وحدات مخصصة ضمن المشهد، فإن منهجيتنا في الترحيل — شاملةً تقارير المطابقة وتجارب التنفيذ وخطط التراجع — معروضة بالتفصيل في صفحة خدماتنا.