مقدمة
كانت ترقية قاعدة بيانات Odoo تعني ملفات dump، وتذاكر دعم، ونافذة طويلة من «رجاءً لا تلمسوا النظام». أما على Odoo.sh فسير العمل كله مدمج داخل المنصة — فرّع فرعًا، واضغط Test Upgrade، وتتكفّل خدمة upgrade.odoo.com الرسمية بالعمل الثقيل في الخلفية.
لكن للأتمتة حدودًا. فإن لم تكن وحداتك المخصّصة متوافقة مع الإصدار المستهدف، فشلت الترقية. وإن تخطّيت بيئة الاختبار، خاطرت بساعات من التوقف غير المخطط له. يستعرض هذا الدليل سير العمل الذي ينجح فعلًا على أرض الواقع — الترتيب، والمطبّات، وشبكات الأمان.
سير العمل عبر ثلاثة فروع
كل ترقية على Odoo.sh تسلك المسار نفسه: Development → Staging → Production. ولكل فرع دور محدد.
┌───────────────────────────────────────┐
│ PRODUCTION (v18) │
└─────────────────┬─────────────────────┘
│ fork
▼
┌───────────────────────────────────────┐
│ 1. DEVELOPMENT (v19) │
│ • Bump Odoo version in settings │
│ • Upgrade your custom modules │
│ • Verify on an empty DB │
└─────────────────┬─────────────────────┘
│ drag → staging
▼
┌───────────────────────────────────────┐
│ 2. STAGING (Test Upgrade) │
│ • "Test Upgrade" sends a copy of │
│ production to upgrade.odoo.com │
│ • Restored as the staging DB │
│ • You test on real data │
└─────────────────┬─────────────────────┘
│ merge upgraded code
▼
┌───────────────────────────────────────┐
│ 3. PRODUCTION (v19) │
│ • Auto backup → upgrade → restore │
│ • Auto rollback if anything fails │
└───────────────────────────────────────┘كل خطوة تحجز التي تليها. لا تبدأ Test Upgrade على Staging قبل أن تُبنى وحداتك المخصّصة بنجاح على فرع التطوير، ولا تدفع إلى الإنتاج أبدًا قبل أن تنجح Test Upgrade على Staging.
الخطوة 1 — تجهيز فرع تطوير
المهمة الأولى هي جعل شيفرتك المخصّصة متوافقة مع الإصدار المستهدف. خدمة الترقية من Odoo لا ترقّي الوحدات المخصّصة — هذا الجزء مسؤوليتك أنت.
- من لوحة تحكم Odoo.sh، فرّع فرع Production إلى فرع Development جديد (مثل
upgrade-v19). - افتح Settings الخاص بالفرع، وابحث عن حقل Odoo version، وغيّره إلى الإصدار المستهدف (مثل
19.0). - ادفع تغييرات الشيفرة التي ترفع كل وحدة مخصّصة إلى واجهة برمجة الإصدار الجديد: المزخرفات المهجورة، وصياغة الحقول، وعناصر الواجهات، وتبعيات ملف manifest.
- انتظر حتى ينجح البناء. صار الفرع الآن يُقلع على إصدار Odoo المستهدف بقاعدة بيانات فارغة، فتظهر أخطاء الإقلاع في شيفرتك المخصّصة هنا أولًا.
نصيحة: اجعل شيفرتك المخصّصة تعمل على قاعدة بيانات فارغة أولًا. فإن لم تستطع التثبيت من جديد على v19، فلن تصمد أمام ترقية حقيقية أيضًا.
الخطوة 2 — تشغيل «Test Upgrade» على Staging
هنا يُختبر ترحيل قاعدة البيانات الفعلي مقابل بيانات إنتاج حقيقية — لكن في عزلة.
- من لوحة تحكم Odoo.sh، اسحب فرع التطوير إلى مرحلة Staging.
- افتح فرع Staging الجديد وانتقل إلى تبويب Upgrade.
- اضغط Test Upgrade واختر الإصدار المستهدف.
- يرسل Odoo.sh آخر نسخة احتياطية يومية من الإنتاج إلى upgrade.odoo.com. تُرقّي المنصة مخطط قاعدة البيانات وبيانات الوحدات القياسية، ثم تعيد ملف dump المُرقّى، فيُستعاد تلقائيًا على فرع Staging لديك.
- وبمجرد أن يعمل البناء، راجع سجل الترقية:
tail -n 200 ~/logs/upgrade.log- عالِج كل خطأ وتحذير قبل المتابعة.
- اختبر كل سير عمل حرج كما يفعل مستخدم حقيقي: أوامر البيع، والفواتير، والإقفالات المحاسبية، والتقارير المخصّصة، والتكاملات. وعامِل أي سلوك غريب على أنه مانع للإطلاق.
الخطوة 3 — الترقية إلى بيئة الإنتاج
بعد أن تنجح Staging وتطمئن:
- ادمج الشيفرة المُرقّاة من فرع Staging في Production. وتأكد أن الإصدار في ملفات
__manifest__.pyوفي إعدادات الفرع يطابق الإصدار المستهدف. - أبلغ المستخدمين بنافذة الصيانة — فبيئة الإنتاج ستكون غير متاحة لفترة وجيزة.
- من تبويب Upgrade في فرع الإنتاج، اضغط Upgrade.
- يأخذ Odoo.sh نسخة احتياطية تلقائيًا، ويرسل قاعدة بيانات الإنتاج إلى upgrade.odoo.com، ثم يستعيد النتيجة المُرقّاة في مكانها.
- وإن فشل أي شيء، تتراجع المنصة تلقائيًا إلى النسخة الاحتياطية السابقة للترقية. فلن تبقى عالقًا.
من يتولّى ماذا
أكبر سبب منفرد لفشل ترقيات Odoo هو الالتباس في حدود المسؤولية. وهذا هو الخط الفاصل:
| ما تتولّاه أنت | ما يتولّاه Odoo.sh / upgrade.odoo.com |
|---|---|
| تحديث الشيفرة المصدرية لوحداتك المخصّصة | ترقية شيفرة الوحدات القياسية |
| إصلاح واجهات البرمجة المهجورة وصياغة الواجهات | تحويل مخطط قاعدة البيانات |
| دفع شيفرة متوافقة مع الإصدار | ترحيل بيانات الوحدات القياسية |
| ضبط الإصدار المستهدف في إعدادات الفرع | إنتاج ملف dump المُرقّى |
| اختبار مسارات العمل على Staging | استعادة ملف dump على فرعك |
| اعتماد الترقية إلى الإنتاج | أخذ نسخة احتياطية من الإنتاج قبل الترقية |
| إبلاغ المستخدمين بفترة التوقف | التراجع تلقائيًا عند الفشل |
إن فشلت ترقيتك، فانظر إلى الجدول. الإجابة تكاد تكون دائمًا في عمود «ما تتولّاه أنت».
مطبّات تسبّب توقفًا حقيقيًا
تخطّي الإصدارات الوسيطة. يرقّي Odoo إصدارًا بعد إصدار. فالقفزة من 17 إلى 19 تمر داخليًا عبر 18. ويجب أن تعمل وحداتك المخصّصة على الهدف النهائي — لكنك لا تكتب شيفرة وسيطة.
مواصلة التطوير أثناء الترقية. كل إيداع جديد على الإنتاج خلال نافذة الترقية يعني إعادة الاختبار على Staging. جمّد قاعدة الشيفرة من لحظة بدء Test Upgrade.
تجاهل التأثير المتسلسل. تغيير رقم الإصدار في وحدة واحدة يفرض ترقية كل وحدة تعتمد عليها — ويُظهر تحذيرات الإهمال الخاملة في صورة أعطال صريحة. وقد تناولنا هذا النمط من الفشل بالتحديد في لماذا يعطّل تغيير رقم الإصدار بناء Odoo.sh.
نسيان وحدات الأطراف الثالثة. وحدات OCA أو متجر التطبيقات التي ليس لها إصدار متوافق مع النسخة المستهدفة ستوقف الترقية تمامًا. دقّق التبعيات قبل البدء.
تخطّي بيئة Staging. عبارة «نجحت على فرع التطوير» لا تعني شيئًا — فالتطوير يستخدم قاعدة بيانات فارغة. وTest Upgrade على بيانات إنتاج حقيقية هو التحقق الوحيد ذو المعنى.
الخلاصة
أفضل طريقة للتفكير في ترقيات Odoo.sh هي اعتبارها مسارين متوازيين: الشيفرة (شيفرتك أنت) والبيانات (بيانات Odoo). تتولّى المنصة تحويل البيانات، والنسخ الاحتياطي التلقائي، والتراجع. وتتولّى أنت جعل وحداتك متوافقة، والتحقق من أن العمل ما زال يسير بعد الترقية.
والترتيب مهم: development → staging → production، مع تجميد للشيفرة بينها. تخطَّ خطوة وستدفع الثمن توقفًا. اتبع سير العمل وستهبط معظم الترقيات بسلام — بل بملل.
وإن كنت تحدّق في upgrade.log فاشل ولا تعرف من أين تبدأ، فالرسالة التي تبحث عنها نادرًا ما تخص قاعدة البيانات. إنها تكاد تكون دائمًا عن وحدة لم تكن جاهزة.
