Это этап контроля качества — это проверка, которую должна пройти работа перед тем, как она сможет продолжить выполнение. Этапы контроля качества позволяют превратить критерий «достаточно хорошо для релиза» из субъективного суждения в правило, которое система применяет одинаково каждый раз.
Блокирующие и рекомендательные
Каждый этап контроля качества относится к одной из этих категорий, и именно это определяет всю его логику:
- Блокирующие — при неудаче выполнение задачи останавливается. Работа не будет продолжена, пока требования не будут выполнены или пока человек не отменит это ограничение.
- Рекомендательные — при неудаче результат фиксируется как замечание и прикрепляется к запросу на объединение кода, но выполнение задачи продолжается.
Начните с рекомендательных этапов. Понаблюдайте за тем, какие этапы контроля качества актуальны для реальной работы в течение недели-двух, а затем переведите те из них, которые себя оправдали, в категорию блокирующих. Если этап контроля начнет блокировать выполнение с первого дня без предварительной настройки, он скорее всего заставит сотрудников обходить его.
Блокирующий шлюз
- Покрытие кода ниже 80%Сбой
Задача останавливается
Она возвращается на доработку вместо того, чтобы открывать pull request, который вы всё равно отклонили бы.
- Лицо, обладающее полномочиями, может отменить это требование. В системе фиксируется, кто, когда и на каком основании это сделал.
Информационный шлюз
- Покрытие кода ниже 80%Сбой
Результат проверки фиксируется
Задача продолжает прохождение этапа рецензирования.
- Результат проверки прикрепляется к pull request для вашего рассмотрения.
Что может проверять этап контроля качества
Этапы контроля качества располагаются на этапе верификации и могут охватывать:
- успешное прохождение вашего собственного набора тестов
- пороги покрытия кода тестами
- проверку кода на соответствие стилю и статический анализ
- сканирование на наличие уязвимостей, настроенное в Безопасность
- браузерные тесты на работающей предпросмотровой версии
- доказательства от внешних поставщиков, прикрепленные к pull request
Самым ценным этапом контроля качества почти всегда является ваш существующий набор тестов, так как он уже отражает то, что важно для вашей команды.
Где этап контроля качества может остановить выполнение работы
Этапы контроля качества запускаются во время верификации, после завершения работы агента разработчика и перед этапом рецензирования. При блокирующей ошибке задача возвращается на доработку, а не превращается в pull request, который в итоге будет отклонен.
Такой порядок действий не случаен: дешевле допустить ошибку на этапе выполнения, чем на вашем рабочем экране.
Политики
Этапы контроля качества группируются в политики, и именно их вы привязываете к проектам. Политика — это именованный набор этапов контроля качества с указанием их типа (блокирующие или рекомендательные), чтобы можно было использовать одну политику для производственных сервисов и более мягкую — для внутренних инструментов.
Политики имеют версионность. Вы публикуете изменения, и при необходимости можете откатиться к предыдущей версии, если новый этап контроля качества окажется слишком строгим.
Отмены
Блокирующий этап контроля качества может быть отменен человеком, имеющим на это полномочия. Такая отмена фиксируется — кто, когда и по какой причине ее сделал.
Именно этот учет и важен. Этап контроля качества, который нельзя отменить, заставит людей искать способы его обойти; этап, который можно отменить без следа, на самом деле не является этапом контроля качества. Отмена с сохранением записи — это и удобно, и прозрачно.
Чего этапы контроля качества не делают
Этапы контроля качества проверяют свойства кода. Они не определяют, решает ли работа нужную проблему — для этого существуют критерии приемки в спецификации , а также этап рецензирования.
Изменение может пройти все этапы контроля качества и при этом оказаться неверным.