Skip to main content
دليل الترقية إلى أودو 20: كيف ترقّي قاعدة بياناتك بأمان
قراءة 17 دقيقة
أودو

دليل الترقية إلى أودو 20: كيف ترقّي قاعدة بياناتك بأمان

تخطط للترقية إلى أودو 20؟ اتبع عملية ترحيل عملية تقوم على الاختبار أولًا في Odoo Online وOdoo.sh والتثبيت المحلي، تشمل الوحدات المخصصة واختبار قبول المستخدم (UAT) والانتقال إلى الإنتاج وفحوصات ما بعد الترقية.

ينبغي التعامل مع الترقية إلى أودو 20 على أنها مشروع ترحيل مضبوط، لا مجرد تبديل للإصدار.

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

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

يشرح هذا الدليل كيفية التخطيط لهذه العملية في Odoo Online وOdoo.sh والتثبيت المحلي (on-premise)، والمواضع التي تتطلب فيها مشاريع أودو المخصصة عملًا هندسيًا إضافيًا.

مهم: صدر أودو 20، لكن إتاحة الترقية إلى الإصدار المستهدف قد تعتمد على الإصدار الحالي، ونموذج الاستضافة، والحالة الراهنة لأدوات الترقية لدى أودو. تحقّق من أن قاعدة بياناتك تحديدًا يمكن ترقيتها إلى أودو 20 قبل الالتزام بموعد للإنتاج.

عملية الترقية إلى أودو 20 في سبع خطوات

بصورة عامة:

  1. تدقيق قاعدة البيانات الحالية.
  2. تجميد التطوير المخصص ومراجعته بعين ناقدة.
  3. طلب قاعدة بيانات اختبارية مرقّاة.
  4. ترقية الوحدات المخصصة وشيفرة التكامل.
  5. إجراء الاختبارات الوظيفية والتقنية واختبارات البيانات.
  6. إجراء تجربة للانتقال إلى الإنتاج.
  7. ترقية بيئة الإنتاج والتحقق منها فورًا.

يبدو هذا التسلسل بسيطًا، لكن العمل الذي يجري داخل الخطوات من 2 إلى 6 هو ما يحدد إن كانت الترقية روتينية أم مُربِكة.

أولًا: افهم ما تعنيه «الترقية» في أودو فعلًا

تميّز أودو بين الترقية والتحديث العادي للبرنامج.

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

أما الترقية فتغيّر قاعدة البيانات بحيث تصبح بنيتها ومحتواها متوافقين مع إصدار رئيسي أحدث. وتصف أودو هذه العملية بأنها لا يمكن التراجع عنها.

كما أن الترقية لا تعني:

  • الانتقال من إصدار Community إلى Enterprise؛
  • تغيير نوع الاستضافة؛
  • الانتقال من نظام تخطيط موارد مؤسسات آخر إلى أودو؛
  • تنظيف بيانات الأعمال الموجودة؛
  • إعادة كتابة كل وحدة مخصصة، سواء أكانت من طرف ثالث أم مطوّرة داخليًا، بصورة تلقائية.

قد تكون هذه مشاريع ذات صلة، لكن لا ينبغي إخفاؤها ضمن نطاق الترقية.

الخطوة 1: دقّق قاعدة البيانات قبل طلب أي شيء

قبل استخدام منصة الترقية، أعدّ جردًا لما تحتويه قاعدة بيانات الإنتاج فعلًا.

سجّل على الأقل ما يلي:

المنصة

  • إصدار أودو الحالي؛
  • الإصدار المستهدف؛
  • Community أم Enterprise؛
  • Odoo Online أم Odoo.sh أم تثبيت محلي؛
  • تفاصيل PostgreSQL والبنية التحتية عند الحاجة.

التطبيقات

  • تطبيقات أودو القياسية المثبتة؛
  • تخصيصات Studio؛
  • الوحدات المأخوذة من Odoo Apps أو من أطراف ثالثة؛
  • الوحدات المطوّرة داخليًا؛
  • الوحدات الموروثة من شريك تنفيذ سابق.

التكاملات

  • تطبيقات الجوال؛
  • بوابات العملاء والموردين؛
  • مزوّدو الدفع؛
  • تكاملات الشحن وشركات النقل؛
  • التبادل الإلكتروني للبيانات (EDI)؛
  • التكاملات المصرفية؛
  • منصات التجارة الإلكترونية (Marketplaces)؛
  • أنظمة الحضور والأجهزة البيومترية؛
  • واجهات API الخارجية والبرمجيات الوسيطة؛
  • اتصالات ذكاء الأعمال (BI) ومستودعات البيانات؛
  • خطافات الويب (webhooks) ومهام المزامنة المجدولة.

السلوك المخصص

  • الإجراءات المؤتمتة؛
  • إجراءات الخادم؛
  • الإجراءات المجدولة؛
  • التقارير المخصصة؛
  • قوالب البريد الإلكتروني المخصصة؛
  • قواعد الوصول المخصصة؛
  • طرق العرض المخصصة؛
  • تعديلات الواجهة الأمامية بـ JavaScript/Owl؛
  • المتحكمات (controllers) ونقاط نهاية API المخصصة؛
  • منطق مخصص للمحاسبة أو المخزون أو التصنيع.

إن لم تستطع الإجابة عن سؤال «ما المخصص هنا؟» قبل الترقية، فستجد صعوبة في إثبات أن قاعدة البيانات المرقّاة تعمل بشكل صحيح بعدها.

الخطوة 2: جمّد التطوير المخصص وراجعه بعين ناقدة

توصي إرشادات أودو الخاصة بقواعد البيانات المخصصة بإيقاف التطوير أثناء عملية الترقية، باستثناء إصلاحات الأخطاء الضرورية.

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

لكن تجميد الشيفرة ليس إلا نصف هذه الخطوة.

فالتمرين الأكثر قيمة هو مراجعة كل تخصيص بعين ناقدة.

اسأل:

  • هل يوفّر أودو 20 الآن هذه الوظيفة بشكل أصيل؟
  • هل ما زال هذا التخصيص مستخدمًا؟
  • هل كان حلًا التفافيًا لقيد لم يعد موجودًا؟
  • هل يمكن الآن استبداله بـ Studio أو بالإعدادات القياسية؟
  • هل ما زالت الوحدة المخصصة تبرّر تكلفة صيانتها؟
  • هل يمكن دمج وحدتين متداخلتين في وحدة واحدة؟

ترقية الإصدار من أفضل الفرص لتقليل الدَّين التقني.

فترحيل تخصيص متقادم بإتقان يبقى جهدًا هندسيًا مهدورًا.

الخطوة 3: اطلب قاعدة بيانات اختبارية مرقّاة

لا تجعل بيئة الإنتاج أول اختبار كامل لك.

تبدأ عملية الترقية الرسمية لدى أودو بقاعدة بيانات اختبارية مرقّاة. ويمكنك طلب عدة ترقيات اختبارية مع تقدّم المشروع.

يعتمد سير العمل الدقيق على نوع الاستضافة.

Odoo Online

في Odoo Online، تتم الترقية عبر المنصة المُدارة من أودو ومدير قواعد البيانات فيها.

عندما يُعرض عليك خيار الترقية، لا تتعامل مع زر Upgrade Now على أنه طريق مختصر لتجاوز الاختبار. اطلب ترقية اختبارية أولًا وتحقّق منها.

ولأن Odoo Online لا يدعم تثبيت وحدات Python مخصصة اعتباطية، فإن نموذج ترحيل الشيفرة المخصصة فيه يختلف اختلافًا كبيرًا عن Odoo.sh والتثبيت المحلي.

Odoo.sh

يتكامل Odoo.sh مع منصة الترقية لدى أودو.

في قاعدة بيانات تحتوي على وحدات مخصصة، يفصل المشروع النموذجي العمل على الشيفرة المخصصة عن بيئة الإنتاج:

  1. جهّز الشيفرة المخصصة للإصدار المستهدف؛
  2. استخدم ترقية في بيئة التجهيز (staging) مبنية على نسخة احتياطية حديثة من الإنتاج؛
  3. دع Odoo.sh يستعيد النسخة الاحتياطية المرقّاة ويحدّث الوحدات المخصصة؛
  4. افحص سجل الترقية؛
  5. أصلح مشكلات ترحيل الشيفرة والبيانات؛
  6. ادفع التعديلات مجددًا وكرّر العملية حتى تنجح الترقية في بيئة التجهيز.

تصف وثائق أودو الحالية وضع التحديث عند كل commit (update-on-commit) لهذه العملية: فدفع commits إلى فرع الترقية يمكن أن يستعيد نسخة احتياطية مرقّاة نظيفة ويحدّث الوحدات المخصصة من جديد.

تكمن قيمة ذلك في أنه يجعل الترحيل قابلًا للتكرار، بدلًا من «إصلاح» قاعدة بيانات اختبارية واحدة طويلة العمر تدريجيًا حتى لا يعود أحد يعرف ما التعديلات اليدوية التي كانت مطلوبة.

التثبيت المحلي

لقواعد البيانات المثبّتة محليًا، توثّق أودو طريقة عبر سطر الأوامر لبدء ترقية اختبارية:

bash
python <(curl -s https://upgrade.odoo.com/upgrade) test \
  -d <your_db_name> \
  -t <target_version>

ينبغي التحقق من متطلبات البيئة الدقيقة ومن إتاحة الإصدار المستهدف في الوثائق الرسمية الحالية قبل تشغيلها.

كما توفّر أودو منصة الترقية الخاصة بها لتقديم طلب الترقية.

لا تنسَ مخزن الملفات (filestore)

في الترقيات التي تُدار بأسلوب التثبيت المحلي، يجب التعامل مع بيانات قاعدة البيانات وملفات المرفقات معًا.

توضح وثائق الترقية الحالية لدى أودو أن نسخة قاعدة البيانات المرسلة إلى خادم الترقية تُرسل من دون مخزن ملفات الإنتاج. ويجب دمج مخزن الملفات المرقّى الناتج مع مخزن ملفات الإنتاج قبل أن تمثّل قاعدة البيانات المستعادة بيئة اختبار واقعية.

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

الخطوة 4: رقِّ الوحدات المخصصة بالتوازي

إذا كانت قاعدة البيانات تحتوي على وحدات Python مخصصة، فإن تحويل قاعدة البيانات وترحيل الشيفرة المصدرية مسؤوليتان منفصلتان.

وتنص أودو صراحةً على أن الشيفرة المصدرية للوحدات المخصصة يجب أن تكون متوافقة مع الإصدار المستهدف قبل أن تنجح الترقية الكاملة.

التسلسل الجيد للوحدات المخصصة هو:

1. اجعل الوحدة قابلة للتثبيت على قاعدة بيانات أودو 20 نظيفة

يكشف ذلك مشكلات التوافق على مستوى إطار العمل من دون التشويش الذي تضيفه بيانات العميل.

راجع:

  • __manifest__.py والاعتماديات؛
  • شيفرة ORM بلغة Python؛
  • النماذج والحقول؛
  • منطق الحساب والعكس (compute/inverse)؛
  • طرق عرض XML؛
  • الإجراءات والقوائم؛
  • قوائم التحكم في الوصول (ACL) وقواعد السجلات؛
  • شيفرة JavaScript/Owl؛
  • حزم الأصول (asset bundles)؛
  • المتحكمات (controllers)؛
  • التقارير؛
  • مهام cron وإجراءات الخادم؛
  • الاختبارات.

2. ثبّتها أو حدّثها على قاعدة بيانات العميل المرقّاة

قد تُثبَّت الوحدة بشكل مثالي على قاعدة بيانات نظيفة، ثم تفشل مع البيانات التاريخية للعميل.

وهنا تصبح أهمية ترحيل البيانات واضحة.

إذا تغيّرت الحقول أو النماذج أو معرّفات XML، فاستخدم سكربتات ترقية مناسبة وأدوات الترقية المساعدة من أودو حيثما يلزم، بدلًا من ترقيع بيانات الإنتاج يدويًا.

3. اختبر ما تغيّره الوحدة فعلًا

نجاح التثبيت ليس قبولًا من جهة الأعمال.

إذا كانت الوحدة تعدّل التصنيع، فأنشئ سيناريوهات تصنيع وأكملها.

إذا كانت تعدّل الرواتب، فتحقّق من قسائم رواتب تمثيلية ومن مخرجاتها المحاسبية.

إذا كانت تعدّل نقاط البيع (POS)، فنفّذ الطلبات والمدفوعات والمرتجعات وإقفال الجلسة.

إذا كانت تعدّل سلوك API، فشغّل التكامل الخارجي.

يجب أن يتتبّع الاختبار الأثر الفعلي للتخصيص على الأعمال.

الخطوة 5: افهم ما لا تختبره قاعدة البيانات الاختبارية المرقّاة

هذا من أسهل جوانب ترقية أودو التي يُساء فهمها.

تقوم أودو بتحييد قواعد البيانات الاختبارية حتى لا تتصرف عن طريق الخطأ كأنها بيئة إنتاج.

وتذكر الوثائق الحالية أن الترقيات الاختبارية تعطّل وظائف أو تغيّرها، ومنها:

  • الإجراءات المجدولة؛
  • خوادم البريد الصادر؛
  • مزوّدو الدفع؛
  • شركات الشحن؛
  • المزامنة المصرفية.

هذا جيد من ناحية الأمان.

لكنه يعني أيضًا أن نتيجة ناجحة في اختبار قبول المستخدم (UAT) لا تثبت تلقائيًا أن كل تكامل في الإنتاج سيعمل بعد الانتقال.

مثال

لنفترض أن تدفق المبيعات لديك كالتالي:

text
Website order
→ payment provider
→ sales order
→ stock reservation
→ carrier label
→ invoice
→ customer email
→ external accounting/BI sync

قد تمنع قاعدة البيانات الاختبارية المحيَّدة عمدًا عدة خطوات خارجية من هذه الخطوات من العمل تمامًا كما في الإنتاج.

لذلك يجب أن تميّز خطة الاختبار بين:

أ. منطق الأعمال الذي يُتحقَّق منه داخل قاعدة البيانات المرقّاة

وبين:

ب. الخدمات الخارجية التي تتطلب بيانات اعتماد لبيئة تجريبية (sandbox)، أو اختبار تكامل مضبوطًا، أو تحققًا فوريًا بعد الإطلاق الفعلي.

ومكان هذا التمييز هو خطة الانتقال.

الخطوة 6: أجرِ اختبار قبول المستخدم من البداية إلى النهاية، لا جولة على الشاشات واحدة تلو الأخرى

فتح القوائم والتأكد من ظهور النماذج لا يكفي.

توصي وثائق الترقية لدى أودو نفسها باختبار تدفقات الأعمال عبر التطبيقات المختلفة.

ابنِ السيناريوهات حول ما يفعله الموظفون فعلًا.

من البيع إلى التحصيل

اختبر:

  1. إنشاء عميل محتمل أو تحويله؛
  2. إعداد عرض سعر؛
  3. تأكيد البيع؛
  4. حجز المنتجات أو تسليمها؛
  5. إصدار الفاتورة؛
  6. تسجيل الدفعة أو اختبار تدفق الدفع؛
  7. التحقق من القيود المحاسبية والتقارير الناتجة؛
  8. اختبار المراسلات مع العملاء.

من الشراء إلى السداد

اختبر:

  1. إنشاء أمر شراء؛
  2. اعتماده حيثما ينطبق ذلك؛
  3. استلام المنتجات؛
  4. التحقق من المسارات والدفعات والأرقام التسلسلية؛
  5. إنشاء فاتورة المورّد؛
  6. التحقق من سلوك الضرائب والحسابات والمحاسبة التحليلية؛
  7. التحقق من سير عمل الدفع والتسوية.

المخزون

تحقّق من:

  • المسارات؛
  • إعادة التزويد؛
  • المستودعات والمواقع؛
  • الطرود؛
  • الدفعات والأرقام التسلسلية؛
  • التحويلات الداخلية؛
  • المرتجعات؛
  • التقييم؛
  • التدفقات بين الشركات حيثما ينطبق ذلك.

التصنيع

تحقّق من:

  • قوائم المواد (BoM)؛
  • التجميعات الفرعية؛
  • أوامر التصنيع؛
  • الاستهلاك؛
  • المنتجات الثانوية؛
  • الجودة؛
  • مراكز العمل؛
  • نتائج المخزون؛
  • الأثر على التكاليف والمحاسبة.

المحاسبة

افعل أكثر من مجرد فتح الميزانية العمومية.

اختبر:

  • فواتير عملاء وفواتير موردين تمثيلية؛
  • الضرائب؛
  • الأوضاع الضريبية (fiscal positions)؛
  • الإشعارات الدائنة؛
  • تدفقات البنوك والتسوية؛
  • المحاسبة التحليلية؛
  • العملات؛
  • السلوك في بيئة متعددة الشركات؛
  • التقارير المالية؛
  • العمليات الخاصة بالتوطين المحلي.

الموقع الإلكتروني والتجارة الإلكترونية

اختبر:

  • الصفحات المهمة؛
  • النماذج؛
  • البحث في المتجر والكتالوج؛
  • سلة التسوق؛
  • إتمام الشراء؛
  • البوابة؛
  • الترجمات؛
  • الصفحات المهمة لتحسين محركات البحث (SEO)؛
  • الدفع والتوصيل في بيئة اختبار مناسبة.

الموارد البشرية والعمليات

اختبر سير العمل الذي تستخدمه فعلًا: الحضور، والإجازات، والرواتب، والمصروفات، والموافقات، والتوظيف، والتخطيط، والخدمة الميدانية، والمستندات.

التكاملات والأتمتة

تنبّه أودو تحديدًا إلى أن التكاملات الخارجية، والتصديرات، والإجراءات المؤتمتة، وإجراءات الخادم عناصر يجب ألا تُنسى.

أنشئ مصفوفة تكاملات منفصلة تتضمن:

التكاملالمسؤولطريقة الاختباربيانات الاعتماد/البيئةالنتيجةفحص الإطلاق الفعلي
مزوّد الدفعالمالية/تقنية المعلوماتمعاملة في بيئة تجريبية (sandbox)بيئة تجريبية (sandbox)قيد الانتظاردفعة حقيقية
شركة الشحنالعملياتملصق شحن تجريبيحساب تجريبيقيد الانتظارملصق شحن حقيقي
تطبيق الجوالالهندسةاختبار انحدار لـ APIقاعدة بيانات اختباريةقيد الانتظارالمصادقة + الاستدعاءات الأساسية
ذكاء الأعمال/مستودع البياناتفريق البياناتمزامنة مضبوطةبيئة التجهيز (staging)قيد الانتظارأول مزامنة حقيقية
البريد الإلكترونيتقنية المعلوماتمحيَّد/يدوياختبارمحدودإرسال حقيقي

الخطوة 7: قارن البيانات، لا السلوك فقط

قد «يعمل» سير العمل بينما تكون البيانات المرحَّلة خاطئة.

اختر سجلات تمثيلية وقارن بين بيئة الإنتاج القديمة وقاعدة البيانات الاختبارية المرقّاة.

أمثلة:

  • فئة المنتج، والسعر، والتكلفة، والحسابات، والمسارات، والموردون؛
  • حقول العملاء والشركات؛
  • أوامر البيع والشراء المفتوحة؛
  • كميات المخزون والأرقام التسلسلية؛
  • الذمم المدينة والدائنة؛
  • إعدادات الضرائب؛
  • العملات؛
  • الأوضاع الضريبية؛
  • صلاحيات وصول الموظفين والمستخدمين؛
  • الأبعاد التحليلية؛
  • عوامل التصفية المحفوظة والترجمات؛
  • المرفقات.

في عمليات التنفيذ التي يغلب عليها الجانب المالي، حدّد إجماليات التسوية قبل الانتقال، حتى يعرف الفريق بالضبط ما الأرقام التي يجب أن تتطابق بعده.

الخطوة 8: اقرأ تقرير الترقية (Upgrade Report)

توفّر أودو تقرير ترقية بعد كل طلب ترقية.

تعامل معه على أنه مُدخل لعملية الاختبار، لا شهادة بأن الاختبار قد اكتمل.

في قواعد البيانات المخصصة، انتبه بشكل خاص إلى طرق العرض المعطَّلة والسجلات المخصصة المتأثرة بـ noupdate.

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

يساعد التقرير على تحديد التغييرات المعروفة، أما الباقي فلا بد أن تكشفه اختباراتك الخاصة بأعمالك.

الخطوة 9: أجرِ تجربة قبل الإنتاج

لا ينبغي أن تكون ترقية الإنتاج أول مرة ينفّذ فيها الفريق التسلسل الكامل.

قبل الإطلاق الفعلي، أجرِ تجربة تشمل:

  • النسخة الاحتياطية النهائية؛
  • فرع الشيفرة أو الوسم (tag)؛
  • تقديم قاعدة البيانات وترقيتها؛
  • تحديث الوحدات المخصصة؛
  • سكربتات الترقية؛
  • التعامل مع مخزن الملفات حيثما ينطبق ذلك؛
  • خطوات الإعداد؛
  • الاختبارات السريعة (smoke tests)؛
  • فحوصات التكامل؛
  • صلاحيات وصول المستخدمين؛
  • التواصل مع أصحاب المصلحة.

سجّل المدة التي تستغرقها كل مرحلة.

لا تَعِد بنافذة توقف لبيئة الإنتاج بناءً على تقدير عام من الإنترنت. قِس زمن تجربتك أنت.

إذا امتد مشروع الترحيل لأسابيع، فاطلب ترقية اختبارية جديدة قبل الإنتاج؛ فقاعدة بيانات الإنتاج وسكربتات الترقية لدى أودو قد تتغيّر كلتاهما خلال مشروع طويل.

الخطوة 10: خطّط لتجميد بيئة الإنتاج

بمجرد أن تبدأ ترقية الإنتاج، فإن التغييرات التي تُجرى على قاعدة بيانات الإنتاج القديمة بعد نقطة النسخ أو التقديم المعنية لن تظهر بطريقة سحرية في قاعدة البيانات المرقّاة.

ضع إجراء تجميد واضحًا.

يجب أن يحدد:

  • متى يتوقف المستخدمون عن إدخال المعاملات؛
  • متى تتوقف التكاملات عن الكتابة؛
  • متى يُعلَّق استقبال الطلبات في التجارة الإلكترونية أو يُعاد توجيهه عند الضرورة؛
  • من يؤكد التجميد؛
  • متى تُؤخذ النسخة الاحتياطية النهائية؛
  • من يطلق عملية الترقية؛
  • من ينشر شيفرة الإصدار المستهدف؛
  • من يجري الاختبارات السريعة التقنية؛
  • من يتولى التحقق من جهة الأعمال؛
  • من يتخذ قرار المضي أو عدم المضي.

تحذّر وثائق أودو من أن قاعدة بيانات الإنتاج لا تكون متاحة أثناء عملية الترقية. وفي Odoo Online، تذكر أيضًا أنه بعد نجاح ترقية الإنتاج لا يمكنك ببساطة إعادة قاعدة البيانات إلى الإصدار السابق.

أما في Odoo.sh، فللمنصة آلية تراجع خاصة بها إذا فشلت عملية الترقية. لكن هذا ليس كالتعامل مع ترقية إصدار رئيسي اكتملت بنجاح على أنها قابلة للتراجع بسهولة.

صمّم خطة الانتقال على هذا الأساس.

الخطوة 11: طبّق بوابة صارمة للإطلاق الفعلي بعد الترقية

فور تشغيل بيئة الإنتاج، تحقّق من أصغر مجموعة من الفحوصات القادرة على كشف أي عطل حرج بسرعة.

الاختبار السريع التقني

  • قاعدة البيانات تعمل دون أخطاء؛
  • إصدار أودو المستهدف صحيح؛
  • الوحدات المتوقعة مثبّتة؛
  • الوحدات المخصصة تُحمَّل؛
  • طرق العرض الحرجة تُفتح؛
  • الإجراءات المجدولة في الحالة المتوقعة؛
  • المستخدمون يستطيعون تسجيل الدخول؛
  • الصلاحيات تعمل بشكل صحيح؛
  • الموقع الإلكتروني والبوابة يستجيبان؛
  • العمليات والمهام الخلفية سليمة.

الاختبار السريع للأعمال

استخدم تدفقات عمل تمثيلية عالية القيمة:

  • إنشاء عملية بيع وتأكيدها؛
  • حجز المخزون أو إتمام حركته؛
  • إنشاء فاتورة؛
  • التحقق من عملية شراء أو استلام؛
  • التحقق من تقرير حرج؛
  • تشغيل سيناريو تصنيع إن كان ذا صلة؛
  • التحقق من سير عمل للرواتب أو الموارد البشرية إن كان ذا صلة.

الاختبار السريع للأنظمة الخارجية

أعد تفعيل اتصالات الإنتاج المضبوطة أو تحقّق منها وفق ترتيب مدروس:

  • البريد الصادر؛
  • مزوّد الدفع؛
  • شركة الشحن؛
  • البنوك والتبادل الإلكتروني للبيانات (EDI) حيثما ينطبق ذلك؛
  • تكاملات الجوال والبوابة؛
  • البرمجيات الوسيطة وخطافات الويب (webhooks)؛
  • ذكاء الأعمال ومزامنة البيانات.

لا تشغّل كل شيء دفعة واحدة ثم تنتظر المستخدمين ليكتشفوا ما الذي فشل.

ما الذي تغطيه خدمة الترقية القياسية من أودو، وما الذي لا تغطيه

هذا التمييز مهم عند وضع ميزانية الترقية إلى أودو 20.

تذكر وثائق ترقية إصدار Enterprise الحالية لدى أودو أن خدمة الترقية تغطي التحويل التقني للتطبيقات والبيانات القياسية، وتشمل بعض سيناريوهات Studio والتخصيص بحسب تغطية الاشتراك أو الصيانة المعمول بها.

كما تسرد بنودًا تقع خارج اتفاقية مستوى الخدمة (SLA) القياسية للترقية، منها:

  • تنظيف البيانات والإعدادات الموجودة مسبقًا؛
  • ترقية الوحدات الإضافية المطوّرة داخليًا أو من أطراف ثالثة غير المشمولة بعقد صيانة؛
  • تدريب المستخدمين على ميزات الإصدار الجديد وسير العمل فيه.

وفي كثير من الشركات التي تعتمد على التخصيص، تكمن في هذه البنود «الخارجة عن النطاق» نسبة كبيرة من الجهد الفعلي للمشروع.

ولهذا فإن عبارة «أودو تُرقّي قاعدة البيانات» وعبارة «شركتنا جاهزة للعمل بأمان على أودو 20» ليستا متكافئتين.

أخطاء شائعة في الترقية إلى أودو 20

1. ترقية بيئة الإنتاج أولًا

قاعدة بيانات الإنتاج ليست بيئة اختبار. اطلب ترقية اختبارية وتحقّق منها.

2. نقل كل تخصيص كما هو

راجع الشيفرة المخصصة بعين ناقدة أولًا، فقد تجعل الوظائف الأصيلة في أودو 20 بعض الوحدات غير ضرورية.

3. اختبار الشاشات بدلًا من العمليات

نجاح فتح نموذج لا يثبت أن تدفق «من الطلب إلى التحصيل» يعمل.

4. تجاهل التحييد

قواعد البيانات الاختبارية تعطّل السلوك الخارجي عمدًا. خطّط لتحقق منفصل من تكاملات الإنتاج.

5. اختبار الوحدات المخصصة وحدها

تدفقات العمل القياسية تتغيّر هي الأخرى. على المستخدمين اختبار عمليات الأعمال بعد الترقية، لا شيفرة المطوّرين فقط.

6. نسيان البيانات التاريخية

الوحدة التي تُثبَّت على قاعدة بيانات أودو 20 فارغة قد تفشل مع ذلك عند ترحيل السجلات القديمة.

7. تجاهل مخزن الملفات

في تدفقات الترقية المحلية التي ينطبق عليها ذلك، يجب تنسيق التعامل مع قاعدة البيانات ومخزن الملفات معًا.

8. تخطّي التجربة

من دون تجربة مسبقة، تبقى تقديرات زمن التوقف وخطوات الانتقال مجرد تخمينات.

9. اعتبار تقرير الترقية بديلًا كاملًا عن اختبار قبول المستخدم

إنه دليل مفيد، لكنه ليس بديلًا عن اختبار الأعمال.

10. دمج مشاريع كثيرة في عملية انتقال واحدة

ترقية الإصدار الرئيسي، ونقل الاستضافة، وتغيير الإصدار (Community/Enterprise)، وتنظيف البيانات، وإعادة تصميم العمليات بالكامل، كلها مخاطر منفصلة. لا تجمع بينها إلا عند وجود سبب مدروس وخطة قابلة للاختبار.

كم تستغرق الترقية إلى أودو 20؟

لا توجد إجابة عامة مسؤولة عن هذا السؤال.

يعتمد الجهد على:

  • الفجوة بين الإصدار الحالي والمستهدف؛
  • عدد الوحدات المخصصة ومدى تعقيدها؛
  • تطبيقات الأطراف الثالثة؛
  • حجم البيانات؛
  • التكاملات؛
  • تعقيد المحاسبة والتوطين المحلي؛
  • عدد الشركات؛
  • الموقع الإلكتروني والتجارة الإلكترونية؛
  • تعقيد التصنيع والمخزون؛
  • العيوب الموجودة أصلًا في بيئة الإنتاج؛
  • مدى توفّر مستخدمي الأعمال لإجراء اختبار قبول المستخدم.

قد لا يكون تحويل قاعدة البيانات بحد ذاته سوى جزء من المدة الكلية للمشروع.

ففي نظام مخصص بكثافة، قد يستحوذ ترحيل الشيفرة المخصصة والتحقق من جهة الأعمال على معظم الجدول الزمني.

وأفضل تقدير يأتي بعد أول ترقية اختبارية وبعد جرد التخصيصات، لا قبلهما.

قائمة التحقق للترقية إلى أودو 20

الاستكشاف

  • تأكيد الإصدار الحالي ونوعه (Community/Enterprise) والاستضافة.
  • التأكد من أن أودو 20 متاح حاليًا كهدف ترقية لمسار قاعدة البيانات المحدد.
  • جرد الوحدات القياسية وتخصيصات Studio ووحدات الأطراف الثالثة والوحدات المخصصة.
  • جرد التكاملات والأتمتة.
  • تحديد تدفقات العمل الحرجة للأعمال.
  • تعيين المسؤولين التقنيين والمسؤولين من جهة الأعمال.

التطوير

  • تجميد التطوير غير الضروري على الإصدار القديم.
  • مراجعة التخصيصات المتقادمة أو إزالتها.
  • تجهيز فرع الشيفرة للإصدار المستهدف.
  • جعل الوحدات المخصصة قابلة للتثبيت على أودو 20 نظيف.
  • تجهيز سكربتات الترقية المطلوبة.
  • التحقق من الوحدات مع بيانات العميل المرقّاة.

الاختبار

  • مراجعة تقرير الترقية.
  • فحص طرق العرض المعطَّلة والمخصصة.
  • إجراء اختبار قبول المستخدم بحسب الأدوار.
  • اختبار تدفقات العمل العابرة للتطبيقات.
  • مقارنة سجلات مرحَّلة تمثيلية.
  • تسوية البيانات المالية وبيانات المخزون.
  • اختبار التقارير والتصديرات والترجمات والقوالب.
  • اختبار التكاملات في بيئات آمنة.
  • تسجيل القيود المعروفة الناتجة عن التحييد.

الانتقال

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

الأسئلة الشائعة

هل يمكنني الترقية مباشرة إلى أودو 20؟

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

هل أحتاج إلى ترقية الوحدات المخصصة بشكل منفصل؟

نعم، إذا كان نظامك يحتوي على وحدات Python مخصصة. فترقية قاعدة البيانات من أودو وترحيل شيفرتك المصدرية المخصصة جزءان مترابطان لكنهما منفصلان من المشروع. وتنص أودو على أن الشيفرة المصدرية للوحدات المخصصة يجب أن تكون متوافقة مع الإصدار المستهدف لكي تنجح الترقية الكاملة.

هل يمكنني اختبار ترقية أودو دون التأثير في بيئة الإنتاج؟

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

هل يمكنني طلب أكثر من ترقية اختبارية؟

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

هل ترقية أودو هي نفسها تغيير الاستضافة؟

لا. تتعامل أودو صراحةً مع تغيير نوع الاستضافة على أنه أمر منفصل عن ترقية قاعدة البيانات.

هل ترقية أودو هي نفسها الانتقال من Community إلى Enterprise؟

لا. التبديل بين الإصدارين ليس جزءًا من التعريف القياسي لترقية قاعدة البيانات.

هل ستُرقّي أودو الوحدات المخصصة التي طوّرتها أطراف ثالثة؟

لا تفترض ذلك. فاتفاقية مستوى الخدمة القياسية للترقية لدى أودو لا تشمل الوحدات الإضافية المطوّرة داخليًا أو من أطراف ثالثة ما لم تكن مشمولة بتغطية صيانة التخصيصات المعمول بها. حدّد المسؤولية قبل بدء المشروع.

هل يمكننا التراجع بعد ترقية بيئة الإنتاج؟

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

الخلاصة

الترقية الآمنة إلى أودو 20 تتضمن ثلاث عمليات ترحيل تجري معًا:

قاعدة البيانات، والشيفرة المخصصة، وتشغيل الأعمال.

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

لذلك تتبع أفضل مشاريع الترقية قاعدة واحدة:

لا تجعل بيئة الإنتاج المكان الذي تكتشف فيه ما إذا كانت خطة الترحيل لديك تنجح.

اختبرها. أصلحها. كرّرها. أجرِ تجربة لها. ثم انتقل إلى الإنتاج.


هل تخطط لمشروع على أودو 20؟ تساعد Octivex Tech الشركات في ترقيات أودو، وترحيل الوحدات المخصصة، والتكاملات، وسير العمل المدعوم بالذكاء الاصطناعي. تصفّح خدماتنا في أودو أو تواصل مع فريقنا الهندسي لمناقشة بيئتك.