CoroidВаша AI программная фабрика
Документация

Как платформа Coroid проверяет собственную работу

Почему задача pull request из Coroid поступает уже проверенной и что подтверждает каждый уровень верификации.

Задание из Coroid в pull request проходит проверку перед тем, как вы его увидите. В этом разделе рассказано, что это значит и как настроить процесс.

Уровни

Проверка — это не единый процесс. Существует четыре уровня, каждый из которых отвечает на свой вопрос.

Ваш набор тестов. Это самый надежный показатель, так как он уже отражает то, что важно для вашей команды. Coroid запускает его в чистом рабочем пространстве для каждой задачи.

Критерии качества. Проверки, заданные политикой — покрытие кода, линтинг, сканирование на предмет уязвимостей, браузерные тесты и Проверка Глобализации для многоязычных проектов. Блокирующие критерии останавливают выполнение задачи; рекомендательные критерии фиксируют находки и позволяют продолжить работу. Подробнее о Политиках качества и критериях.

Рецензирование. Агент-рецензент анализирует готовый дифф и формирует заключения. Исправляемые замечания возвращаются разработчику для доработки; остальные прикрепляются к pull request.

Доказательства. Предварительные демо-версии, результаты сканирования и изменения в покрытии кода прикрепляются непосредственно к самому pull request, поэтому проверка сопровождает код. См. Доказательства рецензирования.

  1. Ваш набор тестовНе ломает ли изменение уже работающий код?
  2. Шлюзы качестваСоответствует ли оно стандартам, закреплённым в вашей политике?
  3. РецензированиеПринял бы его внимательный читатель различий?
  4. ДоказательстваПриложены ли подтверждающие доказательства рядом с кодом?
  5. Ваша рецензияПравильное ли это изменение?

Каждый автоматизированный слой запускается до появления pull request, поэтому ошибки возвращаются как доработка в рамках одного запуска.

Каждый автоматизированный слой отвечает на свой вопрос. Ни один из них не определяет, правильно ли было создавать этот функционал — это остаётся за вами.

Что подтверждает и что не подтверждает этот процесс

Проверка подтверждает, что изменение выполняет заявленные функции, не нарушает существующую логику и соответствует установленным вами стандартам.

Она не подтверждает, что данное изменение — правильное решение для разработки. За этим следят критерии приемки в спецификации , а также целью вашего рецензирования.

Изменение может пройти все уровни проверки и при этом оказаться ошибочным. Четкое соблюдение этого различия делает весь процесс достоверным — как только проверку начинают воспринимать как окончательное суждение, люди перестают заниматься рецензированием.

Зачем запускать проверку заранее

Каждый уровень проверяется до создания pull request, поэтому ошибки возвращаются как задачи на доработку в рамках одного запуска, а не как отклоненный pull request.

Ошибка в рабочем пространстве обходится дешевле, чем на экране вашего монитора. Ваше рецензирование должно стать первым человеческим взглядом, а не первым просмотром.

С чего начать

Если вы настраиваете этот процесс впервые:

  1. Убедитесь, что ваш набор тестов работает корректно — см. Настройка сборки и тестирования. Если это сделано неправильно, всё остальное не имеет значения.
  2. Установите стандартную политику организации на уровне стандарта , а не на самом строгом уровне.
  3. Подключите уже используемые вами поставщики доказательств.
  4. Добавляйте критерии по одному, сначала рекомендательные.

В этом разделе