quality gates что это
Quality Gates: как мы встраиваем автоматические проверки кода в свои процессы
Quality Gates – это автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки. Рассказываем, как работает эта технология, и поделимся дорожной картой, которую мы составили, чтобы внедрить 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. Он даёт быстрый эффект, помогает определиться, куда двигаться дальше.
Общие требования к качеству позволяют в любом проекте запускать проверки на основе этих правил, централизовано обновлять их для всех сразу. Результатом проверок будет отчет со значениями ключевых метрик и объяснением, почему тот или иной код или алгоритм считается плохим – улучшая эти значения, команда будет повышать качество продукта и развивать свои навыки.
Кто ответит в agile за качество разработки сложных проектов, или методология Quality Gates
Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки. Ее не любят за тяжеловесность и плохую реакцию на изменения. Это напрямую влияет на актуальность продукта и увеличивает ТТМ (time-to-market), выливаясь в дополнительные затраты. Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.
Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.
Все решают проблему по-разному, но обычно все сводится к автоматизации тестирования. Разрабатываются тесты на заглушках, общие правила формирования бэклогов соседних команд — фреймворки для межкомандного взаимодействия типа SAFe. В итоге благодаря синхронизации бэклогов команды смежных продуктов могут вместе писать и проводить тесты, в том числе интеграционные. Такие фреймворки есть и у нас.
Но теперь поставим себя на место владельца сложной и высококритичной банковской системы. Кто все-таки ответственен за качество всего этого продукта, если им занимается сразу десяток по-своему ответственных agile-команд? Нужна уверенность, что в продакшене ничего не завалится. Вводить дополнительные тестирования? Привет, waterfall, и пока, TTM.
Идеального решения здесь нет. В этой ситуации мы всегда будет иметь конфликт между принципами методологии и гарантированной надежностью результата. Вот какой компромисс нашли мы.
Quality Gates
Если специфика вашего продукта предполагает, что он не полностью изолирован от других, то в точках соприкосновения вы должны играть по одним правилам — соблюдать минимальный уровень качества. Код должен покрываться модульными тестами, не должен содержать критичных дефектов ИБ, дистрибутивы по мере поставки должны проходить смоук-тесты. Никакой жести, но требования обязательны для всех. Их выполнение — это пропуск к общему тестированию.
Так, в общем, и выглядит практика Quality Gates — набор автоматизированных проверок, встроенных в devops-пайплайн каждой системы. По сути она отражает тенденцию к шифт-лефт тестированию, о которой сейчас частенько говорят в рамках девопса.
Мы договорились со всеми командами о ряде проверок, quality gates, которые они должны проходить в ходе прохождения этапов жизненного цикла.
Кодинг
Перед сборкой кода нужен обязательный статический анализ, проверка кода на соответствие стандартам конкретного языка программирования. А также на полноту покрытия модульными тестами. Для этого существуют разные инструменты. Мы, например, любим SonarQube. Пройдя этот quality gate, команды могут быть уверены, что не нарушили ряд базовых правил еще на раннем этапе. Например, избежали значительного дублирования, которое увеличивает сложность кода и вероятность проблем.
Вторая проверка перед сборкой — это проверка ИБ. Есть общепринятые практики по выявлению проблем ИБ в коде и инструменты, которые могут просканировать код и выявить опасные места. Например, некорректно объявленная переменная может привести к проблемам в продакшене. Здесь мы договорились не допускать все, что можно выявить на этапе написания кода, до пентестов и более сложных проверок.
Сборка дистрибутива
При сборке дистрибутива мы обязательно проверяем результат: что сборка прошла корректно, что все службы запустились и работают как надо, что дистрибутив можно установить на нужную среду, и он заработает. Такой buiild verification test исключает потенциальное непонимание между тестировщиком и разработчиком. В waterfall-практике, бывало, разработчик заканчивал работу, передавал дистрибутив тестерам, а при установке на стенд выяснялось, что сборка даже не запускается. Тогда весь цикл нарушался, разработка растягивалась и вообще ничего хорошего не происходило.
У нас интеграционное взаимодействие выстроено очень непросто. Важно не сломать стенд, на котором могут проверяться и другие команды. Мы можем сделать это из-за плохого дистрибутива, и соседи по стенду узнают об этом раньше нас — мы просто нарушим им весь процесс работы. Кроме того, так можно испортить тестовые данные. А их подготовка тоже стоит денег и занимает немалое время. Особенно когда речь идет об обезличенных данных пользователей.
Смоук-тесты
По мере установки дистрибутива на каждый стенд тестирования он проходит ряд простых смоук-тестов. На стенде системного тестирования тестируется функциональность дистрибутива. Дальше дистрибутив ставится на стенд интеграционного тестирования, где тестируются интеграционные взаимодействия. На нем тоже выполняется набор смоук-тестов. Если дистрибутив их не проходит, он не может перейти на следующий этап.
С помощью этих quality gates мы получаем первичное представление о качестве дистрибутива. Если смоук-тесты прошли успешно, команда приступает к тестированию. Если дистрибутив не прошел смоук-тесты на этом этапе, он, скорее всего, не пройдет и мануальное тестирование. Здесь мы назначаем его только в том случае, когда сборка потенциально готова пойти в пром.
Quality gates как фреймворк
Мы стремимся к тому, чтобы quality gates стали полноценным фреймворком для управления качеством разработки большого количества продуктов в agile. Если какая-то команда постоянно не проходит даже обязательные quality gates — это сигнал о наличии проблем, которые нужно обсудить и решить. С другой стороны, если какая-то команда уже освоилась с базовыми quality gates и встроила их во внутренние процедуры, она может пойти дальше и включить дополнительные quality gates.
В будущем мы планируем выкатывать новые наборы обязательных quality gates. А также необязательных, чтобы каждая команда с достаточным уровнем зрелости могла выбрать, что ей нужно. Например, если стоит прорабатывать стабильность дистрибутива на интеграционных полигонах, команда возьмет одни quality gates. Если нужно следить, чтобы сложная и многокомпонентная сборка не затрудняла деплой — возьмет другие. У кого-то уклон в безопасность на фронте, у кого-то в сторону проверок нагрузочного тестирования, доступности стендов, отклика, у кого-то впереди интеграция или проверка на какие-то данные. Каждая команда сможет найти quality gates для своего случая.
Важно отметить, что quality gates — это не замена тестирования, а инструмент первичного контроля. Тестирование никто не отменяет. Главная задача здесь — как можно раньше минимизировать ущерб другим командам от низкого качества продукта.
Пример стороннего пайплайна, включающего quality gates
Итоги внедрения quality gates
В первую очередь, мы увеличили стабильность производственного цикла. Шифт-лефт в действии, мы можем сразу обнаруживать критичные баги функциональности. Меньше времени уходит на различные итерации тестирования, раньше обнаруживаются дефекты, так что их устранение обходится дешевле.
Уменьшился лид-тайм — время от начала кодинга фичи до ее внедрения в продакшн. Стабильность инженерного этапа ТТМ повысилась за счет того, что мы уменьшили простои в процессе поставки дистрибутива в промышленную среду. Чистое время на тестирование мы тратим такое же, но при этом у нас нет простоев из-за того, что развалился стенд, что нужно ждать пересборки дистрибутива.
Выросло время доступности сред для тестирования. Раньше ты мог поставить на нее сборку и забыть о ней на неделю. А тем временем смежные команды не могли протестироваться в этой среде, потому что твоя сборка дефективна и ты узнаешь об этом только через неделю. Теперь, когда ты ставишь сборку на полигон, то сам тестируешь ее на самые распространенные проблемы, при необходимости откатываешься, допиливаешь, возвращаешь обратно. И шанс никому не помешать становится гораздо выше. Внедрение quality gates также приведет к сокращению костов на восстановление стендов и переподготовку данных для тестирования.
Ваше мнение?
Как мы говорили в начале, противоречие между принципами agile и комплексной разработкой нельзя разрубить как гордиев узел. Можно лишь стремиться к тому, чтобы оно приносило как можно меньше проблем. В нашем случае помогает практика quality gates, но, конечно, мы не считаем ее идеальной. А как решаете эту проблему вы? Нам было бы очень интересно обсудить этот вопрос.
Николай Воробьев-Сарматов, Сбербанк-Технологии, Sberworks
Спасибо Михаилу Бижану за помощь в подготовке статьи!
Отображение разработчикам статуса контроля качества исходного кода в SonarQube
SonarQube — это открытая платформа для обеспечения непрерывного контроля качества исходного кода, поддерживающая большое количество языков программирования и позволяющая получать отчеты по таким метрикам, как дублирование кода, соответствие стандартам кодирования, покрытие тестами, сложность кода, потенциальные ошибки и т.д. SonarQube удобно визуализирует результаты анализа и позволяет отслеживать динамику развития проекта во времени.
Задача: Показывать разработчикам статус контроля качества исходного кода в SonarQube.
Есть два способа решения:
Установка SonarQube
Для установки sonarqube из rpm пакетов воспользуемся репозиторием https://harbottle.gitlab.io/harbottle-main.
Установим пакет с репозиторием для CentOS 7.
Устанавливаем сам sonarqube.
При установке установятся большинство плагинов, но нужно доустановить findbugs и pmd
Запускаем сервис и добавляем в автозагрузку
Если долго загружается, то добавьте в конец опций sonar.web.javaOpts генератор случайных чисел /dev/./urandom
Запуск скрипта проверки статуса контроля качества исходного кода в SonarQube.
К сожалению, плагин sonar-break-maven-plugin давно не обновлялся. Поэтому напишем свой скрипт.
Отображение на главной странице проекта статус контроля качества исходного кода
Устанавливаем плагин для SonarQube
Заходим в SonarQube по адресу http://172.26.9.115:9000/
Создаем обычного пользователя, например «badges».
Заходим под этим пользователем в SonarQube.
Заходим в «My account», создаем новый токер, например с названием «read_all_repository» и нажимаем «Genereate».
Видим что появился токен. Он появлется только 1 раз.
Заходим под администратором.
Копируем этот токен в поле «Activity badge token» и нажимаем кнопку save.
У пользователя badges необходимо установить галку «Browse».
Импортируем этот проект.
В SonarQube проект будет выглядеть так:
Добавляем bages в README.md и они будут выглядeть так:
Код отображения badges выглядит так:
Разбор строки отображения badges:
Где взять/проверить Project Key и id-проекта.
Project Key находится справа внизу. В URL находится id-проекта.
Опции для получение метрик можно посмотреть тут.
Все pull request на улучшение, исправления ошибок присылайте в этот репозиторий.
8 советов по улучшению качества кода
Качественный код — это командная работа, вне зависимости от должности. Менеджер, разработчик и тестировщик должны вместе работать над созданием высококачественного кода.
Ниже представлен список методов по улучшению кода, которые будут полезны для любого проекта.
1. Используйте линтер совместно с IDE
С помощью линтера можно избежать множество проблем. Как мы все знаем, линтер читает код, выдает ошибки и предупреждения, если код не соответствует определенному стандарту языка.
Такие интегрированные среды разработки, как VS Code, JetBrain, Atom имеют множество функций и дополнений для кодового линта. Например, VS Code обладает линтингом для Python, JSLint и других популярных языков программирования.
При добавлении линтинга для существующей базы кода я бы порекомендовал начать с минимального набора правил. Затем вы сможете добавить новые правила на основе полученных результатов проверки кода вручную.
Интеграция инструментов Linter совместно с процессом CI помогает командам обеспечить качество кода и установить систему управления. Мы можем сделать это с помощью таких инструментов CI/CD, как Jenkins, Azure DevOps, Bamboo и т.д. В качестве примеров для автоматического линтера можно выделить flake8, black, pre-commit.
Некоторые платформы оценки качества кода, такие как SonarCloud, также предоставляют линтер для запуска в интегрированной среде разработки. При этом используется один и тот же набор правил, определенный для платформы в одном месте.
Более того, существуют методы, с помощью которых вы сможете заставить команду разработчиков проверить линтинг перед созданием кода, сокращая при этом общее время на итерацию.
Вы можете это сделать, добавив осуществление линтера на крючках предварительного коммита git.
2. Правильный баланс комментариев
Можно выделить два типа разработчиков — те, кто постоянно комментирует все, и те, кто ничего не комментирует.
Как многие знают, добавление слишком большого количества комментариев к коду делает его нагроможденным и трудным для чтения. С другой стороны, отсутствие каких-либо комментариев оставляет будущих разработчиков в состоянии смятения.
Поэтому мы рекомендуем сделать код настолько понятным, чтобы потребовалось минимальное количество комментариев.
Объясняйте то, что код делает, а не определяет.
Однако добавление комментариев бесполезно, если они не обновляются при изменении кода.
Совет: делитесь своими часто используемыми компонентами с помощью Bit (Github).
Bit упрощает совместное использование, документирование и повторное использование независимых компонентов между проектами. Примените его для максимального повторного использования кода, обеспечения согласованного дизайна, ускорения доставки и создания масштабируемых приложений.
Bit поддерживает Node, TypeScript, React, Vue, Angular, и т.д.
3. Автоматизация тестирования
Тестирование необходимо для написания качественного кода. Автоматизация данного процесса поможет снизить расходы на ручное повторное тестирование. Однако это не значит, что мы можем отказаться от ручного тестирования.
Наличие комплексного тестирования помогает выявить ошибки кода и упрощает рефакторинг.
Возможно, вы зададитесь вопросом, где же нам стоит начать? На каких тестах мы должны сфокусироваться?
Это зависит от характера приложения, API и т.д. Например, если вы разрабатываете API, вы можете полагаться на автоматическое тестирование API и модульное тестирование. Если это веб-приложение, вы можете использовать сквозное и модульное тестирование. Более того, вы можете обратиться к тестовой пирамиде, чтобы лучше понять необходимые тесты.
В зависимости от вашей стратегии, вы можете использовать действенные методы тестирования. Например, тестирование моментальных снимков после разработки.
4. Обзор кода вручную
Обзор кода — это самый важный этап в написании качественного кода. Как правило, мы проводим обзор кода на Git Pull Request, где этому способствуют такие современные Git-платформы, как GitHub, Azure DevOps, GitLab. Это поможет проверить код перед объединением с соответствующей веткой.
Кроме того, можно автоматически добавить комментарии к ревью кода, используя такие инструменты анализа, как SonarCloud. Благодаря им можно значительно сократить усилия.
Однако ни один статический анализатор на данный момент не способен полностью заменить опытного разработчика, который проводит ручную проверку.
В качестве непрерывного процесса улучшения вы можете периодически оценивать распространенные ошибки и находить новые правила или новые статические анализаторы кода для их автоматизации.
5. Quality Gates
Quality Gates устанавливает условия и руководящие принципы, которые указывают, соответствует ли предмет необходимым критериям для перехода к следующему этапу.
Как Quality Gates помогает улучшить качество кода?
Quality Gate определяет проблемы с качеством кода и блокирует плохо разработанный код до того, как он попадет в производственную среду. Таким образом, Quality Gate выполняет следующие действия:
· Измеряет масштаб тестирования и проверяет, что он превышает определенный уровень.
· Выполняет автоматизированные тесты (модульное тестирование, интегрированное тестирование и E2E).
· Анализирует статический код.
Однако важно понимать время выполнения и использовать Quality Gate в нужном месте CI/CD-конвейера. Например, мы проводим модульные тесты, статический анализ качества кода во время выполнения интеграционных тестов и E2E-тестов после объединения кода или в зависимости от времени и ресурсов, которые для этого требуются.
6. Периодическая осмотрительность
Техническая проверка — это процесс, которого мы придерживаемся для оценки технологии, продукта, архитектуры и процедуры.
Для чего нужна комплексная проверка программного обеспечения?
В современном мире технологий важность программного обеспечения для успеха бизнеса возрастает. Программное обеспечение выступает основой современной цифровизацией. В условиях высокого спроса и конкуренции в программных активах важно определить архитектуру приложений, которая разработана с учетом современных технологий и открыта для будущих расширений.
После нескольких проверок нам стоит следить за разработкой программного обеспечения:
· Убедитесь, что команда выполняет процесс соответствующим образом. Например, должны быть выявлены требования, функции и ошибки, а изменения кода записываются в соответствии с процессом.
· Убедитесь, что команда придерживается эффективного процесса создания приложения. Например, в кратчайшие сроки можно протестировать новую версию приложения.
· Возможно ли отслеживать каждую версию в отношении запланированных и развернутых функций?
· В какой степени пользователь включен в процесс отслеживания ошибок, чтобы обеспечить своевременный и комплексный отчет об ошибках?
· Как автоматизированы механизмы обновления программного обеспечения?
· Периодически выплачиваются технические долги и создается необходимая развивающаяся архитектура.
· Команда придерживается рекомендаций по безопасности и качеству кода с постоянными улучшениями.
Ниже представлены некоторые из них.
7. Определите стандарты написания кода
Обозначение стандартов имеет позитивное влияние на любую команду. То же самое относится и к разработке программного обеспечения. Определение стандарта написания кода помогает предприятиям организовать и сфокусировать внимание команды разработчиков на повышении качества продукта.
Стандарты написания кода помогают разработчикам и членам команды работать над проектом, который соблюдает определенный набор руководящих принципов. Плюсы грамотно выстроенных стандартов:
· Снижение риска провала проекта.
· Простота в использовании.
Более того, важно также определить ценности для команды, чтобы улучшить качество. Хорошим примером может служить правило бойскаутов.
Всегда оставляйте палаточный лагерь чище, чем вы его нашли. Если вы обнаружите беспорядок на земле, уберите его независимо от того, кто мог это сделать. (Источник)
Это отличная аналогия, чтобы мотивировать команду не оставлять недоделанный код.
8. Сканирование уязвимостей
Регулировка уязвимости является ключевой обязанностью любой компании IT-безопасности и команд разработки программного обеспечения. Этот процесс включает оценку, уменьшение и отчет о любых слабых местах безопасности в системах и программном обеспечении организации.
Сканер уязвимости — это приложение, которое определяет любые слабые места CVS в коде. Он сканирует кодовую базу приложения и уведомляет о наличии в коде каких-либо слабых мест.
Если вы хотите начать с малого, то можете использовать команду npm audit в CI/CD-конвейере для JavaScript, анализа уязвимостей библиотеки узлов.
Большинство организаций автоматизируют сканирование уязвимостей с помощью CI/CD-конвейеров. Мы можем внедрить DevSecOps в приложение, чтобы выявить слабые места до того, как оно будет задействовано в производственной системе.