Приветствуем тебя, читатель Хабра. Возможно, тема непрерывной поставки и интеграции микросервисов покажется немного избитой, ведь сегодня любой идальго путем нехитрых манипуляций при помощи обучающих видео может натравить Jenkins/TeamCity/GitLab (нужное подчеркнуть) на свой репозиторий и начать называть себя испанским доном. Вся соль, на наш взгляд, в тех шагах сборки, которые он для себя определит и какой смысл в них вложит. Не менее чем сама сборка важен процесс автоматизации контроля качества. В этой статье мы расскажем вам о том, что в этом вопросе сделали для себя мы, команда разработчиков всех розничных фронтов банка «Открытие».
В предыдущей статье мы поведали о том, как построили конвейер, который непрерывно поставляет релизы на продуктивную среду без страха разломать ее. Одним из факторов, позволяющих нам это сделать, является контроль обратной совместимости через версионирование контрактов, который мы описали в статье. Но этого далеко не достаточно. Важнейшими шагами сборки мы считаем прохождение автоматизированных и ручных этапов контроля качества, которые и позволяют нам поставлять изменения быстро и без страха.
Рассмотрим конкретный пример.
В момент, когда триггерится сборка, например, когда разработчик сделал коммит в свою ветку, запускается процесс, который выполняется специально написанными скриптами и утилитами. Этот процесс состоит из нескольких обязательных шагов. Ошибка в любом из них приводит к полному падению всей сборки. Ну и, само собой разумеется, шаги расположены в таком порядке, чтобы сужать воронку потенциальных проблем. Если Quality Gate предыдущего этапа не пройдет, то на проверку следующего уже можно не тратить ресурсы.
Данные обещания надо выполнять, тем более, если они сделаны сначала в 
