Протестируй это: как мы определяем, какие тесты запускать на пулл-реквест-чеках
Блог компании Сбербанк,
Тестирование IT-систем,
Тестирование веб-сервисов,
Тестирование мобильных приложений,
Управление разработкой
Привет, Хабр! Меня зовут Егор Даниленко. Я занимаюсь разработкой цифровой платформы корпоративного интернет-банка Сбербанк Бизнес Онлайн, и сегодня я хочу рассказать вам о процедуре CI разработки, принятой у нас.

Как изменения разработчика доходят до вливания в релизную ветку? Разработчик делает изменения локально и пушит в нашу систему управления версиями. Мы используем Bitbucket с авторским плагином (об этом плагине мы писали ранее здесь). На этих изменениях запускается сборка и гоняются тесты (юнит, интеграционные, функциональные). Если сборка не завалилась и все тесты пройдены успешно, а также после успешного ревью, пулл-реквест вливается в основную ветку.

Но со временем количество команд выросло. Пропорционально выросло и количество тестов. Мы понимали, что такое количество команд ускорит наступление проблемы «медленного пулл-реквест-чека», и разрабатывать продукт станет невозможно. На текущий момент у нас порядка 40 команд. Вместе с новыми фичами они приносят и новые тесты, которые также нужно запускать на пулл-реквестах.