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