كيفية نشر وحدات المجتمع على أودو.sh (أودو 16–19)
مرجع شامل للمطوّر لنشر الوحدات المخصصة ووحدات مجتمع OCA على أودو.sh: إعداد مستودع GitHub وسير العمل بالفروع والوحدات الفرعية ومتطلبات.txt وسجلات البناء والترقية من التدريج إلى الإنتاج. موثق لأودو 18 و19.
أودو.sh هي منصة الاستضافة السحابية الرسمية لأودو، مبنية حول نموذج نشر قائم على الفروع ومدمج مع GitHub. كل دفع إلى مستودع GitHub المتصل يُطلق بناءً تلقائيًا على فرع أودو.sh المقابل — دون الحاجة إلى توفير خادم يدوي. يتبع نشر الوحدات المجتمعية أو المخصصة على أودو.sh سير عمل متوقع: أضف كود الوحدة إلى مستودعك، دع أودو.sh يبنيه على فرع تطوير أو تدريج، تحقق منه، ثم رقّه إلى الإنتاج بدمج الفرع. يغطي هذا الدليل كل خطوة في سير العمل ذلك.
نموذج الفروع الثلاثة في أودو.sh
| نوع الفرع | الغرض | قاعدة البيانات | إعادة بناء تلقائية عند الدفع؟ | إرسال البريد الإلكتروني |
|---|---|---|---|---|
| الإنتاج | البيئة الحية الموجهة للعملاء. فرع إنتاج واحد فقط لكل مشروع. | بيانات حية — سجلات عملاء حقيقية | نعم (عند الدمج/الدفع). يُحدّث أودو.sh النسخة الجارية في مكانها. | مفعّل — يستخدم خوادم بريد حقيقية |
| التدريج | اختبار ما قبل الإنتاج. قاعدة البيانات نسخة حديثة من الإنتاج — نفس البيانات، بدون حركة مرور حية. | نسخة من الإنتاج (معادلة تلقائيًا) | نعم — يُعيد البناء عند كل دفع | معطّل افتراضيًا — يتم اعتراض الرسائل الإلكترونية وعدم إرسالها للمستلمين الحقيقيين |
| التطوير | تطوير الميزات واختبارها ببيانات تجريبية أو قاعدة بيانات جديدة. يُسمح بفروع تطوير متعددة. | بيانات تجريبية أو تثبيت يدوي — لا بيانات إنتاج | نعم — يُعيد البناء عند كل دفع | معطّل افتراضيًا |
هيكل المستودع لأودو.sh
يفحص أودو.sh جذر المستودع بحثًا عن مجلدات تبدو كوحدات أودو (تحتوي على ملف `__manifest__.py`) ويضيفها تلقائيًا إلى مسار الوحدة. يمكن وضع الوحدات المخصصة مباشرةً في جذر المستودع أو في مجلد فرعي. الهيكل الموصى به لمشروع يحتوي على وحدات مخصصة وتبعيات OCA:
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
# 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 تهيئة الوحدة الفرعية تلقائيًا خلال كل بناء.
# 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` خلال كل بناء قبل تشغيل خادم أودو.
# 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.سير عمل ترقية الفروع — التطوير → التدريج → الإنتاج
# 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مراقبة سجلات البناء وتشخيص الأعطال
| نمط الخطأ في السجلات | السبب | الحل |
|---|---|---|
| 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 |
|---|---|
| أودو 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؟
كيف أضيف وحدة OCA إلى مشروع أودو.sh؟
ما الفرق بين فروع التدريج والتطوير في أودو.sh؟
هل يُثبّت أودو.sh تبعيات requirements.txt تلقائيًا؟
كيف أُرقّي تغيير وحدة من التدريج إلى الإنتاج على أودو.sh؟
هل يمكنني استخدام أودو.sh لوحدات Odoo Community Edition (CE)؟

iWesabe Editorial Team
رؤى عملية حول Odoo ERP وامتثال ZATCA والعمليات الرقمية للشركات السعودية — بقلم فرق الاستشارات والمالية والهندسة في iWesabe.
مقالات ذات صلة
إدارة قواعد بيانات أودو — الدليل الشامل لمدير قواعد البيانات (أودو 16–19)
مرجع شامل لمدير قواعد البيانات المدمج في أودو: الإنشاء والنسخ والنسخ الاحتياطي والاستعادة والحذف — بالإضافة إلى تقوية الأمان لبيئات الإنتاج. موثق لأودو 18 و19.
أمان الوصول في أودو — ir.model.access.csv وقواعد السجلات (أودو 16–19)
مرجع شامل للمطوّر حول نظام الأمان ثنائي الطبقة في أودو: صلاحيات CRUD على مستوى النموذج عبر ir.model.access.csv والتصفية على مستوى السجل عبر ir.rule. موثق لأودو 18 و19.
كيفية إنشاء مقطع مخصص في موقع أودو
دليل خطوة بخطوة لبناء مكوّنات قابلة للسحب والإفلات في محرر موقع أودو — من قالب XML إلى لوحة المقاطع المباشرة. موثق لأودو 18 و19.