Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Приветствуем тебя, читатель Хабра. Возможно, тема непрерывной поставки и интеграции микросервисов покажется немного избитой, ведь сегодня любой идальго путем нехитрых манипуляций при помощи обучающих видео может натравить Jenkins/TeamCity/GitLab (нужное подчеркнуть) на свой репозиторий и начать называть себя испанским доном. Вся соль, на наш взгляд, в тех шагах сборки, которые он для себя определит и какой смысл в них вложит. Не менее чем сама сборка важен процесс автоматизации контроля качества. В этой статье мы расскажем вам о том, что в этом вопросе сделали для себя мы, команда разработчиков всех розничных фронтов банка «Открытие».
В предыдущей статье мы поведали о том, как построили конвейер, который непрерывно поставляет релизы на продуктивную среду без страха разломать ее. Одним из факторов, позволяющих нам это сделать, является контроль обратной совместимости через версионирование контрактов, который мы описали в статье. Но этого далеко не достаточно. Важнейшими шагами сборки мы считаем прохождение автоматизированных и ручных этапов контроля качества, которые и позволяют нам поставлять изменения быстро и без страха.
Рассмотрим конкретный пример.
В момент, когда триггерится сборка, например, когда разработчик сделал коммит в свою ветку, запускается процесс, который выполняется специально написанными скриптами и утилитами. Этот процесс состоит из нескольких обязательных шагов. Ошибка в любом из них приводит к полному падению всей сборки. Ну и, само собой разумеется, шаги расположены в таком порядке, чтобы сужать воронку потенциальных проблем. Если Quality Gate предыдущего этапа не пройдет, то на проверку следующего уже можно не тратить ресурсы.
Основные Quality Gates, которые встроены в наш pipeline:
Сборка сервиса:
a. Проверка наличия конфигурации корректного формата;
b. Проверка стандартов оформления кода;
c. Проверка на необходимое покрытие Unit-тестами;
d. Генерации и публикации контрактов (контроль обратной совместимости).Запуск Beta-тестов.
Обязательный code-review.
Сканирование на уязвимости.
Проверка наличия конфигурации корректного формата
Для всех сервисов существует универсальный формат конфига. Для унификации в этом процессе мы даже написали собственную тулзу. Из универсального стандартизированного YAML-файла нашего конфига она генерит другие конфиги в различных форматах, которые понятны утилитам и скриптам, участвующим в дальнейших процессах. Если нет правильного конфига – дальше можно ничего не смотреть.
Проверка стандартов оформления кода
Наши разработчики – граммар-наци в своих языках. Не станем рассказывать, что такое codestyle. Скажем лишь, что с ростом количества участников проекта, которые имеют доступ к кодовой базе, требования к унификации кода приобретают все больший вес.
Проверка на необходимое покрытие Unit-тестами
Проверка выполнения тестами выполняется в два этапа:
Проверяется наличие Unit-тестов и их успешное выполнение.
При помощи утилиты coverlet проверяется, что сервис имеет необходимый процент покрытия. Сейчас мы работаем над тем, чтобы покрытие было не ниже 80%.
Генерации и публикации контрактов (контроль обратной совместимости)
На этом шаге запускаются:
Генерация и публикация контрактов к нашему сервису, если это необходимо. Механизм описан тут, в разделе «Публикация контрактов»;
Создание docker-образов;
Генерация при помощи специальной утилиты параметров в виде Helm чарта.
Запуск Beta-тестов
Одним из главных этапов является запуск Beta-тестов, об этом мы расскажем чуть более подробно.
Полный прогон всех Beta-тестов на любой коммит выедал бы все наши ресурсы и стоил бы слишком дорого. Поэтому мы явно определяем, какие именно Beta-тесты необходимо прогнать для того или иного сервиса через механизм Dependencies и Triggers в TeamCity. Такие зависимости выставляются вручную в процессе разработки самих Beta-тестов. Для этого могут быть использованы вспомогательные инструменты автоматической картографии.
и выглядят они примерно так:
На этом шаге в дело вступает специальная внутренняя утилита SRV-Deploy, которая заслуживает отдельной статьи. С помощью этой утилиты мы разворачиваем стенды для Beta-тестов различной конфигурации в зависимости от разрабатываемой задачи. В данный момент одной из ее возможностей является проброс build-статусов о прохождении Beta-тестов в Bitbucket к конкретному коммиту (pull-request-у). Используя стандартный функционал Bitbucket, мы можем на любой проект для pull-request-ов создать правило, которое не будет разрешать производить Merge, пока не будут пройдены все Beta-тесты.
Как видно на изображении выше, кнопка Merge не активна, пока не выполнены все требования к PR, в том числе «зеленые» Beta-тесты.
Обязательный code-review
Очевидно, что у нас есть code-review pull-request-ов. При помощи стандартного функционала Bitbucket за каждым сервисом закреплена группа владельцев. Обязательно, чтобы PR посмотрело не меньше определенного количества разработчиков, среди которых обязательно должен быть кто-то из группы владельцев кода. Помогают разработчикам результаты работы различных популярных статических анализаторов, которые вы наверняка знаете (не будем их тут рекламировать).
Текущий этап проходит параллельно с предыдущим. Строго говоря, это не автоматический, а ручной процесс. Но конвейер настроен так, что без успешного прохождения этого этапа код не релизится.
Сканирование на уязвимости
Последним обязательным этапом является финальное сканирование артефактов, которые поставляются на продуктивную среду специальными сканерами безопасности. В случае, если какие-либо угрозы и уязвимости не выявлены, артефакт сборки считается готовым к поставке, которая производится специальной ролью Release-manager.
Вот такой он, наш конвейер. Процесс непрерывно совершенствовался и менялся в течение нескольких лет и по сей день находится в активной фазе развития. Много скриптов и некоторые вспомогательные утилиты пришлось писать самостоятельно. Надеемся, наш рассказ будет кому-то полезен и пойдет в помощь при создании и совершенствовании своих процессов поставки.
Для доступности темы максимально широкой аудитории основные шаги осознанно описаны без глубокого погружения в технику. Делайте заявки на технические подробности в комментариях.
