Оновлення налаштованої бази даних

Оновлення до нової версії Odoo може бути складним, особливо якщо база даних, з якою ви працюєте, містить кастомні модулі. Ця сторінка має на меті пояснити технічний процес оновлення бази даних з кастомними модулями. Зверніться до Документація з оновлення для отримання вказівок щодо оновлення бази даних без кастомних модулів.

Ми вважаємо кастомним модулем будь-який модуль, який розширює стандартний код Odoo і не був створений за допомогою програми Studio. Перед оновленням такого модуля, або перед запитом на його оновлення, подивіться на Угода про рівень обслуговування (SLA), щоб переконатися, хто за нього відповідає.

Під час роботи над тим, що ми називаємо користувацьким оновленням вашої бази даних, пам’ятайте про цілі оновлення:

1. Залишайтеся підтриманими

2. Отримайте найновіші функції

3. Насолоджуйтесь покращенням продуктивності

4. Зменшити технічний борг

5. Скористайтеся перевагами покращень безпеки

З кожною новою версією Odoo вносяться зміни. Ці зміни можуть вплинути на модулі, для яких було розроблено кастомізацію. Це є причиною того, що оновлення бази даних, яка містить кастомні модулі, вимагає додаткових кроків для оновлення вихідного коду.

Ось кроки, які потрібно виконати для оновлення налаштованих баз даних:

1. Зупиніть розробки та кинь їм виклик.

2. Запит на оновлення бази даних.

3. Зробіть ваш модуль встановлюваним на порожню базу даних.

4. Зробіть ваш модуль придатним для встановлення на оновлену базу даних.

5. Ретельно протестуйте та проведіть репетицію.

6. Оновлення робочої бази даних.

Крок 1: Зупинити розвиток подій

Початок оновлення вимагає зобов’язань і ресурсів для розробки. Якщо розробки продовжуватимуться одночасно, ці функції потрібно буде оновлювати та тестувати кожного разу, коли ви їх зміните. Ось чому ми рекомендуємо повністю заморозити кодову базу перед початком процесу оновлення. Зрозуміло, що ця рекомендація не поширюється на виправлення помилок.

Після того, як ви зупинили розробку, рекомендується оцінити зроблені зміни і порівняти їх з функціями, що з’явилися між поточною версією і версією, на яку ви орієнтуєтесь. Ставте під сумнів розробки, наскільки це можливо, і знаходьте функціональні обхідні шляхи. Видалення надлишковості між вашими розробками і стандартною версією Odoo призведе до полегшення процесу оновлення і скорочення технічного боргу.

Примітка

Ви можете знайти інформацію про зміни між версіями в Примітки до випуску.

Крок 2: Запит на оновлення бази даних

Після того, як розробку кастомних модулів зупинено, а реалізовані функції перевірено на наявність надлишкового та непотрібного коду, наступним кроком буде запит на оновлення тестової бази даних. Для цього виконайте кроки, зазначені в Отримання оновленої тестової бази даних, залежно від типу хостингу вашої бази даних.

Мета цього етапу - не розпочати роботу з кастомними модулями в оновленій базі даних, а переконатися, що стандартний процес оновлення працює безперебійно, а тестова база даних доставлена належним чином. Якщо це не так, і запит на оновлення не виконується, зверніться за допомогою до Odoo через сторінка підтримки, вибравши опцію, пов’язану з тестуванням оновлення.

Крок 3: Очистити базу даних

Перш ніж працювати з оновленою тестовою базою даних, ми рекомендуємо перевірити роботу кастомних розробок на порожній базі даних у цільовій версії вашого оновлення. Це забезпечить сумісність кастомізації з новою версією Odoo, дозволить проаналізувати її поведінку і взаємодію з новими функціями, а також гарантує, що вони не викличуть жодних проблем при оновленні бази даних.

Запуск кастомних модулів у порожній базі даних також допомагає уникнути змін і неправильних конфігурацій, які можуть бути присутніми у виробничій базі даних (наприклад, студійні налаштування, кастомізовані сторінки веб-сайтів, шаблони електронної пошти або переклади). Вони не пов’язані з кастомними модулями по суті, і це може викликати небажані проблеми на цьому етапі процесу оновлення.

Щоб користувацькі модулі працювали на порожній базі даних, радимо виконати такі кроки:

1. Зробіть власні модулі придатними для встановлення

2. Тестування та виправлення

3. Очистіть код

4. Зробити стандартні тести успішно запущеними

Зробіть власні модулі придатними для встановлення

Перший крок - зробити так, щоб кастомні модулі можна було встановити в новій версії Odoo. Це означає, що спочатку потрібно переконатися, що під час їхнього встановлення не буде ніяких відстежень або попереджень. Для цього встановіть кастомні модулі, один за одним, у порожню базу даних нової версії Odoo і виправте помилки та попередження, що виникають при цьому.

Цей процес допоможе виявити проблеми під час встановлення модулів. Наприклад:

• Недійсні залежності модулів.

• Syntax change: assets declaration, OWL updates, attrs.

• Посилання на стандартні поля, моделі, представлення, які більше не існують або перейменовані.

• XPath, які переміщено або видалено з представлень.

• Методи перейменовані або видалені.

• …

Тестування та виправлення

Після того, як при встановленні модулів більше не виникає помилок, наступним кроком є їхнє тестування. Навіть якщо кастомні модулі встановлюються на порожню базу даних, це не гарантує відсутності помилок під час їх виконання. Тому ми рекомендуємо ретельно протестувати всі налаштування, щоб переконатися, що все працює належним чином.

Цей процес допоможе виявити подальші проблеми, які не були виявлені під час встановлення модуля і можуть бути виявлені лише під час виконання. Наприклад, застарілі виклики стандартних функцій python або OWL, неіснуючі посилання на стандартні поля тощо.

Ми рекомендуємо протестувати всі налаштування, особливо такі елементи:

• Представлення

• Шаблони електронних листів

• Звіти

• Дії сервера та автоматизовані дії

• Зміни у стандартних робочих процесах

• Обчислювані поля

Ми також рекомендуємо писати автоматизовані тести, щоб заощадити час під час ітерацій тестування, збільшити покриття тестів і переконатися, що внесені зміни та виправлення не порушують існуючі потоки. Якщо в кастомізації вже є тести, переконайтеся, що вони оновлені до нової версії Odoo і успішно працюють, виправляючи проблеми, які можуть бути присутніми.

Очистіть код

На цьому етапі процесу оновлення ми також рекомендуємо максимально очистити код. Це включає:

• Видаліть зайвий та непотрібний код.

• Видаліть функції, які тепер є частиною стандарту Odoo, як описано в Крок 1: Зупинити розвиток подій.

• Очистіть прокоментований код, якщо він більше не потрібен.

• Рефакторинг коду (функцій, полів, представлень, звітів і т.д.), якщо це необхідно.

Стандартні тести

Після завершення попередніх кроків ми рекомендуємо переконатися, що всі стандартні тести, пов’язані з залежностями кастомного модуля, пройшли. Стандартні тести забезпечують перевірку логіки коду і запобігають пошкодженню даних. Вони допоможуть вам виявити помилки або небажану поведінку до того, як ви почнете працювати над базою даних.

У випадку невдачі стандартних тестів, ми пропонуємо проаналізувати причину їх невдачі:

• Налаштування змінює стандартний робочий процес: адаптуйте стандартний тест до свого робочого процесу.

• Налаштування не враховувало спеціальний потік: адаптуйте своє налаштування, щоб воно працювало для всіх стандартних робочих процесів.

Крок 4: Оновлена база даних

Після того, як кастомні модулі встановлено і вони працюють належним чином у порожній базі даних, настав час змусити їх працювати на оновленій базі даних.

Щоб переконатися, що користувацький код працює бездоганно в новій версії, виконайте такі кроки:

• Міграція даних

• Тестування користувацьких модулів

Міграція даних

Під час оновлення користувацьких модулів вам може знадобитися скрипти оновлення для відображення змін у вихідному коді у відповідних даних. Разом зі скриптами оновлення ви також можете скористатися Upgrade utils та його допоміжними функціями.

• Будь-які технічні дані, що були перейменовані під час оновлення користувацького коду (моделі, поля, зовнішні ідентифікатори), слід перейменувати за допомогою скриптів оновлення, щоб уникнути втрати даних під час оновлення модуля. Дивіться також: rename_field(), rename_model(), rename_xmlid().

• Дані зі стандартних моделей, видалені з вихідного коду нової версії Odoo та з бази даних під час стандартного процесу оновлення, можливо, доведеться відновлювати зі старої таблиці моделей, якщо вона все ще присутня.

  Example

  Кастомні поля для моделі sale.subscription не переносяться автоматично з Odoo 15 в Odoo 16 (коли модель була об’єднана в sale.order). У цьому випадку можна виконати SQL-запит в скрипті оновлення, щоб перенести дані з однієї таблиці в іншу. Візьміть до уваги, що всі стовпці/поля вже повинні існувати, тому розгляньте можливість виконання цього запиту в пост- скрипті (див. upgrade-scripts/phases`).

  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, на цій платформі неможливо запускати скрипти оновлення.

Тестування користувацьких модулів

Щоб переконатися, що користувацькі модулі працюють належним чином з вашими даними в оновленій базі даних, їх також потрібно протестувати. Це допоможе переконатися, що стандартні та користувацькі дані, які зберігаються в базі даних, узгоджуються, і що нічого не було втрачено під час процесу оновлення.

На що звернути увагу:

• Представлення не працюють: Під час оновлення, якщо представлення викликає проблеми через свій вміст, його буде вимкнено. Ви можете знайти інформацію про вимкнені представлення у звіті про оновлення. Це подання потрібно знову активувати (або видалити, якщо воно більше не потрібне). Для цього ми рекомендуємо використовувати сценарії оновлення.

• doc:Дані модуля <../tutorials/define_module_data> не оновлено: Користувацькі записи, які мають прапорець noupdate, не оновлюються при оновленні модуля в новій базі даних. Для кастомних даних, які необхідно оновити у зв’язку зі змінами в новій версії, ми рекомендуємо використовувати скрипти оновлення. Дивіться також: update_record_from_xml().

Крок 5: Тестування та репетиція

Коли користувацькі модулі будуть працювати належним чином в оновленій базі даних, важливо провести ще один раунд тестування, щоб оцінити зручність використання бази даних і виявити будь-які проблеми, які могли залишитися непоміченими під час попередніх тестів. Для отримання додаткової інформації про тестування оновленої бази даних перевірте Тестування нової версії бази даних.

Як зазначено у Оновлення виробничої бази даних, як стандартні скрипти оновлення, так і ваша база даних постійно розвиваються. Тому наполегливо рекомендується часто запитувати нові оновлені тестові бази даних, щоб переконатися, що процес оновлення є успішним.

Крім того, проведіть повну репетицію процесу оновлення за день до оновлення робочої бази даних, щоб уникнути небажаної поведінки під час оновлення і виявити будь-які проблеми, які могли виникнути з перенесеними даними.

Крок 6: Оновлення виробництва

Після того, як ви будете впевнені в оновленні вашої виробничої бази даних, виконайте процес, описаний на сторінці Оновлення виробничої бази даних, залежно від типу хостингу вашої бази даних.