شعب

نمای شعب نمای کلی از شاخه‌های مختلف مخزن شما ارائه می‌دهد.

مراحل

Odoo.sh سه مرحلهٔ شاخهٔ متفاوت ارائه می‌دهد:

• Production

• Staging

• Development

می‌توانید با drag-and-drop یک شاخه زیر مرحلهٔ موردنظر، مرحلهٔ آن را تغییر دهید.

توجه

• شاخه‌های توسعه را می‌توان به زیر Staging منتقل کرد. اگر سعی کنید یک شاخهٔ توسعه را به زیر تولید منتقل کنید، یک پیام هشدار نمایش داده می‌شود که توضیح می‌دهد فقط می‌توانید یک شاخهٔ تولید برای هر پروژه داشته باشید.

• شاخه‌های staging را می‌توان به زیر Development منتقل کرد، اما انتقال آن‌ها به زیر تولید ممکن نیست.

• شاخهٔ تولید را فقط می‌توان به زیر Development منتقل کرد. اگر سعی کنید آن را به زیر Staging منتقل کنید، فقط می‌توانید یک merge انجام دهید. برای توضیح دقیق این فرایند به بخش merging مراجعه کنید.

تولید

شاخهٔ تولید حاوی کدی است که برای اجرای پایگاه دادهٔ تولیدی استفاده می‌شود. تنها یک شاخهٔ تولید می‌تواند وجود داشته باشد.

هنگامی که یک commit جدید به این شاخه push می‌کنید، سرور تولید با کد بازنگری‌شده به‌روزرسانی و راه‌اندازی مجدد می‌شود.

اگر تغییرات نیازمند به‌روزرسانی یک ماژول هستند، مانند تغییر یک نمای فرم، و می‌خواهید به‌روزرسانی به‌صورت خودکار انجام شود، می‌توانید شمارهٔ نسخهٔ ماژول را در فایل manifest آن (__manifest__.py) افزایش دهید. پلتفرم سپس به‌روزرسانی را انجام می‌دهد، در طول آن نمونه به دلایل نگهداری به‌صورت موقت غیرقابل دسترس نگه داشته می‌شود.

این روش معادل ارتقای ماژول با استفاده از منوی برنامه‌ها یا switch -u در خط فرمان است.

توجه

• اگر تغییرات مانع از راه‌اندازی مجدد سرور شوند یا اگر به‌روزرسانی ماژول ناموفق باشد، سرور به‌صورت خودکار به revision کد موفق قبلی برگردانده می‌شود و پایگاه داده به وضعیت قبلی rollback می‌شود. برای عیب‌یابی به لاگ به‌روزرسانی ناموفق دسترسی پیدا کنید.

• داده‌های دمو بارگذاری نمی‌شوند، زیرا برای استفاده در یک پایگاه دادهٔ تولیدی در نظر گرفته نشده‌اند. unit tests انجام نمی‌شوند، زیرا زمان عدم دسترسی پایگاه دادهٔ تولیدی در طول به‌روزرسانی را افزایش می‌دهد.

Odoo.sh به‌صورت خودکار از پایگاه دادهٔ تولیدی پشتیبان می‌گیرد. هفت پشتیبان روزانه، چهار هفتگی و سه ماهانه را نگه می‌دارد. هر پشتیبان شامل dump پایگاه داده، filestore (پیوست‌ها و فیلدهای binary)، لاگ‌ها و sessionها است.

هشدار

هنگام استفاده از پروژه‌های آزمایشی، شاخهٔ تولید و تمام شاخه‌های staging پس از ۳۰ روز به‌صورت خودکار به مرحلهٔ توسعه بازگردانده می‌شوند.

مرحله‌بندی

شاخه‌های staging برای آزمایش ویژگی‌های جدید با استفاده از داده‌های تولیدی، بدون به خطر انداختن پایگاه دادهٔ تولیدی واقعی با رکوردهای آزمایشی در نظر گرفته شده‌اند. آن‌ها کپی‌های خنثی‌شده‌ای از پایگاه دادهٔ تولیدی ایجاد می‌کنند.

خنثی‌سازی موارد زیر را غیرفعال می‌کند:

• اقدامات برنامه‌ریزی‌شده

  توجه

  برای آزمایش آن‌ها، آن‌ها را به‌صورت دستی trigger کنید یا دوباره فعال کنید. توجه داشته باشید که پلتفرم در صورت عدم استفادهٔ کسی از پایگاه داده، برای صرفه‌جویی در منابع آن‌ها را کمتر trigger می‌کند.

• ایمیل‌های خروجی

  توجه

  آن‌ها در عوض توسط یک mail catcher رهگیری می‌شوند. یک رابط برای مشاهدهٔ ایمیل‌های ارسال‌شده توسط پایگاه داده در پروژهٔ Odoo.sh شما فراهم شده است. به این ترتیب هیچ ایمیلی به مخاطبین شما ارسال نمی‌شود.

• خدمات IAP

• ارائه‌دهندگان پرداخت و کانکتورهای حمل و نقل

  توجه

  آن‌ها در حالت آزمایش قرار می‌گیرند.

اگر در یک پایگاه دادهٔ staging تغییرات پیکربندی را تنظیم یا مشاهده می‌کنید، حتماً آن‌ها را ثبت کنید (گام‌به‌گام یادداشت کنید، در تولید بازتولید کنید و غیره) یا آن‌ها را مستقیماً در ماژول‌های شاخه با استفاده از فایل‌های داده XML برای override پیکربندی یا نماهای پیش‌فرض بنویسید. برای مشاهدهٔ نمونه‌ها مستندات ماژول اول را ببینید.

توجه

Unit testها انجام نمی‌شوند. آن‌ها به داده‌های دمو متکی هستند که در پایگاه‌های دادهٔ تولید و staging بارگذاری نمی‌شوند. اگر Odoo از اجرای unitها بدون داده‌های دمو پشتیبانی کند، Odoo.sh سپس اجرای آزمون‌ها روی پایگاه‌های دادهٔ staging را در نظر خواهد گرفت.

از پایگاه‌های دادهٔ staging به‌صورت خودکار پشتیبان‌گیری نمی‌شود. با این حال، می‌توانید یک پشتیبان از پایگاه دادهٔ تولیدی را در یک شاخهٔ staging برای اهداف آزمایشی یا برای بازیابی دستی داده‌هایی که به‌اشتباه از پایگاه دادهٔ تولیدی حذف شده‌اند بازیابی کنید. ایجاد پشتیبان‌های دستی از پایگاه‌های دادهٔ staging امکان‌پذیر است.

هشدار

پایگاه‌های داده ایجادشده برای شاخه‌های staging به‌صورت خودکار پس از یک ماه حذف می‌شوند. برای استفادهٔ مجدد از شاخه، باید آن را rebuild کنید.

توسعه

شاخه‌های توسعه پایگاه‌های داده جدیدی با استفاده از داده‌های دمو برای اجرای unit testها ایجاد می‌کنند. ماژول‌های نصب‌شده آن‌هایی هستند که در شاخه گنجانده شده‌اند. می‌توانید این فهرست ماژول‌ها را برای نصب در تنظیمات پروژه تغییر دهید.

هنگام push کردن یک commit به یک شاخهٔ توسعه، یک سرور جدید با پایگاه دادهٔ ایجادشده از صفر راه‌اندازی می‌شود و شاخه به‌روزرسانی می‌شود. داده‌های دمو بارگذاری می‌شوند و unit testها به‌صورت پیش‌فرض برای تأیید اینکه تغییرات هیچ یک از ویژگی‌های در حال آزمایش را خراب نمی‌کنند انجام می‌شوند. می‌توانید با رفتن به تنظیمات شاخه آزمون‌ها را غیرفعال کنید یا اجازه دهید آزمون‌های خاصی با برچسب‌های سفارشی اجرا شوند.

مشابه شاخه‌های staging، ایمیل‌ها ارسال نمی‌شوند بلکه توسط یک mail catcher رهگیری می‌شوند، و تا زمانی که پایگاه داده استفاده نشود، اقدامات برنامه‌ریزی‌شده trigger نمی‌شوند.

از پایگاه‌های دادهٔ توسعه به‌صورت خودکار پشتیبان‌گیری نمی‌شود و پشتیبان‌گیری دستی نیز امکان‌پذیر نیست.

هشدار

پایگاه‌های دادهٔ ایجادشده برای شاخه‌های توسعه قرار است تقریباً سه روز دوام بیاورند. پس از آن، می‌توانند به‌صورت خودکار garbage-collect شوند تا برای پایگاه‌های دادهٔ جدید جا باز شود، بدون اطلاع قبلی.

Merge کردن شاخه‌ها

می‌توانید با drag-and-drop شاخه‌ها روی یکدیگر، آن‌ها را merge کنید.

برای آزمایش تغییرات شاخه‌های توسعه با داده‌های تولیدی، می‌توانید یکی از این کارها را انجام دهید:

• شاخهٔ توسعه را با drag-and-drop روی شاخهٔ موردنظر، در یک شاخهٔ staging merge کنید؛ یا

  

• شاخهٔ توسعه را با drag-and-drop زیر بخش Staging بیندازید تا به یک شاخهٔ staging تبدیل شود.

  

هنگامی که تغییرات برای تولید آماده هستند، شاخهٔ staging را با drag-and-drop در شاخهٔ تولید بیندازید تا آن‌ها merge و مستقر شوند.

توجه

• می‌توانید شاخه‌های توسعه را مستقیماً در شاخهٔ تولید merge کنید. با این حال، تغییرات از طریق یک شاخهٔ staging در برابر داده‌های تولید اعتبارسنجی نخواهند شد، بنابراین ریسک بیشتری برای مواجهه با مشکلات در پایگاه دادهٔ تولید وجود دارد.

• می‌توانید شاخه‌های توسعه را در یکدیگر و شاخه‌های staging را در یکدیگر merge کنید.

• همچنین می‌توانید مستقیماً روی workstation خود از git merge برای merge کردن شاخه‌های خود استفاده کنید. هنگامی که revisionهای جدید به شاخه‌های شما push می‌شوند، Odoo.sh مطلع می‌شود.

merge کردن یک شاخهٔ staging در شاخهٔ تولید فقط کد منبع را merge می‌کند. هر تغییری که در پایگاه دادهٔ staging انجام شود به پایگاه دادهٔ تولید منتقل نمی‌شود. با این حال، اگر کد را در مخزن اصلاح کنید، هنگام merge به شاخهٔ تولید منتقل می‌شود.

اگر تغییرات پیکربندی را در شاخه‌های staging آزمایش می‌کنید و می‌خواهید آن‌ها روی شاخهٔ تولید اعمال شوند، باید یکی از این کارها را انجام دهید:

• تغییرات پیکربندی را در فایل‌های داده XML بنویسید تا پیکربندی یا نماهای پیش‌فرض در شاخه را override کند، و سپس نسخهٔ ماژول را در manifest آن (__manifest__.py) افزایش دهید تا به‌روزرسانی ماژول هنگام merge کردن شاخهٔ staging در شاخهٔ تولید trigger شود.

  توجه

  این روش برای مقیاس‌پذیری بهتر توسعه‌های شما توصیه می‌شود، زیرا از ویژگی‌های versioning Git برای تمام تغییرات پیکربندی استفاده خواهید کرد، بنابراین قابلیت ردیابی تغییرات خود را تضمین می‌کنید.

• آن‌ها را به‌صورت دستی با copy و paste از پایگاه دادهٔ staging به پایگاه دادهٔ تولیدی منتقل کنید.

تب‌ها

تاریخچه

تب تاریخچه نمای کلی از تاریخچهٔ شاخه ارائه می‌دهد:

• پیام‌های commit و نویسندگان آن‌ها

• رویدادهای مختلف مرتبط با پلتفرم، مانند تغییر مرحله، وارد کردن پایگاه داده و بازیابی پشتیبان

یک وضعیت در گوشهٔ بالا سمت راست هر رویداد، عملیات فعلی روی پایگاه داده (مثلاً نصب، به‌روزرسانی، وارد کردن پشتیبان) یا نتیجهٔ آن (مثلاً بازخورد آزمون، وارد کردن موفق پشتیبان) را نشان می‌دهد. اگر یک عملیات موفق باشد، دکمهٔ اتصال ظاهر می‌شود که به شما اجازهٔ دسترسی به پایگاه داده را می‌دهد.

ایمیل‌ها

تب ایمیل‌ها شامل mail catcher است که نمای کلی از ایمیل‌های ارسال‌شده توسط پایگاه داده را ارائه می‌دهد.

توجه

mail catcher برای شاخه‌های توسعه و staging در دسترس است. ایمیل‌های پایگاه دادهٔ تولید واقعاً ارسال می‌شوند و توسط mail catcher رهگیری نمی‌شوند.

پوسته (Shell)

تب Shell دسترسی شل به کانتینر را فراهم می‌کند.

کلیک روی Shell یک تب جدید مرورگر را باز می‌کند که می‌توانید در آن دستورات پایهٔ Linux (ls, top) را اجرا کنید. می‌توانید با اجرای psql یک shell روی پایگاه داده باز کنید.

نکته

می‌توانید چندین تب شل را به‌طور هم‌زمان باز کنید و با drag-and-drop چیدمان آن‌ها را تنظیم کنید.

توجه

• shellهای نمونهٔ تولید با رنگ قرمز برجسته می‌شوند تا خطر دستکاری مستقیم نمونه‌های تولید را برجسته کنند، در حالی که shellهای نمونهٔ staging/توسعه با رنگ زرد برجسته می‌شوند.

• نمونه‌های شل با اجرای طولانی/نشست‌های بیکار شل را می‌توان در هر زمان برای آزادسازی منابع خاتمه داد.

دستورات

در ادامه نمای کلی از دستورات مفیدی که می‌توانید در یک ترمینال پایگاه دادهٔ Odoo.sh اجرا کنید آمده است:

• odoo-bin shell: برای باز کردن یک شل Odoo

• odoo-update: برای به‌روزرسانی ماژول‌ها در پایگاه داده

• odoosh-restart: برای راه‌اندازی مجدد سرویس‌های Odoo.sh (http یا cron)

• odoosh-storage: برای بررسی میزان استفاده از فضای ذخیره‌سازی فایل‌سیستم کانتینر نمونهٔ شما

• psql: برای باز کردن یک شل پایگاه داده

• mutt: برای بررسی نحوهٔ نمایش ایمیل‌ها در کلاینت‌های متنی (نمونه‌های staging و توسعه)

• lnav ~/logs/odoo.log: برای پیمایش در فایل odoo.log نمونهٔ شما

• ncdu: برای راه‌اندازی تحلیل‌گر مصرف دیسک با رابط تعاملی

• grep: برای فیلتر کردن و یافتن اطلاعات در فایل‌های لاگ یا پیکربندی

ویرایشگر

کلیک روی ویراستار یک تب جدید مرورگر را باز می‌کند تا به یک محیط توسعهٔ یکپارچهٔ آنلاین (IDE) برای ویرایش کد منبع دسترسی پیدا کنید. همچنین می‌توانید ترمینال‌ها، کنسول‌های Python و کنسول‌های Odoo shell را باز کنید.

می‌توانید چندین تب را باز کنید و با drag-and-drop چیدمان را به دلخواه تنظیم کنید.

همچنین ببینید

مستندات ویرایشگر آنلاین.

پایش

تب Monitor معیارهای مختلف پایش عملکرد ساخت فعلی را نمایش می‌دهد.

با نشانگر خود Zoom in کنید تا بازهٔ زمانی را تنظیم کنید یا آن را به‌صورت دستی از انتخاب‌گر بازهٔ زمانی انتخاب کنید. همچنین تغییر منطقهٔ زمانی امکان‌پذیر است.

توجه

• لاگ‌های فنی همیشه از UTC استفاده می‌کنند. برای تحلیل این لاگ‌ها به همراه معیارهای پایش، اطمینان حاصل کنید که UTC در ابزار پایش انتخاب شده است.

• به همین ترتیب، هنگام ارسال یک تیکت پشتیبانی، اطمینان حاصل کنید اطلاعاتی که به اشتراک می‌گذارید بر اساس UTC است، زیرا Odoo از این منطقهٔ زمانی برای بررسی مشکلات عملکرد استفاده می‌کند.

اطلاعات به‌صورت دوره‌ای تجمیع می‌شوند. در این حالت، یک خط نقطه‌چین آبی به همراه برچسب Aggregate Date نمایش داده می‌شود. این به این معنی است که داده‌های قبل از این تاریخ در مقایسه با داده‌های پس از این تاریخ مسطح به نظر می‌رسند. بنابراین هنگام استفاده از ابزار پایش، توصیه می‌شود برای دستیابی به دقیق‌ترین اطلاعات ممکن، روی رویدادهای اخیر تمرکز کنید.

توجه

خطوط نقطه‌چین با رنگ‌های دیگر به شما کمک می‌کنند تغییرات دیگر روی ساخت (وارد کردن پایگاه داده، git push و غیره) را تشخیص دهید.

نکته

روی هر نمودار، یک آیکون 𝕚 (اطلاعات) در گوشهٔ بالا سمت چپ نمایش داده می‌شود. ماوس خود را روی آن نگه دارید تا جزئیات بیشتری دربارهٔ آنچه نمودار نمایش می‌دهد دریافت کنید.

معیارها

سیستم

نمودار Memory اطلاعاتی دربارهٔ مصرف حافظه نمایش می‌دهد:

• Memory container نمایانگر workerهای Odoo و فرایندهای کانتینر است.

• Memory postgresql نمایانگر پایگاه داده است.

نمودار CPU اطلاعاتی دربارهٔ مصرف CPU نمایش می‌دهد:

• CPU http نمایانگر workerهای Odoo است.

• CPU cron/mail نمایانگر اقدامات برنامه‌ریزی‌شده و ایمیل‌های ورودی است.

• CPU postgresql (فرایندهای پایگاه داده)

• CPU other نمایانگر webshellها، ویرایشگر و غیره است.

نمودار مکان انبار اطلاعاتی دربارهٔ فضای ذخیره‌سازی مصرف‌شده نمایش می‌دهد:

• Container نمایانگر filestore، فایل‌های لاگ و فایل‌های کاربر است.

• Postgresql نمایانگر پایگاه داده و indexها است.

HTTP

نمودار درخواست ها اطلاعاتی دربارهٔ تعداد درخواست‌های HTTP در ثانیه نمایش می‌دهد:

• HTTP successes نمایانگر درخواست‌های موفق است.

• HTTP errors نمایانگر درخواست‌های ناموفق است (فایل odoo.log را بررسی کنید).

• HTTP rate limited نمایانگر درخواست‌های ردشده است، احتمالاً به‌دلیل کمبود workerها.

نمودار Concurrent requests (max) بیشینهٔ تعداد درخواست‌های HTTP هم‌زمان در ثانیه را نمایش می‌دهد.

توجه

workerهای پایگاه داده تعداد درخواست‌های هم‌زمانی را که می‌توان به‌طور هم‌زمان مدیریت کرد تعیین می‌کنند. داشتن workerهای کافی برای رسیدگی به تمام درخواست‌های ورودی به‌محض رسیدن آن‌ها ضروری است. با این حال، داشتن workerهای اضافی فراتر از این، سرعت پردازش درخواست‌ها را بهبود نمی‌بخشد.

نمودار Average Response time میانگین زمان پاسخ به درخواست‌های HTTP (به میلی‌ثانیه) را نمایش می‌دهد.

ایمیل‌ها

نمودار پیش رو داده‌هایی دربارهٔ تعداد روزانهٔ ایمیل‌های ورودی نمایش می‌دهد:

• Received Emails نمایانگر ایمیل‌هایی است که با موفقیت دریافت شده‌اند.

• Received Emails bounced نمایانگر ایمیل‌هایی است که دریافت آن‌ها ناموفق بوده است.

نمودار خروجی داده‌هایی دربارهٔ تعداد روزانهٔ ایمیل‌های خروجی نمایش می‌دهد:

• Sent Emails نمایانگر ایمیل‌هایی است که با موفقیت ارسال شده‌اند.

• Sent Emails bounced نمایانگر ایمیل‌هایی است که ارسال آن‌ها ناموفق بوده است.

لاگ‌ها

تب گزارش ها نمای زنده‌ای از لاگ‌های سرور شما ارائه می‌دهد.

لاگ‌های مختلفی در دسترس است:

• pip.log: نصب وابستگی‌های Python

• install.log: نصب پایگاه داده (برای شاخه‌های توسعه، آزمون‌ها نیز شامل می‌شوند)

• odoosh-import-database.log: فرایند dump آخرین وارد شده

• odoo.log: سرور در حال اجرا

• update.log: به‌روزرسانی‌های پایگاه داده

• pg_slow_queries.log: کوئری‌های psql که زمان غیرعادی می‌برند

• sh_webshell.log: اقدامات انجام‌شده در webshell

• sh_editor.log: اقدامات انجام‌شده در ویرایشگر

• neutralize.log: خنثی‌سازی پایگاه داده (فقط staging)

هنگامی که خطوط جدید به لاگ‌ها اضافه می‌شوند، به‌صورت خودکار نمایش داده می‌شوند. اگر به پایین scroll کنید، هر بار که خط جدیدی اضافه می‌شود مرورگر به‌صورت خودکار scroll می‌کند.

می‌توانید با کلیک روی دکمهٔ (مکث) در گوشهٔ بالا سمت راست، فرایند fetch لاگ‌ها را متوقف کنید. در غیر این صورت، فرایند پس از پنج دقیقه متوقف می‌شود. می‌توانید با کلیک روی دکمهٔ (play) آن را دوباره راه‌اندازی کنید.

پشتیبان‌ها

تب Backups نسخه‌های پشتیبان در دسترس برای دانلود و بازیابی را فهرست می‌کند، به شما اجازه می‌دهد یک پشتیبان دستی بگیرید و یک پایگاه داده وارد کنید.

از پایگاه دادهٔ تولید به‌صورت خودکار روزانه پشتیبان‌گیری می‌شود. هفت پشتیبان روزانه، چهار هفتگی و سه ماهانه نگه داشته می‌شود. هر پشتیبان شامل dump پایگاه داده، filestore (پیوست‌ها و فیلدهای binary)، لاگ‌ها و sessionها است.

توجه

می‌توانید برای درک بهتر نحوهٔ کار سیستم به زمان‌بندی تخمینی پشتیبان‌گیری‌های خودکار مراجعه کنید. این فایل روزانه به‌روزرسانی می‌شود و روز جاری را به‌عنوان نقطهٔ مبدأ در نظر می‌گیرد.

از پایگاه‌های دادهٔ staging و توسعه به‌صورت خودکار پشتیبان‌گیری نمی‌شود. با این حال، می‌توانید یک پشتیبان از پایگاه دادهٔ تولید را در شاخه‌های staging خود برای اهداف آزمایشی بازیابی کنید یا داده‌هایی را که به‌اشتباه از پایگاه دادهٔ تولید حذف شده‌اند به‌صورت دستی بازیابی کنید.

فهرست شامل پشتیبان‌هایی است که روی سرور پایگاه دادهٔ تولید شما نگه داشته می‌شوند. این سرور فقط یک ماه پشتیبان نگه می‌دارد: هفت پشتیبان روزانه و چهار هفتگی.

سرورهای پشتیبان اختصاصی همان پشتیبان‌ها را، به همراه سه پشتیبان ماهانهٔ اضافی، نگه می‌دارند. برای بازیابی یا دانلود یکی از این پشتیبان‌های ماهانه، با Odoo Support تماس بگیرید.

هنگام merge کردن یک commit که نسخهٔ یک یا چند ماژول را (در __manifest__.py) یا وابستگی‌های Python متصل به آن‌ها را (در requirements.txt) به‌روزرسانی می‌کند، Odoo.sh یک پشتیبان‌گیری خودکار انجام می‌دهد (با نوع Update در فهرست علامت‌گذاری می‌شود)، زیرا یا کانتینر با نصب بسته‌های pip جدید تغییر می‌کند، یا خود پایگاه داده با به‌روزرسانی ماژول که پس از آن trigger می‌شود تغییر می‌کند. در این دو حالت، یک پشتیبان trigger می‌شود زیرا ممکن است چیزی را خراب کند.

اگر commit merge‌شده نسخهٔ یک ماژول یا وابستگی‌های متصل را به‌روزرسانی نکند، هیچ پشتیبانی توسط Odoo.sh trigger نمی‌شود، زیرا نه کانتینر و نه پایگاه داده اصلاح نمی‌شود؛ بنابراین پلتفرم این را به‌اندازهٔ کافی امن می‌داند. به‌عنوان احتیاط اضافی، می‌توانید پیش از اصلاح منابع تولید یک پشتیبان دستی بگیرید.

هدف پشتیبان‌های دستی، ایجاد یک snapshot خاص از پایگاه‌های دادهٔ تولید یا staging است (برای توسعه در دسترس نیست). این‌ها به مدت هفت روز در دسترس باقی می‌مانند. با این حال، محدودیت پنج پشتیبان دستی روزانه وجود دارد.

مرحله	پشتیبان‌گیری خودکار	پشتیبان‌گیری دستی
تولید	بله (تا ۳ ماه)	بله (۳ روز)
مرحله‌بندی	خیر	بله (۳ روز)
توسعه	خیر	خیر

ویژگی Import Database آرشیوهای پایگاه داده از منابع زیر را می‌پذیرد:

• مدیر استاندارد پایگاه دادهٔ Odoo (در سرورهای on-premise Odoo تحت /web/database/manager در دسترس است)

• مدیر پایگاه‌های دادهٔ Odoo Online

• تب Backups در Odoo.sh (با استفاده از دکمهٔ (Download Options))

• نمای Builds در Odoo.sh (با کلیک روی Download DB dump)

ارتقا

از تب ارتقا می‌توان برای ارتقای شاخه‌های تولید و staging پروژه‌های معتبر استفاده کرد. برای اطلاعات بیشتر دربارهٔ فرایند ارتقا، به مستندات Upgrade مراجعه کنید.

ابزارها

تب Tools شامل code profiler است. از آن برای شروع یک نشست profiling استفاده می‌شود که فعالیت‌های workerهای Odoo در حال اجرا در نمونه را به مدت حداکثر پنج دقیقه ضبط می‌کند. می‌توانید انتخاب کنید نشست را زودتر خاتمه دهید، زیرا اجرای ابزار برای مدت کوتاه‌تر، میزان noise در گزارش را کاهش می‌دهد.

پس از هر نشست، یک flame graph تعاملی ایجاد می‌شود تا به شما کمک کند نحوهٔ تخصیص زمان توسط workerهای Odoo را تجسم کنید.

هشدار

اجرای profiler منابع سرور زیادی مصرف می‌کند، بنابراین از اجازه دادن به اجرای طولانی‌مدت آن خودداری کنید. هدف، ضبط یک اقدام خاص در پایگاه داده شما است.

تنظیمات

تب تنظیمات گزینه‌های پیکربندی در دسترس برای شاخهٔ انتخاب‌شدهٔ فعلی را فهرست می‌کند. گزینه‌ها برای هر مرحله متفاوت است.

رفتار هنگام دریافت commitهای جدید

می‌توانید رفتار شاخه را هنگام دریافت یک commit جدید برای شاخه‌های development و staging تغییر دهید.

به‌صورت پیش‌فرض، یک شاخهٔ توسعه یک ساخت جدید ایجاد می‌کند و یک شاخهٔ staging ساخت قبلی را به‌روزرسانی می‌کند. این مفید است اگر ویژگی‌ای که روی آن کار می‌کنید نیازمند یک پیکربندی خاص است، زیرا نیازی نخواهید داشت پس از هر commit آن را به‌صورت دستی دوباره پیکربندی کنید.

اگر New build را برای یک شاخهٔ staging انتخاب کنید، هر بار که یک commit push شود یک کپی تازه از ساخت تولیدی ایجاد می‌شود.

شاخه‌ای که از staging به development منتقل می‌شود به‌صورت خودکار روی Do nothing تنظیم می‌شود.

نصب ماژول

می‌توانید انتخاب کنید کدام ماژول‌ها به‌صورت خودکار برای شاخه‌های development نصب شوند.

برای تغییر رفتار پیش‌فرض، تیک گزینهٔ Use Default در زیر Development build behavior را بردارید و یکی از گزینه‌های زیر در زیر Module Installation را انتخاب کنید:

• Install only my modules (does not include submodules): فقط ماژول‌های شاخه را نصب می‌کند، به‌جز زیرماژول‌ها. این گزینهٔ پیش‌فرض است.

• Full installation (no test suite): ماژول‌های شاخه، زیرماژول‌ها و تمام ماژول‌های استاندارد Odoo را نصب می‌کند. هنگام اجرای نصب کامل، مجموعهٔ آزمون غیرفعال می‌شود.

• Install a list of modules: ماژول‌های مشخص‌شده را نصب می‌کند. برای این کار، نام فنی آن‌ها را وارد کنید و آن‌ها را با کاما از هم جدا کنید (مثلاً sale_management,website,accountant).

توجه

اگر مجموعهٔ آزمون فعال باشد، نصب تمام ماژول‌های استاندارد Odoo می‌تواند تا یک ساعت طول بکشد.

مجموعهٔ آزمون

به‌صورت پیش‌فرض، مجموعهٔ آزمون برای شاخه‌های توسعه فعال است. می‌توانید با وارد کردن test tags و جداسازی آن‌ها با کاما (مثلاً custom_tags,at_install,post_install)، آزمون‌هایی را که اجرا می‌شوند محدود کنید.

برای غیرفعال کردن کامل مجموعهٔ آزمون، تیک Validate the test suite on new builds را بردارید.

نسخهٔ Odoo

می‌توانید نسخهٔ Odoo را برای شاخه‌های توسعه تغییر دهید، برای مثال برای آزمایش کد ارتقایافته یا توسعهٔ ویژگی‌ها در حالی که پایگاه دادهٔ تولید شما در حال ارتقا به نسخهٔ جدیدتر است، با انتخاب نگارش دیگر.

به‌صورت پیش‌فرض، Latest به‌عنوان Revision انتخاب می‌شود و منابع سرور Odoo شما به‌صورت خودکار هفتگی به‌روزرسانی می‌شوند تا از آخرین اصلاحات باگ، امنیت و عملکرد بهره‌مند شوند.

برای انتخاب یک revision خاص، آن را از طریق فیلد Revision انتخاب کنید.

هشدار

revisionها پس از سه ماه منقضی می‌شوند. زمانی که تاریخ انقضای revision نزدیک می‌شود از طریق ایمیل به شما اطلاع داده می‌شود. اگر هنگام انقضا اقدامی نکرده باشید، فیلد Revision به‌صورت خودکار به Latest بازگردانده می‌شود.

دامنه‌های سفارشی

می‌توانید برای همهٔ انواع شاخه، دامنه‌های اضافی <name>.odoo.com یا دامنه‌های سفارشی خود را پیکربندی کنید.

برای استفاده از دامنهٔ سفارشی خود، لازم است:

• نام دامنه را در اختیار داشته باشید یا خریداری کنید.

• نام دامنه را در بخش Custom domains (مثلاً www.mycompany.com) وارد کنید، سپس روی Add domain کلیک کنید.

• نام دامنه (مثلاً www.mycompany.com) را با استفاده از domain name manager registrar خود، با مقدار رکورد CNAME تنظیم‌شده روی نام دامنهٔ پایگاه دادهٔ تولید شما (مثلاً mycompany.odoo.com) پیکربندی کنید.

مهم

دامنه‌های bare (مثلاً mycompany.com) پذیرفته نمی‌شوند. آن‌ها را فقط می‌توان با استفاده از رکوردهای A که تنها آدرس‌های IP را به‌عنوان مقدار خود می‌پذیرند پیکربندی کرد. بنابراین، یک دامنهٔ bare می‌تواند ناگهان از کار بیفتد، زیرا آدرس IP یک پایگاه داده می‌تواند تغییر کند (مثلاً پس از یک ارتقا، یک خرابی سخت‌افزاری، یا تغییر مکان میزبانی پایگاه داده).

برای داشتن همزمان دامنهٔ bare (مثلاً mycompany.com) و دامنهٔ www (مثلاً www.mycompany.com) که کار کنند، لازم است دامنهٔ bare را به دامنهٔ www بازهدایت کنید. .com. بیشتر domain managerها روشی برای پیکربندی این بازهدایت، که معمولاً به آن web redirection گفته می‌شود، ارائه می‌دهند.

HTTPS/SSL

اگر بازهدایت به‌درستی تنظیم شده باشد، یک گواهی SSL به‌صورت خودکار با استفاده از Let's Encrypt ظرف یک ساعت تولید می‌شود، به این معنی که دامنهٔ شما از طریق HTTPS قابل دسترسی خواهد بود.

انطباق با SPF و DKIM

اگر دامنهٔ آدرس‌های ایمیل شما از پروتکل احراز هویت SPF یا DKIM استفاده می‌کند، لازم است Odoo را به‌عنوان sending host در تنظیمات نام دامنه مجاز کنید تا deliverability ایمیل‌های خروجی افزایش یابد. برای اطلاعات بیشتر به مستندات Configure DNS records to send emails in Odoo مراجعه کنید.

مهم

اگر Odoo به‌عنوان میزبان ارسال‌کننده مجاز شناخته نشود، ایمیل‌های خروجی شما ممکن است به‌عنوان spam علامت‌گذاری شوند.

دستورات شل

در گوشهٔ بالا سمت راست نما، چندین دستور shell نمایش داده می‌شود. دستورات را می‌توان با استفاده از دکمهٔ clipboard کپی کرد و سپس در یک ترمینال استفاده کرد. علاوه بر این، برخی از آن‌ها را می‌توان مستقیماً از رابط Odoo.sh استفاده کرد.

کلون

دستور clone برای ایجاد یک کپی محلی از مخزن Git شما استفاده می‌شود.

Example

git clone --recurse-submodules --branch development git@github.com:my-organization/my-repository.git

• --recurse-submodules برای دانلود زیرماژول‌های مخزن شما

• --branch main برای برداشت به یک شاخهٔ خاص مخزن (مثلاً development)

توجه

دکمهٔ run در دسترس نیست زیرا این دستور برای ایجاد یک کپی محلی روی دستگاه شما استفاده می‌شود.

انشعاب

دستور fork برای ایجاد یک شاخهٔ جدید بر اساس شاخهٔ فعلی استفاده می‌شود.

Example

git checkout -b main-1 development && git push -u origin development-1

• git checkout -b main-1 main دستوری برای ایجاد یک شاخهٔ جدید (مثلاً development-1) بر اساس شاخهٔ فعلی (مثلاً development)

• git push -u origin development-1 دستوری برای آپلود شاخهٔ جدید (مثلاً development-1) به مخزن راه‌دور

ادغام

دستور merge برای ترکیب تغییرات یک شاخه در شاخهٔ دیگر استفاده می‌شود.

Example

git merge staging-1 && git push -u origin staging

• git merge staging-1 دستوری برای merge کردن تغییرات شاخهٔ فعلی در شاخهٔ دیگر (مثلاً staging-1)

• git push -u origin staging دستوری برای آپلود تغییرات merge‌شده به شاخهٔ مخزن راه‌دور (مثلاً staging)

SSH

دستور SSH برای اتصال به یک ساخت با استفاده از SSH استفاده می‌شود.

برای استفاده از دستور SSH، ابتدا باید یک کلید SSH تنظیم کنید. برای این کار:

• یک کلید SSH جدید تولید کنید.

• کلید SSH را در clipboard خود کپی کنید.

• در Odoo.sh، روی کاربر GitHub خود در گوشهٔ بالا سمت راست کلیک کنید و پروفایل را انتخاب کنید.

  

• کلید SSH را در فیلد Add a key manually paste کنید و روی افزودن کلیک کنید.

  

Example

ssh 25004381@my-user-my-repository-staging-25004381.dev.odoo.com

• 25004381 شناسهٔ ساخت

• my-user-my-repository-staging-25004381.dev.odoo.com دامنهٔ مورد استفاده برای اتصال به ساخت

به شرط اینکه حقوق دسترسی لازم را روی پروژه داشته باشید، دسترسی SSH به ساخت به شما داده می‌شود.

توجه

اتصال‌های SSH با اجرای طولانی تضمین نمی‌شوند. اتصال‌های بیکار می‌توانند برای آزادسازی منابع قطع شوند.

زیرماژول

دستور submodule برای افزودن یک شاخه از مخزن دیگر به شاخهٔ فعلی شما به‌عنوان زیرماژول استفاده می‌شود.

همچنین ببینید

مستندات زیرماژول‌ها

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging

• git submodule add -b master <URL> <PATH> دستوری برای افزودن یک شاخهٔ خاص (مثلاً master) از یک مخزن (<URL>) به‌عنوان زیرماژول در مسیر مشخص‌شده (<PATH>) در شاخهٔ فعلی شما.

• git commit -a دستوری برای commit کردن تمام تغییرات فعلی

• git push -u origin staging دستوری برای آپلود تغییرات شاخهٔ فعلی (مثلاً staging) به مخزن راه‌دور.

حذف

دستور delete برای حذف یک شاخه از مخزن شما استفاده می‌شود.

توجه

پس از حذف یک شاخه، هیچ راهی برای بازیابی آن وجود ندارد مگر اینکه یک پشتیبان موجود باشد. شاخه‌های staging به‌صورت خودکار پشتیبان‌گیری نمی‌شوند، اما می‌توان به‌صورت دستی این کار را کرد. از شاخه‌های توسعه نمی‌توان پشتیبان گرفت.

Example

git push origin :staging && git branch -D staging

• git push origin :staging دستوری برای حذف یک شاخهٔ خاص (مثلاً staging) در مخزن راه‌دور

• git branch -D staging دستوری برای حذف شاخهٔ خاص در کپی محلی مخزن

هشدار

پیش از حذف یک شاخه، برای درک بهتر نحوهٔ کار آن‌ها و زمانی که باید یک پشتیبان دستی بگیرید به بخش Backups مراجعه کنید.