تطوير أودو

كيفية نشر وحدات المجتمع على أودو.sh (أودو 16–19)

مرجع شامل للمطوّر لنشر الوحدات المخصصة ووحدات مجتمع OCA على أودو.sh: إعداد مستودع GitHub وسير العمل بالفروع والوحدات الفرعية ومتطلبات.txt وسجلات البناء والترقية من التدريج إلى الإنتاج. موثق لأودو 18 و19.

iWesabe Editorial Team١ فبراير ٢٠٢٢8 دقائق للقراءة

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

نموذج الفروع الثلاثة في أودو.sh

أنواع فروع أودو.sh وأغراضها
نوع الفرعالغرضقاعدة البياناتإعادة بناء تلقائية عند الدفع؟إرسال البريد الإلكتروني
الإنتاجالبيئة الحية الموجهة للعملاء. فرع إنتاج واحد فقط لكل مشروع.بيانات حية — سجلات عملاء حقيقيةنعم (عند الدمج/الدفع). يُحدّث أودو.sh النسخة الجارية في مكانها.مفعّل — يستخدم خوادم بريد حقيقية
التدريجاختبار ما قبل الإنتاج. قاعدة البيانات نسخة حديثة من الإنتاج — نفس البيانات، بدون حركة مرور حية.نسخة من الإنتاج (معادلة تلقائيًا)نعم — يُعيد البناء عند كل دفعمعطّل افتراضيًا — يتم اعتراض الرسائل الإلكترونية وعدم إرسالها للمستلمين الحقيقيين
التطويرتطوير الميزات واختبارها ببيانات تجريبية أو قاعدة بيانات جديدة. يُسمح بفروع تطوير متعددة.بيانات تجريبية أو تثبيت يدوي — لا بيانات إنتاجنعم — يُعيد البناء عند كل دفعمعطّل افتراضيًا

هيكل المستودع لأودو.sh

يفحص أودو.sh جذر المستودع بحثًا عن مجلدات تبدو كوحدات أودو (تحتوي على ملف `__manifest__.py`) ويضيفها تلقائيًا إلى مسار الوحدة. يمكن وضع الوحدات المخصصة مباشرةً في جذر المستودع أو في مجلد فرعي. الهيكل الموصى به لمشروع يحتوي على وحدات مخصصة وتبعيات OCA:

text
my-odoo-project/              ← GitHub repository root
├── my_custom_module/             ← custom module (detected automatically)
│   ├── __manifest__.py
│   ├── __init__.py
│   ├── models/
│   └── views/
├── my_other_module/              ← another custom module
│   └── __manifest__.py
├── OCA/                          ← OCA community modules (as git submodules)
│   ├── account-invoicing/        ← OCA repository submodule
│   │   └── account_invoice_xyz/  ← specific OCA module
│   └── partner-contact/
├── requirements.txt              ← Python package dependencies
└── .gitmodules                   ← git submodule registry (auto-managed)

ربط مستودع GitHub الخاص بك بأودو.sh

bash
# Step-by-step: first-time setup for a new Odoo.sh project

# 1. Create a GitHub repository for your project
#    (either a new repo or fork an existing one)

# 2. Clone locally and add your custom module
git clone https://github.com/your-org/your-odoo-project.git
cd your-odoo-project

# 3. Add your custom module directory
mkdir my_custom_module
# ... add __manifest__.py, __init__.py, models/, views/ etc.

# 4. Commit and push to the branch Odoo.sh is watching
git add .
git commit -m "feat: add my_custom_module"
git push origin main   # or 'master' depending on your default branch

# 5. In the Odoo.sh dashboard:
#    - Go to your project → Branches tab
#    - Your 'main' branch now appears as a Development branch
#    - Odoo.sh automatically starts a build
#    - Watch the build log in the Logs tab

إضافة وحدات مجتمع OCA عبر الوحدات الفرعية Git

وحدات OCA (جمعية مجتمع أودو) تُدار كمستودعات GitHub منفصلة. الطريقة الصحيحة لتضمينها في مشروع أودو.sh هي كوحدات فرعية git — هذا يُثبّت وحدة OCA على commit محدد، يُبقي حجم مستودعك صغيرًا، ويتيح لأودو.sh تهيئة الوحدة الفرعية تلقائيًا خلال كل بناء.

bash
# Adding an OCA module as a git submodule

# Example: add the OCA 'account-invoicing' repository
# (contains multiple modules — Odoo.sh will scan it and find them all)
git submodule add -b 17.0 https://github.com/OCA/account-invoicing.git OCA/account-invoicing

# This creates:
#  - OCA/account-invoicing/ directory (the submodule contents)
#  - .gitmodules file entry registering the submodule

# Commit both the submodule reference and .gitmodules
git add .gitmodules OCA/account-invoicing
git commit -m "feat: add OCA account-invoicing submodule (17.0)"
git push origin main

# Odoo.sh will automatically run 'git submodule update --init' during each build.
# You do NOT need to run any extra commands on the server.

# To update the submodule to the latest commit on its branch later:
git submodule update --remote OCA/account-invoicing
git add OCA/account-invoicing
git commit -m "chore: update OCA account-invoicing to latest 17.0"
git push origin main

تبعيات Python — requirements.txt

إذا كانت وحداتك المخصصة أو وحدات OCA تعتمد على حزم Python غير مضمّنة في تثبيت أودو الأساسي، أضف ملف `requirements.txt` إلى جذر المستودع. يُشغّل أودو.sh تلقائيًا `pip install -r requirements.txt` خلال كل بناء قبل تشغيل خادم أودو.

text
# requirements.txt — place in the repository root

# Pin versions for reproducible builds
zeep==4.2.1          # SOAP client (e.g. for ZATCA integration)
cryptography==41.0.3  # for custom encryption utilities
pandas==2.1.0         # for data export/import modules
openpyxl==3.1.2       # Excel export

# OCA modules sometimes list their own requirements.txt files
# inside the module directory — Odoo.sh scans for and installs those too.
# Your repo root requirements.txt is additive.

سير عمل ترقية الفروع — التطوير → التدريج → الإنتاج

bash
# Safe deployment workflow for a new module

# 1. Develop on a feature branch (development branch in Odoo.sh)
git checkout -b feature/my-new-module
# ... develop, commit, push
git push origin feature/my-new-module
# Odoo.sh auto-builds on 'feature/my-new-module' as a development branch

# 2. Test on development branch
#    - Open Odoo.sh dashboard → feature/my-new-module → Connect (SSH or browser)
#    - Install the module: Apps → search for your module → Install
#    - Verify functionality with demo/test data

# 3. Merge to staging branch for pre-production testing
#    Option A: via GitHub pull request to 'staging' branch
#    Option B: via Odoo.sh dashboard → Staging tab → Merge branch
git checkout staging
git merge feature/my-new-module
git push origin staging
# Odoo.sh rebuilds staging with a copy of the production database
# The new module is NOT auto-installed — you must install it manually
# on the staging database to test the upgrade path

# 4. Verify on staging
#    - Module installs correctly on a production-data copy
#    - No data migration errors
#    - Emails are intercepted — safe to test workflows

# 5. Merge to production
git checkout main   # your production branch
git merge staging
git push origin main
# Odoo.sh applies the update in-place: runs module upgrade, restarts

مراقبة سجلات البناء وتشخيص الأعطال

أنماط فشل البناء الشائعة في أودو.sh وحلولها
نمط الخطأ في السجلاتالسببالحل
ModuleNotFoundError: لا توجد وحدة باسم 'xyz'حزمة Python مطلوبة من وحدة مفقودة من requirements.txtأضف الحزمة المفقودة إلى requirements.txt في جذر المستودع. أتمّ الـcommit وادفع — سيُثبّتها البناء التالي بواسطة pip.
Cannot find module 'my_module' in addons pathsدليل الوحدة يفتقر إلى __manifest__.py (لذا لا يتعرف عليه أودو.sh كوحدة)أضف __manifest__.py إلى جذر دليل الوحدة. بدونه، لا يُضاف الدليل إلى مسار الإضافات.
دليل الوحدة الفرعية فارغ / وحدة OCA غير موجودةتمت إضافة الوحدة الفرعية لكن .gitmodules لم يُتمّ commit، أو لم تتم تهيئة الوحدة الفرعيةشغّل 'git submodule update --init' محليًا، أتمّ commit لـ .gitmodules مع مرجع الوحدة الفرعية، وادفع مجددًا.
odoo.exceptions.ValidationError أو MissingError أثناء البناءملف بيانات (XML/CSV) في الوحدة يستند إلى سجل غير موجود في قاعدة البيانات المستهدفةاختبر تثبيت الوحدة على قاعدة بيانات جديدة أولًا. على التدريج (مع بيانات الإنتاج)، قد يكون السجل موجودًا في التطوير لكن ليس في الإنتاج. استخدم noupdate='1' بعناية واختبر ترحيل البيانات.

ملاحظات الإصدار

تغييرات نشر أودو.sh حسب إصدار أودو
إصدار أودوالتغييرات الرئيسية المؤثرة على نشر وحدات أودو.sh
أودو 15 و16لا توجد تغييرات كاسرة على نموذج فروع أودو.sh أو معالجة الوحدات الفرعية. تتبع فروع وحدات OCA اتفاقية التسمية 15.0/16.0. التثبيت التلقائي لـ requirements.txt لم يتغير.
أودو 17تم إعادة تصميم واجهة لوحة تحكم أودو.sh — انتقلت إدارة الفروع إلى علامة تبويب الفروع الجديدة. الوظائف لم تتغير. تستخدم فروع OCA تسمية 17.0. يجب أن يتطابق حقل 'version' في __manifest__.py للوحدة مع الإصدار الرئيسي لأودو (مثلًا '17.0.1.0.0').
أودو 18لا توجد تغييرات كاسرة على سير عمل نشر أودو.sh. معالجة الوحدات الفرعية ومتطلبات.txt لم تتغير. فروع أودو 18 في OCA مسمّاة 18.0.
أودو 19لا توجد تغييرات كاسرة على أودو.sh. تدعم المنصة تلقائيًا بنيات أودو 19. فروع OCA 19.0 متاحة للمستودعات المدعومة. سير عمل النشر متطابق.

تحتاج مساعدة في إعداد أودو.sh أو نشر وحدات مخصصة؟

يتولى فريق أودو المعتمد لدينا إعداد مشاريع أودو.sh الكاملة وهيكلة مستودعات GitHub وتكامل وحدات OCA وأنابيب النشر الآمن للإنتاج — بما في ذلك وحدات اللغة العربية من اليمين لليسار وتكاملات ZATCA وتهيئات متعددة الشركات للشركات السعودية.

واتساب

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

كيف أنشر وحدة مخصصة على أودو.sh؟
أضف مجلد وحدتك (الذي يحتوي على `__manifest__.py`) إلى مستودع GitHub المتصل بمشروع أودو.sh الخاص بك. أتمّ commit وادفع — يكتشف أودو.sh الوحدة تلقائيًا ويُعيد بناء الفرع ويضيفها إلى قائمة التطبيقات. لتثبيتها، انتقل إلى التطبيقات في أودو، ابحث عن اسم وحدتك، وانقر على تثبيت. الوحدة لا تُثبَّت تلقائيًا عند الدفع؛ يجب تثبيتها يدويًا في المرة الأولى.
كيف أضيف وحدة OCA إلى مشروع أودو.sh؟
استخدم الوحدات الفرعية git. شغّل `git submodule add -b .0 https://github.com/OCA/.git OCA/` من جذر مستودعك، ثم أتمّ commit لكلٍّ من ملف `.gitmodules` ومرجع دليل الوحدة الفرعية الجديد وادفع. يُهيّئ أودو.sh الوحدات الفرعية تلقائيًا خلال كل بناء — لا تحتاج إلى فعل أي شيء على الخادم. استخدم دائمًا الفرع المطابق لإصدار أودو الخاص بك (مثلًا `-b 17.0` لأودو 17).
ما الفرق بين فروع التدريج والتطوير في أودو.sh؟
يتلقى فرع التدريج تلقائيًا نسخة من قاعدة بيانات الإنتاج — نفس البيانات، معادلة (البريد الإلكتروني معطّل والإجراءات المجدولة موقوفة). استخدم التدريج لاختبار ترقيات الوحدة على البيانات الحقيقية قبل النشر المباشر. يستخدم فرع التطوير بيانات تجريبية أو قاعدة بيانات جديدة — لا بيانات إنتاج. استخدم فروع التطوير لتطوير الميزات واختبار الوحدة الأولي والتجريب. يمكنك امتلاك فروع تطوير متعددة لكن فرع تدريج واحد وفرع إنتاج واحد فقط لكل مشروع أودو.sh.
هل يُثبّت أودو.sh تبعيات requirements.txt تلقائيًا؟
نعم. ضع ملف `requirements.txt` في جذر المستودع. يُشغّل أودو.sh `pip install -r requirements.txt` خلال كل بناء قبل تشغيل خادم أودو. يفحص أيضًا جميع الوحدات الفرعية git بحثًا عن ملفات `requirements.txt` ويُثبّتها. ثبّت إصدارات الحزم الخاصة بك (مثلًا `zeep==4.2.1`) لتجنب كسر البنيات عندما تُصدر الحزم المصدرية تغييرات كاسرة.
كيف أُرقّي تغيير وحدة من التدريج إلى الإنتاج على أودو.sh؟
ادمج فرع التدريج في فرع الإنتاج عبر GitHub (طلب سحب أو دمج مباشر) وادفع. يكتشف أودو.sh الدفع إلى فرع الإنتاج ويُطلق بناءً ويطبق تغييرات الوحدة في مكانها — مُشغّلًا `odoo -u ` تلقائيًا لأي وحدات تغيّرت. يُعاد تشغيل الخادم كجزء من التحديث. راقب سجلات البناء والخادم في لوحة تحكم أودو.sh لأي أخطاء خلال تحديث الإنتاج.
هل يمكنني استخدام أودو.sh لوحدات Odoo Community Edition (CE)؟
صُمّم أودو.sh لـ Odoo Enterprise — يتطلب اشتراكًا نشطًا في Odoo Enterprise. يمكن نشر وحدات Community Edition (الوحدات التي تعتمد فقط على `base` ووحدات CE الأخرى) على أودو.sh لأن أودو.sh يُشغّل Enterprise، الذي يتضمن جميع وحدات CE. ومع ذلك، لا يمكنك تشغيل نسخة CE خالصة على أودو.sh. لنشر CE الخالص، استخدم خادمًا ذاتي الإدارة (VPS أو محلي) بدلًا من ذلك.
iWesabe Editorial Team

iWesabe Editorial Team

رؤى عملية حول Odoo ERP وامتثال ZATCA والعمليات الرقمية للشركات السعودية — بقلم فرق الاستشارات والمالية والهندسة في iWesabe.

عن iWesabe

مقالات ذات صلة