Перейти к основному содержанию
`Ctrl`+`K`

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

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

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

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

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

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

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

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

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

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

Предупреждение

Не допускается совместное обновление кластерных утилит и прикладного решения или сервера приложений. Подобная практика приводит к нарушениям в работе системы: возможны сбои в работе утилит, что вызывает некорректный старт сервера приложений и выход из строя прикладного решения.
Также в случае ошибок существенно усложняется диагностика первопричины из-за одновременного обновления нескольких компонентов.

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

1. Обновление кластерных утилит.

2. Проведение тестирования после обновления по контрольному чек-листу.

3. После успешного тестирования — обновление прикладного решения или сервера приложений.

## 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 обновления могут выполняться без полной остановки сервисов.