Для pull request от Coroid уже выполнена проверка, прежде чем вы его увидите. В этом разделе рассказывается, что это значит и как настроить этот процесс.
Уровни
Процесс проверки не сводится к одному этапу: существует четыре уровня, каждый из которых отвечает на свой вопрос.
Ваш набор тестов. Это самый надежный показатель качества, так как он уже отражает то, что важно для вашей команды. Coroid запускает его в чистой рабочей среде для каждой задачи.
Критерии качества. Проверки, заданные политикой — покрытие кода, линтинг, браузерные тесты и Проверка на соответствие требованиям Глобализации для проектов с несколькими языками. Блокирующие критерии останавливают выполнение задачи; рекомендательные критерии фиксируют замечания и позволяют продолжить работу. Подробнее — в разделе Политики качества и критерии. Сканирование на предмет Безопасности выделено в отдельный этап: подробнее — в разделе Безопасность.
Рецензирование. Агент-рецензент анализирует готовый дифф и формирует замечания. Исправляемые замечания возвращаются разработчику на доработку; остальные прикрепляются к pull request.
Доказательства. Предварительные демо-версии, результаты сканирования и изменения в показателях покрытия кода прикрепляются к самому pull request, поэтому проверка сопровождает код. Подробнее — в разделе Доказательства для рецензирования.
- Ваш набор тестовНе ломает ли изменение уже работающий код?
- Шлюзы качестваСоответствует ли оно стандартам, закреплённым в вашей политике?
- РецензированиеПринял бы его внимательный читатель различий?
- ДоказательстваПриложены ли подтверждающие доказательства рядом с кодом?
- Ваша рецензияПравильное ли это изменение?
Каждый автоматизированный слой запускается до появления pull request, поэтому ошибки возвращаются как доработка в рамках одного запуска.
Что подтверждает и что не подтверждает процесс проверки
Процесс проверки подтверждает, что изменение выполняет заявленные функции, не нарушает существующую функциональность и соответствует заданным стандартам.
Он не подтверждает, что данное изменение — правильное решение для реализации. Именно для этого существуют критерии приемки в спецификации , а также процесс вашего рецензирования.
Изменение может пройти все уровни проверки и при этом оказаться ошибочным. Четкое соблюдение этого различия делает весь процесс достоверным — как только проверку начинают воспринимать как окончательное решение, люди перестают заниматься рецензированием.
Зачем запускать проверку заранее
Все уровни проверки выполняются до создания pull request, поэтому ошибки возвращаются на доработку в рамках текущего процесса, а не как отклоненный pull request.
Ошибка в рабочей среде обходится дешевле, чем ошибка при просмотре результата на экране. Ваше рецензирование должно стать первым человеческим взглядом, а не первым просмотром.
С чего начать
Если вы настраиваете этот процесс впервые:
- Убедитесь, что ваш набор тестов работает корректно — подробнее в разделе Настройка сборки и тестирования. Если этот этап выполнен неверно, все остальное не имеет значения.
- Установите стандартную политику организации на уровне стандарта , а не на самом строгом уровне.
- Подключите уже используемые вами поставщики доказательств.
- Добавляйте критерии по одному, сначала рекомендательные.