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. Он даёт быстрый эффект, помогает определиться, куда двигаться дальше.
Общие требования к качеству позволяют в любом проекте запускать проверки на основе этих правил, централизовано обновлять их для всех сразу. Результатом проверок будет отчет со значениями ключевых метрик и объяснением, почему тот или иной код или алгоритм считается плохим – улучшая эти значения, команда будет повышать качество продукта и развивать свои навыки.
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 в приложение, чтобы выявить слабые места до того, как оно будет задействовано в производственной системе.
Quality Gates
Quality Gates – это набор условий, которым должен соответствовать проект, прежде чем он сможет претендовать на релиз. Концепция Quality Gates возникла еще в 1986 году и изначально применялась для контроля качества в автомобильной промышленности. Это лучший способ обеспечить соблюдение всех стандартов и их регулирование на проекте. Quality Gates можно определить как набор пороговых показателей, таких как Code Coverage, технический долг, количество блокирующих проблем и уязвимостей, дубликаты кода и т.д.
Linters
Проверка кода линтерами помогает избежать многих ошибок еще на этапе написания кода. Анализ синтаксиса и структуры кода проводится автоматически и при обнаружении нарушений правил написания кода, выводится соответствующее сообщение в консоль. Такой подход позволяет избежать очень много типовых ошибок на ранних этапах разработки, а так же значительно сэкономить время и силы на код-ревью.
Первый линтер был написан Стивеном Джонсоном в 1978 году, когда он работал в операционной системе Unix в Bell Labs. После появилось много других линтеров на разные языки программирования с различными настройками, позволяющие статически анализировать код, используя настройки конфигурации и проверяя соответствие кода заданным проектным требованиям по стилю и правилам безопасности.
Основные задачи линтеров:
1. Статический анализ – автоматизированное программное обеспечение проходится по Вашему коду (не выполняя его) и тем самым статически проверяет на наличие ошибок, например, табуляция, нейминг, утечки памяти, соответствие правилам Code standards, которые приняты на проекте и многое другое.
Code standards – это набор правил и соглашений, используемых при написании исходного кода на определенном проекте. Это обеспечивает читаемость кода, сохраняет одинаковую стилизацию по всему проекту и ускоряет процесс адаптации новых сотрудников.
2. Проблемы с безопасностью – есть специальные плагины, например eslint-plugin-security для node js, которые позволяют выявить слабые места безопасности, например, использование команды eval, вызов дочерних процессов, импорт модулей с передачей в соответствующую команду чего-то, отличающегося от строкового литерала и т.д.
4. Упрощения процесса Code review – поскольку описки и другие банальные ошибки будут исправлены до процесса Code review, во время просмотра Pull Request не будет необходимости тратить время на проверку синтаксиса кода и соответствие его базовым кодовым стандартам, а можно будет сосредоточиться на анализе выбранного решения, что значительно сэкономит время всех участников процесса review.
5. Делает код читаемым. Если стиль написания кода не изменяется от файла к файлу и в различных функциях – это делает код читаемым и легким для восприятия.
Рассмотрим пример такого кода:
После проверки линтерами вы увидите следующие ошибки:
Ожидается ‘use strict’ перед ‘alert’. alert(«Hello » + name);
Необъявленная переменная ‘name’ name = «Albus Dumbledore»;
Необъявленная переменная ‘name’ sayHello(name)
Ожидается ‘;’ в конце строки sayHello(name)
Pre-commit
Для уверенности в том, что все синтаксические ошибки исправлены на максимально раннем этапе – рекомендуют запускать линтеры в обязательном порядке перед каждым коммитом. В таком случае пока все ошибки не будут исправлены – система не позволит Вам сделать коммит в репозиторий.
Для создания Pre-commit хука установим пакет husky и включим хук в package.json :
Также рекомендуется добавление запуска Unit Tests в прекоммит хук, но об этой теме мы поговорим далее.
Code review
Code review – это анализ написанного кода другими разработчиками перед добавлением кода в общую ветку.
Основные задачи процесса Code review:
Подготовка к Code review:
Анализ кода с помощью SonarQube
SonarQube — это платформа с открытым исходным кодом, предназначенная для непрерывного анализа и измерения качества кода. В SonarQube есть набор правил для анализа исходного кода во время компиляции с целью выявления потенциальных уязвимостей, ошибок, анти-шаблонов и плохих методов кодирования. Также можете создать новые Quality Gates для своих проектов и определять индивидуальные пороговые значения.
При запуске SonarQube он определит, соответствует ли код всем установленным вами порогам качества, в случае если какой-то из Quality Gates нарушен – автоматическая сборка проекта завалится.
Automation Tests
В то время как выполнения тестов вручную – это медленный и кропотливый процесс, автоматическое тестирование позволяет один раз написать тестовые сценарии и автоматически запускать их каждый раз, когда разработчики вносят изменения в код приложения. Инструмент автоматизации тестирования собирает результаты и представляет их в удобном для чтения формате. Это позволяет вашей команде разработчиков своевременно тестировать программное обеспечение на предмет дефектов и быстро их исправлять.
Automation тесты делятся на 3 уровня: Unit tests, Integration и GUI (Graphical User Interface). Пирамида автоматизированного тестирования наглядно показывает сколько тестов какого уровня должно присутствовать. Unit tests – самые быстрые и простые тесты в написании, соответственно и самые дешевые, а это значит, что их должно быть больше всего на проекте. Интеграционные тесты предназначены для проверки связи между компонентами, а также взаимодействия с различными частями системы. GUI тестирование программного обеспечения проверяет графический интерфейс пользователя, а именно то, что при взаимодействии пользователя с приложением, например клик по кнопке или отправлении формы – пользователь получит ожидаемый результат. Эти тесты являются самыми сложными в написании и поддержке, требуют наибольшее время для прохождения, потому их количество должно быть наименьшее, в сравнении с другими тестами. GUI тесты следует запускать уже после того, как убедитесь, что Unit и Integration тесты прошли успешно. 
Automation тесты позволяют:
Чем раньше мы выявим проблемы, тем проще и дешевле их решить – используя возможности статического анализа кода, разработчики могут получать раннюю обратную связь об изменениях, находить и выявлять ошибки на самых ранних этапах.
Unit Tests
Unit Tests – это тестирование наименьшей части приложения – отдельной функции в изоляции от внешней логики. Задача каждого отдельного теста проверить, что при попадании на вход функции возвращается ожидаемый результат. Тесты должны быть максимально изолированы от приложения, для чего используются моки данных и функций.
Написание каждого теста проходит в 3 этапа:
Для unit-тестирования в Angular приложениях используется фреймворк Jasmine, для запуска тестов в разных браузерах или в headless mode используется Karma.
Функция describe() объединяет в себе группу взаимосвязанных тестов, где первый параметр (string) – текстовое описание группы, второй параметр – функция, которая содержит конфигурацию и набор тестов.
Функция it() описывает каждый тест в отдельности, она принимает 2 параметра – тестовое описание функции и функцию теста.
Функция expect() служит для проверки результатов, она принимает параметр – результат и позволяет его проверить одним из способов (toBeTruthy, toEqual, toContain …)
Unit тестов всегда наибольшее количество, так как они маленькие, не занимают много времени на написание и поддержку, не требуют много ресурсов и в кратчайшие сроки позволяют разработчикам обнаружить ошибки в коде еще на ранних этапах разработки.
Code Coverage – одна из оценок качества тестирования приложения. Она показывает на сколько хорошо приложение покрыто тестами в процентном соотношении.