Каждая основная версия Odoo поддерживается три года, и каждая новая версия приносит новые функции, исправления и более высокую производительность. Чем дольше компания остаётся на старой версии, тем сложнее будет обновление, поскольку разрыв между версиями постоянно растёт. В этом руководстве пошагово объясняется, как на самом деле проходит обновление для каждого типа хостинга и что компании нужно подготовить, прежде чем переводить рабочую базу данных.
Об источниках: описанные ниже шаги основаны на официальной документации Odoo по обновлению и руководствах для разработчиков. Команды, меню и условия сервиса могут меняться от версии к версии, поэтому перед началом работ всегда сверяйтесь с актуальными инструкциями в официальной документации для целевой версии.
Что такое обновление и чем оно не является
Обновление переносит вашу существующую базу данных со всеми данными со старой версии Odoo на более новую поддерживаемую версию. Сервис обновления Odoo преобразует структуру данных, после чего ваша команда тестирует результат до реального перехода.
Сервис обновления не предусматривает откат на более старую версию, переход между Community и Enterprise, смену типа хостинга или миграцию из другой ERP-системы. Каждая из этих задач — отдельный проект.
Как часто нужно обновляться в зависимости от типа хостинга
- Odoo Online: обновление до новой основной версии обязательно каждые два года. Odoo уведомляет об этом за несколько недель, проводит фоновое тестовое обновление и, если вы ничего не предпримете до установленного срока, обновляет базу данных автоматически.
- Odoo.sh: после окончания трёхлетней поддержки вашей версии у вас есть ещё два года, чтобы завершить обновление, и платформа уведомит вас, когда оно станет обязательным.
- On-premise: можно оставаться на одной версии сколь угодно долго, но это не рекомендуется. Чем меньше разрыв между версиями, тем проще и дешевле обновление.
Семь шагов официального процесса
- Шаг 1: запросите обновлённую тестовую базу данных.
- Шаг 2: обновите исходный код пользовательских модулей, если они есть.
- Шаг 3: тщательно протестируйте обновлённую базу данных.
- Шаг 4: сообщите в службу поддержки Odoo обо всех проблемах, выявленных при тестировании, указав этап миграции.
- Шаг 5: когда будете уверены в результате, спланируйте обновление рабочей базы.
- Шаг 6: запросите обновление рабочей базы. На время обновления база данных недоступна.
- Шаг 7: сообщите в службу поддержки Odoo обо всех проблемах, выявленных после запуска, указав этап продакшена.
Шаг 1: запросите обновлённую тестовую базу данных
В Odoo Online откройте менеджер баз данных, выберите базу, нажмите «Управление», а затем «Обновить». Выберите целевую версию, укажите адрес электронной почты для уведомлений, оставьте цель «Тест» и подтвердите. По завершении процесса вы получите письмо со ссылкой на тестовую базу данных.
В Odoo.sh откройте вкладку Upgrade и запустите обновление на staging-ветке. Последняя ежедневная резервная копия рабочей базы отправляется на платформу обновления, а ветка переходит в специальный режим, в котором каждый новый коммит восстанавливает обновлённую резервную копию и обновляет ваши пользовательские модули. Журнал обновления доступен в файле upgrade.log в папке логов обновлённой staging-сборки.
В варианте on-premise запустите официальный скрипт обновления на сервере базы данных с параметром тестирования, именем базы данных и целевой версией, как указано в документации Odoo по обновлению. Серверу нужен сетевой доступ к серверам обновления. Возвращённая копия не содержит хранилище файлов (filestore), поэтому перед тестированием объедините полученную папку filestore с filestore рабочей базы.
После каждого успешного обновления к письму с подтверждением прикладывается отчёт об обновлении; он также публикуется в Discuss для администраторов. Внимательно изучите его: в нём перечислено, что изменилось и что требует внимания.
Шаг 2: обновите пользовательские модули
Базу данных с пользовательскими модулями нельзя обновить, пока у этих модулей нет версии, совместимой с целевым выпуском. Начинайте эту работу параллельно с запросом тестовой базы.
- Заморозьте разработку: прекратите добавлять функции и принимайте только исправления ошибок до завершения обновления.
- Сравните свои доработки с новой версией и удалите всё, что Odoo теперь предоставляет в стандартной поставке.
- Установите каждый модуль в пустую базу данных целевой версии и исправьте все ошибки и предупреждения.
- Проверьте представления, шаблоны писем, отчёты, серверные и автоматические действия и вычисляемые поля, а там, где это полезно, добавьте автоматические тесты.
- Напишите скрипты обновления для изменений в данных: переименованных моделей, полей и внешних идентификаторов, восстановления данных из удалённых моделей и пересчёта полей.
Скрипты обновления размещаются в модуле в папке upgrades или migrations, а внутри неё — в папке с полным номером версии модуля, например 19.0.2.0. Имя каждого файла начинается с pre-, post- или end-, что определяет момент его запуска: до загрузки модуля, после обновления модуля или после обновления всех модулей. В каждом файле определяется функция migrate, которая получает курсор базы данных и установленную версию.
В Odoo.sh платформа запускает эти скрипты при обновлении ваших модулей. В варианте on-premise вы восстанавливаете обновлённый дамп и обновляете модули с помощью odoo-bin с параметром обновления. В Odoo Online установка пользовательских модулей на Python невозможна, поэтому доработки там необходимо выполнять в Studio.
Шаг 3: протестируйте обновлённую базу данных
Тестовые базы данных нейтрализуются для защиты рабочей среды: запланированные действия отключаются, серверы исходящей почты заменяются фиктивным, платёжные провайдеры и службы доставки переводятся в тестовый режим, а синхронизация с банком выключается. Если вам нужно её протестировать, запросите у своего банковского провайдера учётные данные для тестовой среды (sandbox).
- Убедитесь, что представления, активные в рабочей базе, остались активными после обновления.
- Распечатайте счета, коммерческие предложения, накладные на доставку и другие отчёты и сравните их с рабочей базой.
- Создайте и отредактируйте записи, проверьте фильтры поиска, шаблоны писем и экспорт.
- Проверьте страницы сайта и пройдите основные бизнес-процессы от начала до конца, например «предложение — счёт — оплата» и «закупка — поступление — счёт поставщика».
- Протестируйте внешние интеграции, такие как API и EDI, автоматические действия, серверные действия и сквозные процессы между приложениями.
- Сравните ключевые показатели с рабочей базой: стоимость запасов, остатки по счетам, открытую дебиторскую и кредиторскую задолженность.
Дайте каждому отделу письменный сценарий тестирования и назначьте ответственного, фиксируйте каждый результат. Тест, который не записан, не проводился.
Шаг 4: сообщите о проблемах до запуска
Сообщайте обо всех расхождениях и ошибках в тестовой базе данных в службу поддержки Odoo через страницу поддержки, выбрав этап миграции. Odoo исправит скрипты обновления, а вы запросите новую тестовую базу данных, чтобы убедиться в исправлении. Повторяйте, пока результаты не станут чистыми.
Шаг 5: спланируйте обновление рабочей базы
- Выберите время с низкой активностью, поскольку во время обновления база данных недоступна.
- Незадолго до запуска запросите свежую тестовую базу данных и проведите полную генеральную репетицию накануне.
- Сообщите пользователям о периоде простоя и прекратите ввод данных до начала обновления.
- Сделайте резервную копию и проверьте её, а также подготовьте короткий чек-лист на первые часы после запуска.
Шаг 6: запросите обновление рабочей базы
В Odoo Online повторите запрос, как для тестовой базы, но укажите цель «Продакшн». После завершения вернуться к предыдущей версии будет невозможно.
В Odoo.sh обновление рабочей базы начинается, когда в production-ветку отправляется новый коммит, поэтому обновлённая база данных и обновлённые пользовательские модули развёртываются одновременно. Если что-то пойдёт не так, платформа автоматически откатит обновление, а при успехе сохранит резервную копию, сделанную перед обновлением.
В варианте on-premise запустите тот же скрипт обновления, но с параметром продакшена вместо тестирования. Изменения, внесённые в рабочую базу после отправки базы данных, не попадут в обновлённую базу. Объедините filestore перед запуском новой версии.
Шаг 7: поддержка после запуска
В первые дни обеспечьте доступность ключевых пользователей, отслеживайте запланированные действия, электронную почту и интеграции по мере их повторного включения и сообщайте о любых проблемах в службу поддержки Odoo, указав этап продакшена.
Что включает сервис обновления для клиентов Enterprise
В Odoo Enterprise обновление до последней версии входит в подписку вместе с поддержкой по расхождениям, выявленным в обновлённой базе данных. Это касается стандартных приложений, доработок в Studio при условии, что Studio и соответствующая подписка активны, а также доработок, на которые оформлена подписка на сопровождение доработок.
Сервис не включает очистку существующих данных или настроек, обновление собственных и сторонних модулей без договора на сопровождение, а также обучение работе с новой версией. На пользователей Community этот сервис не распространяется; обычно они используют проект с открытым исходным кодом OpenUpgrade, который поддерживает Odoo Community Association.
Практические советы из опыта проектов обновления
- Очистите основные данные перед обновлением: дубли контрагентов, неиспользуемые товары и архивные настройки замедляют тестирование.
- Удалите неиспользуемые модули до запроса тестовой базы, чтобы при обновлении пришлось преобразовывать меньше данных.
- В плане проекта закладывайте переход по одной версии за раз, даже если сервис обновляет базу сразу до целевой версии.
- Ведите перечень всех доработок с ответственными и по каждой примите решение: оставить, заменить стандартной функцией или отказаться.
- Никогда не пропускайте генеральную репетицию: большинство сюрпризов при запуске связано с данными, введёнными после последнего теста.
Чем может помочь 1CBMS
1CBMS планирует и ведёт проекты обновления Odoo от начала до конца: оценивает вашу текущую версию и доработки, переносит пользовательские модули, пишет сценарии тестирования для каждого отдела, работает с обращениями в службу поддержки Odoo и контролирует запуск рабочей базы. Свяжитесь с нами через сайт, чтобы проанализировать путь обновления вашей системы.