Как автоматически обновить тестовую среду

Дмитрий Миронов

руководитель Направления практики разработки и сопровождения программного обеспечения

Основное влияние на тестовую среду банка оказывает релизный цикл. В 2022 году у нас было десять крупных релизов — и множество маленьких между ними. Поэтому каждую тестовую среду переключали с одной версии на другую 15–20 раз.

В процессе важно, чтобы все системы обновились до правильных версий. Иначе при тестировании сложных бизнес-процессов могут возникать дефекты, которые задержат внедрение задач. При этом системы могут быть разными:

• коробочные системы с банковской кастомизацией;
• системы, которые разрабатывают вендоры, передавая готовые дистрибутивы;
• системы, разработанные внутри банка.

Одни из них используются десятилетиями, другие — только внедряются.

Из-за этого разнообразия и CI/CD-пайплайны могут сильно отличаться. И обновлять системы вручную — или даже автоматизированно, запуская вручную только обновления отдельных систем, — долго и накладно. Чтобы сделать этот процесс эффективным, нужно научиться обновлять среды полностью автоматически. В этом помогает грамотная автоматизация.

Что нужно знать, чтобы автоматизировать обновление среды

Раньше мы не имели однозначных данных о том, какие системы изменяются при выполнении конкретной задачи. У каждой команды разработки были свои эпики в Jira, кто-то из них мог изменить сразу несколько систем и сообщить об этом только в инструкции по обновлению. Понятно, что использовать такую информацию для автоматизации было сложно.

Во-первых, нужно формализовать информацию об инфраструктуре в CMDB (Configuration Management Database): базы данных, сервера, тестовые среды. Главное — прописать чёткий список систем — конфигурационных единиц (КЕ), — с указанием, в каких тестовых средах они находятся.

Каждая КЕ должна иметь чёткие границы, чтобы не возникало перекрытий или пропусков отдельных компонентов. А каждая тестовая среда — конкретный состав и версию релиза, которому она соответствует в данный момент. Версии всех систем должны этому релизу соответствовать.

Чтобы сделать информацию о тестовых средах, системах и версиях более доступной мы сделали специальный сервис «Версии систем». Он автоматически собирает информацию о версиях тестовых сред и систем для отображения или предоставлении по API.

Во-вторых, нужно понимать какие системы должны быть обновлены в каждом релизе. Если в каждом Jira-эпике разместить информацию о системе и релизе, в который входит задача, то можно автоматически собрать список всех систем, которые меняются в релизе.

Мы сделали небольшую доработку Jira. И теперь при создании запроса на обновление среды автоматически создаются отдельные запросы на обновление каждой системы, которая поменялась в релизе и присутствует в среде.

В-третьих, нужно знать, как запустить обновление каждой системы в целевой среде.

Если автоматизации обновления в системе недостаточно, то запрос на установку попадает к конкретному специалисту, который обновляет систему.

Но целевой вариант предполагает использование скриптов обновления полностью в автоматическом режиме. Должно быть достаточно сообщить скрипту, какую среду нужно обновить, и целевой релиз обновления. Скрипт же должен самостоятельно разобраться со всем остальным — найти правильный дистрибутив нужной версии, обновить все компоненты до целевой версии, запустить систему, если нужно и проверить корректность обновления.

Удобно, когда скрипты обновления запускаются единообразно.

Процесс обновления тестовой среды

Благодаря доработкам обновление тестовой среды выглядит так:

1. Лидер продуктовой команды или владелец тестовой среды создаёт в Jira запрос на обновление, в котором указывает название среды и целевой релиз.
2. Jira создаёт отдельные запросы для каждой системы и назначает ответственных специалистов.
3. Скрипт обрабатывает запросы настроенных систем, запускает обновление и закрывает запросы по окончании обновления.
4. Запросы по некоторым системам обрабатываются вручную.

Инициатор может отслеживать прогресс обновления.

Принципы построения CI/CD-pipeline

Давайте теперь спустимся на уровень ниже и посмотрим, как должны быть устроены CI/CD-pipeline для системы, чтобы соответствовать такому подходу. Будем отталкиваться от свойств дистрибутива.

Дистрибутив должен быть:

1. Системным, то есть должен содержать необходимые артефакты для обновления всех компонентов системы. Не должно быть такого, что какой-то из необходимых компонентов — например, sql-скрипты для базы данных — обновлялся отдельно вручную.
2. Кумулятивным, то есть содержать все изменения, а не только дельту от предыдущего дистрибутива/версии/релиза. Без кумулятивности сложно автоматизировать правильную последовательность установки в разные по состоянию среды. Эта проблема возникает обычно на бэковых системах, построенных вокруг баз данных, или на специфических движках. В таких случаях довольно сложно сделать кумулятивные сборки, но к этому нужно стремиться.
3. Версионным. Каждая сборка должна помечаться уникальной версией, которая обычно состоит из порядкового номера сборки и ещё какого-либо признака более общей версионности — мы используем номер релиза. Версия системы выглядит так: [Номер_релиза].[Номер_спринта].[Номер_сборки], например, 112.0.0.123, где 112.0 — это номер релиза, 0 — если спринты не используются, 123 — номер сборки. Привязка к номеру релиза имеет ключевое значение. Именно по ней определяется принадлежность дистрибутива к релизу и формализуется его поиск.
4. Сохраняться в хранилище артефактов, в нашем случае в Nexus. Структура хранения тоже должна быть формализована так, чтобы всегда можно было найти нужные артефакты по номеру версии или последнюю успешную сборку для системы-релиза.
5. Средонезависимым. Дистрибутив не должен содержать никаких средозависымых параметров. Все средозависимые параметры должны содержаться в inventory-файлах скрипта развёртывания, в дополнительных хранилищах секретов.

Сборочный скрипт приложения или CI-pipeline должен быть устроен так, чтобы в результате порождать дистрибутив, соответствующий всем этим свойствам.

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

Итоги внедрения скрипта обновления тестовой среды

Раньше мы обновляли среды в течение трёх дней, теперь тратим на это меньше дня, не завися от экспертов по каждой системе и не отвлекая их.

В планах сделать процесс полностью автоматическим и сократить время обновления до нескольких часов – осталось только доавтмоатизировать несколько систем и вписать их в общий процесс.