Планы

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

Используйте его, когда для выполнения работы требуется несколько изменений в определенном порядке или когда вы хотите увидеть весь подход перед тем, как приступить к реализации.

Жизненный цикл#

Планирование — это самостоятельный этап, а не мгновенное преобразование.

1. Начинается планирование. Как только запрос проходит этап квалификации, архитектор анализирует кодовую базу и составляет этапы и задачи. Планирование начинается автоматически, если только в запросе не были вложения или не использовался рабочий процесс SDLC; в таких случаях оно стартует при создании плана или завершении подготовки.
2. Вы проверяете черновик. Это самый экономичный момент для внесения корректировок во всей системе.
3. Утвердить, отредактировать или сбросить. Утверждение запускает его на выполнение; редактирование отправляет его обратно с вашими комментариями; сброс перезапускает процесс планирования.
4. Выполнение. Задачи выполняются по очереди, соблюдая границы этапов.

Вы можете утвердить и запустить выполнение одним шагом или утвердить, а запустить позже.

Редактировать, а не сбрасывать#

Если план почти готов, его редактирование сохраняет знания архитектора о вашей кодовой базе и учитывает ваши комментарии. Сброс уничтожает эти данные и начинает все сначала.

Сбрасывайте план, если весь подход ошибочен. Редактируйте его, если подход верный, но детали не соответствуют ожиданиям. Редактирование обходится дешевле, а содержимое отклоненного плана не теряется — оно становится исходным материалом для следующей попытки.

Управление запущенным планом#

Запущенный план можно приостановить, возобновить или отменить, а также отслеживать прогресс по его этапам. Планы также можно клонировать — это удобный способ повторить уже проверенную структуру, например, при миграции на другой сервис.

Завершенные планы можно архивировать, чтобы сохранить актуальность основного представления.

Один pull request, а не один на каждую задачу#

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

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

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

Когда меняется базовая ветка#

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

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

Если базовая ветка изменилась, Утвердить и слить остаётся недоступной, а в отчёте о продвижении указываются новые коммиты и изменённые файлы. Вы выбираете дальнейшие действия:

• Принять новую основную ветку (названную в честь вашей базовой ветки) — эти изменения не влияют на текущую работу. Coroid фиксирует, кто и какой коммит принял и почему, и этот коммит становится новой базовой точкой. Если ветка изменится снова во время вашего рассмотрения, Coroid заблокирует процесс и покажет вам более новые коммиты. Ничто не будет принято без предварительного отображения.
• Слить и повторно проверить — Coroid сливает базовую ветку в ветку конвейера, разрешая конфликты при их наличии. Затем он снова пропускает ветку через этапы разработки, проверки качества и рецензирования, сверяя её с критериями приемки плана и коммитами из основной ветки. Утверждение сохраняется до завершения этого процесса. Только после этого новый коммит становится базовой точкой. Если слияние или повторная проверка завершатся неудачно, решение снова переходит к вам.

По умолчанию используется пауза. Проект может выбрать вариант «Слить и повторно проверить», чтобы Coroid запускал процесс без ожидания вашего вмешательства; подробнее — в Настройки репозитория и веток. Повторная проверка расходует часы работы агентов.

План, перезапущенный с начала, фиксирует новую базовую версию, поэтому он выполняется относительно базовой ветки в её текущем состоянии. Данные о предыдущей попытке сохраняются в истории, но не становятся актуальными для новой попытки.

Принудительное слияние также пропускает эту проверку и фиксирует указанную причину необходимости такого действия. Подробнее — Слияние.

Этапы и параллелизм#

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

Даже если в плане десять задач, допускающих параллельное выполнение, а слотов для агентов всего один, они будут выполняться по очереди. Структура не создает дополнительных ресурсов — см. Ресурсы и слоты агентов.

План или задача?#

В форме создания новой работы выберите План или Задача в поле Создать как, либо оставьте значение по умолчанию — Автоматически , и пусть квалификация сама определит тип. Работа, охватывающая более одного проекта, всегда оформляется как план. Если вы выберете один вариант, а квалификация порекомендует другой, вы увидите эту рекомендацию до создания чего-либо.

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

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

Этапы доставки#

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

Сопутствующее#

• Задачи, планы, спринты и конвейеры
• Спринты
• Спецификации
• Происхождение