Quality Gates: как мы встраиваем автоматические проверки кода в свои процессы

Принцип Quality Gates – буквально «ворота качества» – помогает решать проблемы в коде на ранних этапах, до того, как он обрастёт зависимостями. Если в коде есть дублирование, обнаруживаются проблемы с переменными или не хватает тестов, он не «проходит в ворота» и возвращается автору. В результате код становится чище и понятнее, баги оказывается проще исправлять, да и появляются они реже.

Три причины внедрить Quality Gates

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

Пошаговый план внедрения

Начинать эксперименты с Quality Gates стоит со статического анализа кода. Этот метод помогает командам избавиться от общих ошибок, вычистить код от шероховатостей и некоторых пробелов безопасности. Подчеркнём слово «некоторых» – чтобы в продукте не было уязвимостей, требуются специальные проверки.

Мы выбрали для статического анализа SonarQube, популярное open source решение, которое поддерживает пару десятков языков программирования. Важный для нас момент – есть интеграция с нашим инструментом контроля версий – TFS, так что мы можем делать готовые пайплайны с уже включёнными проверками кода.

Полезные выводы по результатам пилота

Уже после тестовых прогонов на нескольких десятках проектов мы смогли оценить эффективность и ограничения инструмента.

«С высоты птичьего полёта» отчетливо увидели, как у разных команд формируется собственный стиль – разработчики бессознательно формируют общий подход к написанию кода, в итоге внутри каждой команды появляются одни и те же недочёты. С Quality Gates такую ситуацию можно исправить у всех разом.
Первые результаты с сотнями ошибок на большой проект логко могут деморализовать. Важно понимать, что обращать внимание нужно не на общее количество проблем, а на их разнообразие. Чем меньше типов ошибок, тем быстрее можно всё исправить.
Для iOS-продуктов нужны дополнительные средства – базовая версия SonarQube не поддерживает Swift и Objective-С. В платной правил проверки для iOS в SonarCube в разы меньше, чем для Java/C#, к тому же нет одновременной проверки Swift и ObjC, а у нас большинство продуктов содержат код на обоих языках.
Для полноценной защиты продукта обязательно нужны дополнительные средства. Мы сопоставили список уязвимостей, которые нашёл SonarQube на одном из приложений, с результатами полноценного аудита безопасности. Совпадение обнаружилось только в одном случае – SonarQube не хватает динамических проверок, да и стандартный список правил нужно расширять.

Заключение

Статический анализ – это отличная стартовая точка для внедрения Quality Gates. Он даёт быстрый эффект, помогает определиться, куда двигаться дальше.

Общие требования к качеству позволяют в любом проекте запускать проверки на основе этих правил, централизовано обновлять их для всех сразу. Результатом проверок будет отчет со значениями ключевых метрик и объяснением, почему тот или иной код или алгоритм считается плохим – улучшая эти значения, команда будет повышать качество продукта и развивать свои навыки.