Привет! Не пугайся, я полностью с тобой согласен, первая реакция на заголовок должна быть, как у Джеки. Сейчас всё расскажу по порядку. И в конце концов мы даже действительно взвесим два типа ТЗ.

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

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

Рассмотрим конкретный пример.

В момент, когда триггерится сборка, например, когда разработчик сделал коммит в свою ветку, запускается процесс, который выполняется специально написанными скриптами и утилитами. Этот процесс состоит из нескольких обязательных шагов. Ошибка в любом из них приводит к полному падению всей сборки. Ну и, само собой разумеется, шаги расположены в таком порядке, чтобы сужать воронку потенциальных проблем. Если Quality Gate предыдущего этапа не пройдет, то на проверку следующего уже можно не тратить ресурсы.

Hello World!

Меня зовут Сергей Павлов, я тимлид по системной аналитике в банке "Открытие” на продукте МСБ “Бизнес-Портал”. Хочу рассказать, как я решал задачи по управлению командой, когда к ней присоединился.

Скажу сразу: тут я не буду описывать графики, капасити, велосити и любые инструменты, связанные с командными метриками. Речь пойдет именно об организации процессов для повышения качества взаимодействия при коллективной работе.

Итак, морозное утро, вежливый голос руководителя мне говорит: “Это команда системных аналитиков, начинай творить добро”. Я смог выдавить только “угу” и сел думать насчет того самого творить и того самого добра.