Процедура обновления Global ERP

Процедура обновления Global ERP#

1. Общие положения#

Процедура описывает порядок, состав, сроки и условия выполнения обновлений программного комплекса Global ERP — как базовой платформы, так и прикладных модулей, поставляемых в рамках проекта внедрения. Процедура утверждена вендором и применяется на всех проектах, где используется Global ERP.

2. Состав обновления#

Обновление может включать следующие компоненты:

  • Образы Kubernetes — контейнеры инфраструктурных компонентов;

  • Сервер приложений — обновление версии платформы и сервисных модулей;

  • Образ прикладного решения — сборка новой версии проектного кода и расширений;

  • Релизы конфигурации — поставочные данные и настройки.

Каждый компонент может обновляться независимо или в составе комплексного релиза.

3. Подход к обновлению#

Обновление выполняется по многоступенчатой модели с обязательным прохождением промежуточных сред. Процедура включает следующие этапы:

  1. DEV (разработка) – сборка коробочного решения с проектными расширениями и выполнение простейших функциональных тестов;

  2. TEST / QA – установка версии на тестовый стенд, проведение регрессионных и интеграционных тестов (автоматизированных и ручных);

  3. PRE-PROD / UAT – окончательное тестирование обновлённого решения с учётом проектных расширений на продуктивных данных;

  4. PROD – установка в промышленный контур после утверждения заказчиком.

Все обновления проходят предварительную проверку на совместимость версий компонентов (ядро, СУБД, окружение).

4. Условия и режимы обновления#

Поддерживаются два режима обновления:

  • Стандартный (Stop-and-Upgrade) — выполняется при отсутствии активных сессий, с монопольным доступом к базе данных;

  • Мягкий (Rolling Update) — используется для минимизации простоя системы. Поддерживает перекрытие версий, автоматическое завершение блокирующих сессий и обновление контейнеров без полной остановки кластера.

Обновления базы данных выполняются по принципу expand/contract (сначала добавление новых структур, затем удаление устаревших). Файловые ресурсы и контейнеры обновляются средствами CI/CD и Kubernetes.

5. Периодичность и сроки проведения#

  • Релизы платформы выпускаются ежемесячно;

  • Обновления контейнерных образов — раз в полгода;

  • Прикладные решения обновляются по мере готовности модулей (в среднем раз в квартал).

Сроки внедрения конкретного обновления на стороне заказчика согласовываются индивидуально и фиксируются в плане релизов.

6. Ответственность и контроль качества#

  • Обновление выполняется обученными специалистами заказчика, а также при необходимости техническими специалистами вендора или сертифицированного партнёра по платформе Global ERP;

  • Все действия фиксируются в журналах обновлений;

  • Перед установкой каждой версии выполняется резервное копирование базы данных и конфигурации;

  • При необходимости возможен откат к предыдущей версии.

7. Документирование и сопровождение#

По каждому релизу формируется комплект сопроводительной документации:

  • Release Notes — описание изменений, новых функций и исправлений ошибок;

  • Инструкция по установке и обновлению;

  • Инструкция по откату (Rollback).

Документация публикуется на внутреннем портале и сопровождается версиями в системе контроля версий (GitLab).

8. Принятие обновлений#

После установки выполняется приёмочное тестирование на стороне заказчика. По итогам подписывается акт приёмки обновления или формируется список замечаний, подлежащих исправлению в ближайшем релизе.

9. Сроки и порядок проведения обновлений#

Длительность и график проведения обновлений зависят от состава релиза и объёма данных:

  • Платформенные обновления (сервер приложений, контейнеры, конфигурация) выполняются, как правило, не более 20 минут, некоторые не требуют остановки работы пользователей;

  • Обновление образа прикладного решения выполняется в среднем за 4 минуты, включая копирование данных по сети и скрипты обновления базы данных.

  • Обновления базы данных (структурные миграции, преобразование данных) занимают до двух минут, долгие скрипты миграции выполняются в двухфазном режиме:

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

    • После завершения скриптов миграции обновление новым решением с окончательным переходом на новую структуру данных.

Обновления планируются заранее и согласовываются с ответственными представителями заказчика. За 10 рабочих дней до установки направляется уведомление с перечнем изменений, планом обновления и оценкой влияния на систему.

Проведение обновлений осуществляется в регламентное окно обслуживания (в вечернее или ночное время) с учётом требований заказчика к доступности системы. При использовании режима Rolling Update обновления могут выполняться без полной остановки сервисов.

Содержание