Это страница, на которую ссылаются остальные разделы документации. На ней указаны все этапы выполнения, чтобы в других статьях можно было точно описать место возникновения того или иного процесса.
Путь
- 1
СпецификацияЧто будет создано и как вы узнаете, что это сработало
АрхитекторВы можете изменить - 2План
Упорядоченные шаги, согласованные перед написанием кода
АрхитекторВы утверждаете - 3
СборкаКод и тесты, написанные в изолированном рабочем пространстве
Разработчик - 4
ПроверкаВаш набор тестов, а также проверки и критерии качества
Специалист по тестированию - 5
РецензированиеАвтоматизированная проверка различий в коде
Рецензент - 6Запрос на объединение
На ветке вашего репозитория, ожидает вашего решения
Вы сливаете
Неудачные результаты проверки и исправляемые замечания рецензента возвращаются разработчику для доработки, прежде чем откроется pull request.
Эти этапы одинаковы для обоих режимов выполнения задачи. В стандартном режиме платформа переводит задачу из одного этапа в другой. В режиме координатора агент планирования выступает в роли координатора, передает каждый этап соответствующему агенту и решает, что делать после получения результата, включая отправку работы обратно. В любом случае этап завершается собственными проверками. См. Роли агентов — там описано, чем отличаются эти два режима.
Спецификация
Coroid не начинает работу с вашего предложения. Сначала он преобразует ваше описание в спецификацию: что будет создано, что явно не входит в область применения и критерии приемки, по которым определяется успешность выполнения работы.
Это важно, потому что критерии приемки используются на этапе верификации для проверки результата. Нечеткая спецификация приводит к тому, что результат трудно оценить.
Вы можете просматривать и редактировать спецификацию на вкладке задачи Спецификация перед началом выполнения.
Руководство по разработке на основе спецификации подробно рассказывает о том, как составлять проверяемые критерии, устанавливать границы области применения и сохранять единое определение успеха на всех этапах — от планирования до реализации и проверки. объясняет, как задавать проверяемые критерии, определять границы объёма работ и сохранять единое понимание успеха на этапах планирования, реализации и проверки.
Для любых задач, кроме небольших изменений, спецификация превращается в
план **: упорядоченный набор шагов, сгруппированных по этапам. Вы утверждаете план перед написанием кода.**Отклонить план — недорого и это правильный шаг, если подход ошибочен. Отклонять его после написания кода — дорого. Именно на этом этапе ваше суждение имеет наибольший вес.
Отклонить план несложно, и это правильное решение, если выбран неверный подход. Отклонить его после написания кода обходится дорого. Именно на этом этапе ваше суждение имеет наибольший вес.
Агент клонирует репозиторий в изолированное рабочее пространство и работает там. Он читает код, вносит изменения и создает или обновляет тесты.
Рабочее пространство является разовым и привязано к конкретной задаче. Ничто из того, что делает агент, не затрагивает вашу стандартную ветку, а две задачи, выполняющиеся одновременно, не могут видеть работу друг друга в процессе.
Рабочая среда создаётся отдельно для каждой задачи и удаляется после её завершения. Действия агентов не затрагивают вашу ветку по умолчанию, а две одновременно выполняющиеся задачи не видят работу друг друга в процессе.
Сначала запускается ваш собственный набор тестов — это самый надежный сигнал, так как он отражает то, что уже определено вашей командой как важное.
Кроме того,
ограничения качества проверяют все параметры, настроенные в вашей организации: пороги покрытия кодом, линтеры, браузерные тесты на предварительном деплое и выполняют все проверки, настроенные в вашей организации: пороговые значения покрытия кода, линтинг, браузерные тесты в предварительной среде и Безопасность . Блокирующая проверка останавливает задачу; рекомендательная фиксирует результат и позволяет продолжить работу.
Рецензирование
Агент-рецензент изучает diff так же, как это сделал бы коллега, и формирует замечания. Замечания, которые можно исправить, отправляются на доработку; остальные прикрепляются к pull request, чтобы вы их увидели.
Поэтому Coroid pull request поступает уже после проверки — не для того, чтобы заменить вашу проверку, а чтобы она была не первой.
Запрос на слияние
Ветка отправляется в удалённый репозиторий, и создаётся pull request в целевой ветке, содержащий изменения, тесты, результаты проверок и замечания рецензента. Если код уже выполняет требования задачи, отправлять нечего: QA проверяет неизменённый код, и задача завершается без pull request.
Автоматизация задач в Coroid на этом заканчивается. Слияние — за вами.
После слияния
Откройте Релизы , чтобы подготовить конкретный коммит, который вы собираетесь
выпустить. Релиз может включать несколько слитых запросов на слияние, прямой коммит или
изменения, влитые за пределами Coroid. Этап выпуска и согласования относятся к этому коммиту
и конкретной среде. Ваш конвейер развёртывает его; Coroid фиксирует
подтверждённый успех или явное подтверждение, прежде чем показать релиз как выпущенный. Задача
со статусом COMPLETED или один только слитый pull request не подтверждают развёртывание.
Статусы задач
Статус задачи показывает, на каком этапе описанного выше процесса она находится:
| Статус | Значение |
|---|---|
PENDING | Принята, ожидает свободного слота агента |
IN_PROGRESS | Выполняется |
PENDING_REVIEW | Работа завершена и проверена; ожидает интеграции или согласования |
COMPLETED | Работа по задаче завершена; развёртывание отслеживается отдельно |
NEEDS_HUMAN_REVIEW | Coroid не может продолжить работу самостоятельно и задаёт вам вопрос |
PAUSED | Временно приостановлена, можно возобновить |
FAILED | Не удалось завершить выполнение |
CANCELLED | Остановлена вами |
WONT_FIX | Закрыта без выполнения работы |
Что влияет на пропускную способность
Один слот агента Платформа выполняет по одной задаче за раз. Слоты определяют объём параллельно выполняемых операций; они не ускоряют завершение отдельной задачи. Продолжительность выполнения задачи зависит от объёма изменений и времени, необходимого для запуска тестового набора.
Далее
Роли агентов — какой агент отвечает за каждый этап работы. Затем ознакомьтесь с Релизы для настройки маршрута после слияния изменений через ваши среды.