Выпуск новой версии шаблона и обновление микросервисов

Инструкция описывает выпуск версии 1.1.0 шаблона go-service и обновление микросервисов, созданных из версии 1.0.0. В новой версии меняется CI и добавляется файл .dockerignore. В результате в репозиториях микросервисов открываются запросы на слияние с изменениями шаблона, а после их принятия версия шаблона микросервисов в каталоге становится 1.1.0.

Инструкция продолжает пример «Создание и публикация шаблона микросервиса».

Перед началом работы

Для выполнения инструкции подготовьте:

• шаблон go-service версии 1.0.0 в реестре шаблонов и микросервисы, созданные из него;
• процесс «Обновить микросервис из шаблона», привязанный к шаблону в блоке «Действия по шаблонам» правил маппинга;
• разрешение edit:template-registries для изменения настроек реестра шаблонов.

Подготовка новой версии

Внесите изменения в пакет:

1. Измените .gitlab-ci.yml, например добавьте задачу тестирования.

2. Создайте файл .dockerignore.

3. Добавьте .dockerignore в список update.addIfMissing манифеста:

   update:
     strategy: selective_additive
     overwrite:
       - .gitlab-ci.yml
       - deploy/**
     addIfMissing:
       - .editorconfig
       - .dockerignore

4. Проверьте пакет командой ddp-template lint ./go-service.

Файлы, которые не входят в update.overwrite и update.addIfMissing, например cmd/{{ .slug }}/main.go, при обновлении не изменяются: изменения разработчиков в этих файлах сохраняются.

Проверка обновления на копии микросервиса

Перед публикацией проверьте, какие файлы изменит обновление в существующем микросервисе. Скопируйте раздел values lock-файла .ddp/template.lock.yaml микросервиса в файл service-values.yaml и отрисуйте новую версию с имитацией стратегии обновления:

ddp-template render ./go-service \
  --values ./service-values.yaml \
  --use-overwrite \
  --output ./render-out

Значения параметров с аннотацией x-ddp-from в lock-файле уже записаны, поэтому команда отрисует файлы с данными микросервиса.

Публикация и синхронизация

Опубликуйте версию 1.1.0 и загрузите её в портал:

1. Выполните публикацию:

   ddp-template publish ./go-service --version 1.1.0 \
     --registry registry.example.com \
     --repository-prefix ddp-templates

2. Перейдите в раздел «Администрирование» → «Интеграции» → «Шаблоны» → «Запуски синхронизации», нажмите «Синхронизировать» и дождитесь статуса «Успех».

3. На вкладке «Шаблоны» убедитесь, что тег «последняя» отмечает версию 1.1.0.

Ручное обновление

Обновите один микросервис кнопкой в карточке:

1. Откройте главную → «Микросервисы» и выберите микросервис, созданный из go-service.
2. На вкладке «Справка» в блоке «Доступна версия 1.1.0» нажмите «Обновить».
3. В окне «Запустить процесс» нажмите «Запустить» и дождитесь завершения процесса в панели «Мои активности».
4. Откройте проект микросервиса в GitLab и найдите запрос на слияние Upgrade go-service to 1.1.0 из ветки ddp/template-upgrade-1.1.0.

Запрос на слияние содержит изменённый .gitlab-ci.yml, новый .dockerignore и lock-файл с версией 1.1.0. Если .dockerignore уже был в репозитории, он не изменяется.

Примите запрос на слияние. Через интервал сверки версии поле «Версия» в карточке микросервиса примет значение 1.1.0, а блок «Доступна версия» исчезнет. Сверка версии выполняется, если в настройках реестра задан пользователь автоматизации; без него версия в каталоге обновится при следующем запуске процесса обновления.

Автоматическое обновление

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

Настройте пользователя автоматизации:

1. Создайте сервисного пользователя, например template-bot, и заполните в его профиле токен и имя пользователя GitLab.
2. Перейдите в раздел «Администрирование» → «Интеграции» → «Шаблоны» → «Настройки».
3. Выберите пользователя в поле «Пользователь автоматизации».
4. Задайте «Лимит очереди обновлений» не меньше числа микросервисов шаблона, например 20, и сохраните настройки.

Включите автоматическое обновление для микросервисов: откройте сущность микросервиса в каталоге и установите параметр «Политика обновления шаблона» в значение «Ревью автоматически».

После публикации и синхронизации следующей версии, например 1.2.0, портал запустит процесс обновления для каждого микросервиса с политикой «Ревью автоматически» от имени пользователя автоматизации. Запросы на слияние создаются так же, как при ручном обновлении.

Автоматическое обновление не запускается для микросервиса, если в его репозитории открыт запрос на слияние с обновлением до предыдущей версии. Примите или закройте такой запрос на слияние и обновите микросервис кнопкой «Обновить».

Конфликты и ручные изменения

Стратегия selective_additive перезаписывает .gitlab-ci.yml и файлы deploy/** целиком. Если разработчики изменили эти файлы в репозитории, их изменения будут заменены версией шаблона в запросе на слияние; проверьте изменения перед принятием.

Чтобы сохранить изменения разработчиков в файлах шаблона, задайте для микросервиса стратегию merge:

1. Откройте сущность микросервиса в каталоге.
2. Установите параметр «Стратегия обновления шаблона» в значение merge.
3. Запустите обновление кнопкой «Обновить».

При стратегии merge портал сливает изменения шаблона с изменениями в репозитории. Если изменения пересекаются, обновление завершается ошибкой merge_conflict со списком файлов, и репозиторий не изменяется. В этом случае верните стратегию selective_additive, запустите обновление и перенесите изменения разработчиков в ветку запроса на слияние вручную.

Удаление файлов из шаблона

Обновление не удаляет файлы. Если в новой версии шаблона файл удалён или переименован, старый файл остаётся в репозиториях микросервисов.

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