Привет, Хабр! Меня зовут Денис Коробков, я руковожу отделом DevOps по розничному направлению в ПСБ. В своей статье расскажу, как мы внедрили релизную платформу, чтобы выстроить и автоматизировать релизный процесс.
До недавнего времени он был практически полностью ручным. Разработчики согласовывали участие в релизе по почте, релиз-менеджеры вручную собирали общий список сервисов и индивидуально переносили каждую сборку между стендами. Потом в компании изменился подход к разработке: розничный блок, в том числе и микросервисная платформа, перешёл на Trunk Based Development (далее TBD). В связи с этим нам нужно было уменьшить ручные шаги и сократить время релизного цикла.
Релизная платформа позволила нам уйти от ручной работы там, где это было возможно, и сэкономила довольно много времени. Расскажу, что она умеет, как устроена изнутри, и приведу цифры — где и на чём мы снизили затраты по часам. Надеюсь, будет интересно почитать DevOps-ам и вообще всем, кто имеет отношение к релизному циклу. Прошу под кат.
Для начала: что такое релизный процесс? Это цикл этапов подготовки, тестирования, стабилизации и выпуска ПО или его обновлений для конечных пользователей.
Как это было устроено раньше
До внедрения релизной платформы наш процесс был почти полностью ручным. Что было довольно тяжко.
Разработчик письмом запрашивал возможность включить сервис в релиз.
По каждому сервису вручную проверялся список задач к релизу.
Срезы (перенос сборок) от стенда к стенду выполнялись индивидуально для каждого сервиса.
Проверки SAST-анализатора терялись среди множества пайплайнов.
Полный список сервисов в релиз фиксировали руками — все разработчики писали письма, которые вручную сводились на страницу в базе знаний.
Запуск установки на продуктовый контур также делался вручную, согласно этому списку.
И как стало
Сейчас я вкратце расскажу, как всё выглядит после внедрения релизной платформы, и дальше представлю всё подробно. Итак, теперь:
Разработчик подаёт Merge Request (MR) в релизной платформе.
Автоматически выполняется проверка задач к релизу.
Срез всего состава релиза делается нажатием одной кнопки.
Проверка SAST-анализатора запускается централизованно в платформе.
Список сервисов к релизу генерируется автоматически в системе контроля версий (AhCode) Pages.
Установка на прод производится запуском одного пайплайна.
Что представляет из себя релизная платформа
Это специальный репозиторий в Ahcode, который помогает собрать, зафиксировать и провести релиз. Для каждого проекта создаётся свой репозиторий, чтобы не было путаницы. Сейчас у нас есть несколько таких платформ: самая большая — для ПСБ РБС, а также для Расчётного банка, Цифрового рубля, OCRM, ACRM и других систем.
Как я уже писал выше, причина её появления в том, что наш розничный блок, включая микросервисную платформу, перешёл на TBD. Нам нужно было уменьшить количество ручных шагов и требовалось сократить время всего релизного цикла.
На всякий случай уточню для справки, что такое TBD. Trunk Based Development — подход, при котором ведётся одна основная ветка (master/trunk). Все изменения мержатся прямо в неё, и на основе коммитов автоматически создаются теги. Именно из этих тегов происходит раскатка на стенды и в прод.
Что это нам даёт?
Нет лишних мердж-реквестов. Раньше была цепочка: из master в staging, из staging в load_testing, потом в preprod и prod. Это занимало уйму времени. Теперь у нас только один MR — в мастер.
Меньше нагрузка на машины сборки. Сейчас у нас единая сборка на все контуры. Раньше при каждом переливе кода из ветки в ветку мы его пересобирали — машины просто не вывозили такой нагрузки.
Полная прозрачность. Всегда понятно, какой тег установлен на каком контуре. Исключены ситуации, когда в какой-то ветке появляется «лишний» код.
Идём дальше.
Что умеет наша релизная платформа
Фиксирует состав релиза — как для проектов на GitLab Flow (у нас осталось не так много сервисов, где используется GitLab Flow, но они есть), так и для TBD.
Автоматически проверяет список задач к релизу для каждого репозитория.
Запускает проверку SAST-анализатора для версии, указанной в json-файле.
Проверяет готовность сервиса к релизу (соединения, сертификаты и так далее).
Автоматически создаёт страницу (Pages) с полной информацией о предстоящем релизе.
Выполняет срез на любой стенд «в одну кнопку».
Как это работает изнутри
Каждый релиз версионируется. Релиз-менеджер создаёт под каждый релиз ветку с идентичным названием версии релиза. Разработчики подают MR в эту ветку с уже заполненным json-файлом, где указывают ссылки на их репозиторий и их тэг.
Далее при формировании MR создаётся пайплайн, где производятся проверки задач в системах управления задачами, а также запускается сканирование кода на уязвимости.
Выводим итог, где все эти проверки и результат выполнения job по проверке задач, где сравнивается тег, который стоит в продакшене, и тот тег, который разработчик подал непосредственно в релиз.
Между ними разработчик коммитил и в нём есть список задач. Система анализирует коммиты и проверяет, что все задачи закрыты в нужных статусах. Всё это делается автоматизированно для большого количества сервисов.
При принятии MR запускается новый пайплайн, который делает следующее:
init_stand (manual): устанавливает на выбранный стенд все сервисы из релиза (сервисов может быть 100–200, наш рекорд — 308 микросервисов за раз).
SAST-анализатор: запускает сканирование по всем тегам.
xlsx_file: формирует Excel-файл со списком всех репозиториев и их тегов.
release_checker: автоматически проверяет готовность каждого сервиса.
pages: генерирует итоговую страницу релиза.
Установка на preprod и prod идёт из отдельного, защищённого репозитория (доступ есть только у DevOps). Туда передаётся ссылка на версию релизной платформы. Пайплайн разбит на CI и CD этапы, чтобы обеспечить сборку до релиза. В автоматизации учтены приоритеты установки, так как существуют зависимые сервисы, домены с разной критичностью и другие факторы.
На автосгенерированной странице релиза видны направления, домены, сервисы, заявители, ветки/теги, список задач в таск-трекере, готовность к релизу и кликабельные статусы установки на preprod/prod с временем выполнения.
Сколько времени мы сэкономили
Цифры большие, но объёмы у нас соответствующие: на микросервисной платформе около 450 сервисов, в этом году планируется ещё примерно 300.
Итого: раньше все ручные проверки, мержи и согласования отнимали 1540 минут (более 25 часов) условного человеческого времени на крупный релиз. Сейчас автоматизированный процесс занимает около 6 минут чистого времени работы системы.
Конечно, мы не отказались от ручного труда там, где он необходим. Но выстроили процесс так, чтобы передать системе всё, что можно было доверить ей без рисков. Это позволило высвободить сотни часов работы разработчиков и релиз-менеджеров.
Вдобавок мы снизили количество человеческих ошибок при срезах и установках, а заодно повысили прозрачность — теперь все участники релизного процесса в реальном времени видят статус и состав релиза.
На этом, пожалуй, всё. Спасибо за то, что прочитали статью. Если у вас есть вопросы или вы хотите поделиться своим опытом — буду рад пообщаться в комментариях!