Ну и что делать, если в вашей компании — несколько тысяч программистов, сотни команд и десятки стримов? И вам нужно… Нет, не нужно — жизненно необходимо, чтобы они все работали как единый, отлаженный, настроенный механизм.

Разработка в Газпромбанке — это процесс, в котором задействовано более 3500 инженеров, пять департаментов, 59 стримов и 200+ кросс-функциональных команд.

При этом был период, когда наши команды создавали ПО разрозненно, стандарта разработки не было, практики и технологии у всех свои. Велосипеды, как в анекдоте, были у всех, но ездили по-разному. Билды проходили тесты, которые не должны были пройти, и возвращались «на доработку» едва ли не перед запланированным релизом. Что же делать, как же быть?

Да. Нужен стандарт. И нужны автоматизированные средства поддержки стандарта.

Нам не подошли ни одни из существующих Quality Gates — мы сформировали собственный набор практик проверки качества продукта (билда, сборки — всего того, чему требуется многоуровневое тестирование). Теперь у нас выросшая в семь раз частота деплоев и шикарные фильтры, построенные на тестах.

Почему мы не купили готовое решение? Что сделали? Как? Расскажем.

Привет, Хабр! Меня зовут Евгений, я тимлид команды развития инженерных практик в Газпромбанке.

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

Мы внедряли Agile и переводили команды на Trunk Based Development с короткоживущими ветками, быстрыми мержами и непрерывной поставкой. Теоретически вместе с этим должно было прилететь счастье.

Но чёрта с два:

• Команды саботировали тесты и спеки.

• Не было готовых инструментов для кастомных Quality Gates.

• Недостаточно экспертизы по контрактным тестам.

• Legacy. Проблемы с Legacy никогда не меняются.

• Внешние подрядчики, которых тяжело заставить что-то менять и меняться самим.

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

В результате мы создали свой стандарт и разработали для него свои Quality Gates.

Стандарт, чек-лист и Quality Gates

Мы начали с главного — стандарта разработки. Вместе с head-of-profession описали, что такое «нормальная разработка» в контексте ГПБ — от языков и тестирования до мониторинга. Далее — чек-лист, по которому команда могла проверить свой сервис перед выпуском.

Часть этого чек-листа мы проверяем автоматически через Quality Gates, встроенные в пайплайн. Эти гейты автоматически проверяют соблюдение практик на этапе CI/CD.

А дальше мы начали строить QGaaS — quality gate as service

Готовые решения для Quality Gates нас не устроили. Почему? Потому что.

Ладно, потому что:

• Они слишком закостенелые или привязаны к одному инструменту.

• У них нет нормального механизма кастомизации и масштабирования.

Нам же хотелось:

• Решения «Platform agnostic» — отсутствия зависимости от инструмента CI/CD.

• Асинхронных проверок без задержек в пайплайне.

• Централизованного контроля над гейтами.

• Возможности постоянно обновлять практики без риска что-то сломать.

• Поддержки любых, каких мы сами придумаем, проверок.

• Innersource-разработки: мы хотели, чтобы наши пользователи делали вклад в развитие системы.

Мы решили создать свои собственные QG. Так появился сервис QGaaS — расширяемый сервис, который принимает события из CI/CD, Bitbucket, Jira и прогоняет нужные проверки.

Как он устроен

Для команды всё просто — достаточно добавить два шага в пайплайн:

1. QualityGateRunner — создаёт поставку (единицу релиза).

2. QualityGateCheck — проверяет, прошла ли поставка нужные гейты.

А под капотом — архитектура с очередями, роутерами, воркерами и кэшем:

1. CI отправляет информацию о сборке.

2. QGaaS создаёт «поставку» — сущность с метаинформацией (версия, фичи, дата, инициатор).

3. Воркеры запускают проверки: semver, sonar, спеки, healthchecks, контрактные тесты и другие.

4. Результаты складываются в базу и кэш, они доступны через API или веб-интерфейс.

Всё это работает асинхронно. Проверки можно перезапустить. Новые практики можно внедрять без изменений в пайплайнах команд.

У нас три Quality-гейта:

• QG1 — можно деплоиться на тестовый полигон.

• QG2 — на препрод.

• QG3 — на прод.

Если что-то не прошло — релиз дальше не поедет.

Что проверяет QGaaS уже сейчас:

• SemVer артефакта и валидность манифеста сервиса.

• Использование Feature toggles: живут до месяца, управляются централизованно через Unleash.

• API-спеки (OpenAPI/AsyncAPI). Мы следуем принципу API First: сначала — спека, потом — код.

• Контрактные тесты.

• Healthchecks.

• SonarQube.

• SAST и другие проверки от команды appsec (в будущем вообще начнём запускать их в параллель и экономить этим 30% времени).

• Соответствие чек-листу Стандарта разработки (пока что частично вручную).

Планируем автоматизировать генерацию кода по спекам, чтобы убрать «творчество» из сервисов и избавиться от контрактных тестов, которые могут занимать до 40% времени разработчика.

Теперь переходим к самому вкусному — результатам (а они впечатляют):

• Cycle time (от постановки задачи до продакшена) упал с 45 до полутора дней.

• Частота деплоев выросла в семь раз.

• Инциденты на проде упали на 71%.

• Собрано 4500 билдов, из них через QG1 прошло только 37% — то бишь 2500+ сборок было забраковано ещё до тестов: экономия времени QA — колоссальная.

У нас пять платформ, сотни команд и десятки тысяч релизов в год. Без средств контроля качества разработки всё это гарантированно развалилось бы. А QGaaS — это платформа, скомпилированная «по домашнему рецепту», дающая бешеные плюсы к качеству и стабильности.

В планах:

• Проверка миграций схем БД.

• Контроль практики Trunk Based Development по времени жизни веток.

• Расширение системы метрик.

• Подключение новых платформ к QGaaS.

• Доведение покрытия чек-листа до 100% автоматизации.

• Запуск универсального пайплайна с KotlinDSL: несколько переменных — и команда катится в прод.