ارتقای یک پایگاه‌دادهٔ سفارشی‌شده

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

هر ماژولی که کد استاندارد Odoo را گسترش می‌دهد و با اپلیکیشن Studio ساخته نشده باشد را یک ماژول سفارشی در نظر می‌گیریم. پیش از ارتقای چنین ماژولی یا درخواست ارتقای آن، نگاهی به توافق‌نامهٔ سطح خدمات (SLA) بیندازید تا مطمئن شوید چه کسی مسئول آن است.

هنگام کار روی آنچه ما ارتقای سفارشی پایگاه‌دادهٔ شما می‌نامیم، اهداف یک ارتقا را در نظر داشته باشید:

1. تحت پشتیبانی بمانید

2. ویژگی‌های جدید را به‌دست آورید

3. از بهبود عملکرد بهره ببرید

4. بدهی فنی را کاهش دهید

5. از بهبودهای امنیتی بهره‌مند شوید

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

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

1. توسعه‌ها را متوقف کنید و آن‌ها را به چالش بکشید.

2. یک پایگاه‌دادهٔ ارتقایافته درخواست کنید.

3. ماژول خود را در یک پایگاه‌دادهٔ خالی قابل نصب کنید.

4. ماژول خود را روی پایگاه‌دادهٔ ارتقایافته قابل نصب کنید.

5. آزمایش گسترده و تمرین انجام دهید.

6. پایگاه‌دادهٔ تولید را ارتقا دهید.

گام ۱: توسعه‌ها را متوقف کنید

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

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

توجه

می‌توانید اطلاعات مربوط به تغییرات بین نسخه‌ها را در یادداشت‌های انتشار بیابید.

گام ۲: درخواست یک پایگاه‌دادهٔ ارتقایافته

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

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

گام ۳: پایگاه‌دادهٔ خالی

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

کار کردن ماژول‌های سفارشی در پایگاه‌دادهٔ خالی همچنین به جلوگیری از تغییرات و پیکربندی‌های نادرستی کمک می‌کند که ممکن است در پایگاه‌دادهٔ تولید وجود داشته باشد (مانند سفارشی‌سازی studio، صفحات سفارشی‌سازی‌شدهٔ وب‌سایت، قالب‌های ایمیل یا ترجمه‌ها). این موارد ذاتاً به ماژول‌های سفارشی مرتبط نیستند و می‌توانند در این مرحله از فرآیند ارتقا، مسائل ناخواسته‌ای را ایجاد کنند.

برای کار کردن ماژول‌های سفارشی روی یک پایگاه‌دادهٔ خالی، توصیه می‌کنیم این گام‌ها را دنبال کنید:

1. ماژول‌های سفارشی را قابل نصب کنید

2. آزمایش و رفع اشکالات

3. کد را تمیز کنید

4. تست‌های استاندارد را با موفقیت اجرا کنید

ماژول‌های سفارشی را قابل نصب کنید

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

این فرآیند به شناسایی مسائل در طول نصب ماژول‌ها کمک می‌کند. برای مثال:

• وابستگی‌های ماژول نامعتبر.

• تغییر سینتکس: اعلان assets، به‌روزرسانی‌های OWL، attrs.

• ارجاع به فیلدها، مدل‌ها، نماهای استانداردی که دیگر وجود ندارند یا تغییر نام داده‌اند.

• Xpathهایی که از نماها جابه‌جا یا حذف شده‌اند.

• متدهایی که تغییر نام داده یا حذف شده‌اند.

• ...

آزمایش و رفع اشکالات

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

این فرآیند به شناسایی مسائل بیشتری که در طول نصب ماژول شناسایی نمی‌شوند و تنها در زمان اجرا قابل کشف هستند، کمک می‌کند. برای مثال، فراخوانی‌های منسوخ توابع python یا OWL استاندارد، ارجاع به فیلدهای استاندارد ناموجود، و غیره.

توصیه می‌کنیم همهٔ سفارشی‌سازی را آزمایش کنید، به‌ویژه عناصر زیر:

• نماها

• قالب‌های ایمیل

• گزارش‌ها

• اکشن‌های سرور و اکشن‌های خودکار

• تغییرات در workflowهای استاندارد

• فیلدهای محاسبه‌شده

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

کد را تمیز کنید

در این مرحله از فرآیند ارتقا، همچنین پیشنهاد می‌کنیم کد را تا حد ممکن تمیز کنید. این شامل موارد زیر می‌شود:

• کد افزوده و غیرضروری را حذف کنید.

• ویژگی‌هایی که اکنون بخشی از استاندارد Odoo هستند را حذف کنید، همان‌طور که در گام ۱: توسعه‌ها را متوقف کنید توضیح داده شد.

• اگر کد کامنت‌گذاری شده دیگر مورد نیاز نیست، آن را تمیز کنید.

• در صورت نیاز، کد را بازآرایی (توابع، فیلدها، نماها، گزارش‌ها و غیره) کنید.

تست‌های استاندارد

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

در صورت وجود تست استاندارد ناموفق، پیشنهاد می‌کنیم دلیل شکست آن‌ها را تحلیل کنید:

• سفارشی‌سازی، workflow استاندارد را تغییر می‌دهد: تست استاندارد را با workflow خود تطبیق دهید.

• سفارشی‌سازی، یک جریان خاص را در نظر نگرفته است: سفارشی‌سازی خود را تطبیق دهید تا برای همهٔ workflowهای استاندارد کار کند.

گام ۴: پایگاه‌دادهٔ ارتقایافته

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

برای اطمینان از این که کد سفارشی در نسخهٔ جدید بی‌نقص کار می‌کند، گام‌های زیر را دنبال کنید:

• داده‌ها را migrate کنید

• ماژول‌های سفارشی را آزمایش کنید

داده‌ها را migrate کنید

در طول ارتقای ماژول‌های سفارشی، ممکن است مجبور شوید از اسکریپت‌های ارتقا استفاده کنید تا تغییرات کد منبع را روی داده‌های متناظر آن‌ها منعکس کنید. به همراه اسکریپت‌های ارتقا، می‌توانید از Upgrade utils و توابع کمکی آن نیز استفاده کنید.

• هر دادهٔ فنی که در طول ارتقای کد سفارشی تغییر نام داده شده است (مدل‌ها، فیلدها، شناسه‌های خارجی) باید با استفاده از اسکریپت‌های ارتقا تغییر نام داده شود تا از دست رفتن داده در طول ارتقای ماژول جلوگیری شود. همچنین نگاه کنید: rename_field()، rename_model()، rename_xmlid().

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

  Example

  فیلدهای سفارشی برای مدل sale.subscription به‌طور خودکار از Odoo 15 به Odoo 16 منتقل نمی‌شوند (زمانی که مدل با sale.order ادغام شد). در این مورد، می‌توان یک کوئری SQL را در یک اسکریپت ارتقا اجرا کرد تا داده‌ها از یک جدول به جدول دیگر منتقل شوند. در نظر بگیرید که همهٔ ستون‌ها/فیلدها باید از قبل وجود داشته باشند، بنابراین انجام این کار را در یک اسکریپت post- در نظر بگیرید (نگاه کنید به Phases of upgrade scripts).

  Spoiler

  def migrate(cr, version):
     cr.execute(
        """
        UPDATE sale_order so
           SET custom_field = ss.custom_field
          FROM sale_subscription ss
         WHERE ss.new_sale_order_id = so.id
        """
     )
  

  برای اطلاعات بیشتر دربارهٔ Upgrade scripts به اسناد مراجعه کنید.

از اسکریپت‌های ارتقا همچنین می‌توان برای موارد زیر استفاده کرد:

• تسهیل زمان پردازش یک ارتقا. برای مثال، ذخیرهٔ مقدار فیلدهای محاسبه‌شده‌ی ذخیره‌شده روی مدل‌هایی با تعداد رکورد بسیار زیاد با استفاده از کوئری‌های SQL.

• محاسبهٔ مجدد فیلدها در صورت تغییر محاسبهٔ مقدار آن‌ها. همچنین نگاه کنید: recompute_fields().

• حذف ماژول‌های سفارشی ناخواسته. همچنین نگاه کنید: remove_module().

• اصلاح داده‌های معیوب یا پیکربندی‌های نادرست.

اجرا و آزمایش اسکریپت‌های ارتقا

Odoo OnlineOdoo.shOn-premise

از آنجا که نصب ماژول‌های سفارشی حاوی فایل‌های Python در پایگاه‌داده‌های Odoo Online مجاز نیست، اجرای اسکریپت‌های ارتقا روی این پلتفرم ممکن نیست.

ماژول‌های سفارشی را آزمایش کنید

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

مواردی که باید به آن‌ها توجه شود:

• نماهایی که کار نمی‌کنند: در طول ارتقا، اگر یک نما به‌دلیل محتوای آن مشکلاتی ایجاد کند، غیرفعال می‌شود. اطلاعات نماهای غیرفعال‌شده را می‌توانید در گزارش ارتقا بیابید. این نما باید دوباره فعال شود (یا اگر دیگر مفید نیست، حذف شود). برای دستیابی به این هدف، توصیه می‌کنیم از اسکریپت‌های ارتقا استفاده کنید.

• داده‌های ماژول به‌روزرسانی نشده: رکوردهای سفارشی که پرچم noupdate را دارند، هنگام ارتقای ماژول در پایگاه‌دادهٔ جدید به‌روزرسانی نمی‌شوند. برای داده‌های سفارشی که به‌دلیل تغییرات در نسخهٔ جدید نیاز به به‌روزرسانی دارند، توصیه می‌کنیم برای این کار از اسکریپت‌های ارتقا استفاده کنید. همچنین نگاه کنید: update_record_from_xml().

گام ۵: آزمایش و تمرین

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

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

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

گام ۶: ارتقای تولید

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