Пример: ветки, MR и код-ревью
Вымышленный проект «Обращения», тот же поток, что в примере процесса задачи. Это пример заполнения Git-шаблона, без утверждения о фактических настройках какого-либо клиента.
Ветки и права
| Параметр | Значение примера |
|---|---|
| Репозиторий | service-ui; реальный URL и доказательство доступа заполняются в рабочей версии |
| База / цель MR | Актуальная main |
| Рабочая ветка | agent/APP-42-summary-limit |
| Граница | Одно изменение поведения по APP-42, код и тесты в одном MR |
| Аккаунт агента | agent-project; роль Developer с проверенными правами рабочей ветки, MR и комментариев |
| Защита main | Прямая запись агента запрещена; merge выполняет Алексей |
| Обновление базы | Merge актуальной main в рабочую ветку; после конфликтов — повторные проверки |
| Переписывание истории | Для продуктовых веток force push не разрешён; исключение для служебных деплойных веток описано отдельно в варианте CI/CD ниже |
| Завершение ветки | После merge ветку удаляет Алексей; при передаче человеку ветка и MR сохраняются |
От ветки до merge
- Агент получает актуальную main, создаёт рабочую ветку и связывает её с APP-42. Проверяет, что рабочая ветка относится к этой задаче.
- Вносит код и тесты, выполняет обязательные проверки. Создаёт draft MR в main с причиной изменения, результатом, ссылкой на задачу, проверками и ограничениями.
- Когда комплект готов, автор переводит MR в готовность к ревью и назначает Алексея и Бориса. Применение этого шага агентом и маршруты PoC/Пилота описаны в отдельном примере.
- Алексей проверяет код и влияние изменения, Борис — смысл автотестов и доказательства. В этом примере на старте подробно проверяются все MR.
- Агент обрабатывает замечания, делает новый коммит, повторяет затронутые проверки и отвечает ссылками на diff и результаты. Обсуждение закрывает автор замечания либо явно назначенный ревьюер после подтверждения исправления.
- После продуктовой приёмки и выполнения условий Алексей делает merge. Агент проверяет фактическое слияние и обновляет задачу по правилам процесса.
Пример содержимого MR
Зачем: форма должна принимать текст до 1000 символов по решению Ольги в APP-42.
Изменение: обновлены ограничение ввода и проверка API; текст ошибки использует тот же лимит.
Проверки: границы 999/1000/1001, пробелы и существующий сценарий регистрации. В рабочем MR указываются точные ревизии, результаты и ссылки на прогоны.
Риски и ограничения: контракт ответа не менялся; миграция не нужна. Изменение текста интерфейса проверяет Борис; при отсутствии соответствующего доказательства это указывается как непроведённая проверка.
Замечание и повторная проверка
Борис замечает, что тест на 1001 символ проверяет только код ответа, но не отсутствие созданной записи. Агент добавляет проверку состояния данных и повторяет тест. В ответе указывает коммит и результат прогона. Борис проверяет исправление и фиксирует решение; ответ агента не заменяет его подтверждение.
Если Алексей требует лимит 500, противоречащий решению Ольги, агент не выбирает последний комментарий автоматически: открывает предметный вопрос по маршруту HITL и приостанавливает зависимое изменение.
Изменение версии после ревью
В этом примере новые изменения после одобрения требуют повторного подтверждения затронутых частей. Если обновилась main, агент обновляет рабочую ветку, разрешает типовые конфликты в пределах инструкции, повторяет проверки. Конфликт с неоднозначным поведением направляет Алексею.
До merge Алексей проверяет, что результаты CI и ревью относятся к итоговой версии. Приёмка прежней версии не переносится автоматически на изменившееся поведение.
Приёмка и завершение
Для проверки UI собирается артефакт проверяемой ревизии, публикуется в хранилище и деплоится по ID на UAT. Борис предъявляет результат проверки, Ольга фиксирует продуктовую приёмку. При последующем изменении поведения нужна повторная проверка затронутого.
В примере «решено» означает приёмку и merge в main. Если клиент считает завершением выпуск в production, после merge задача остаётся на соответствующем этапе до подтверждения выпуска. Настройка среды всегда выполняется через сборку, хранилище артефактов и деплой.
В рабочую версию примера добавляются ссылки на правила защиты веток, фактические подтверждения доступа и результаты FLOW-10 журнала PoC.
Вариант CI/CD со служебными деплойными ветками
Альтернативные исходные условия того же вымышленного проекта: раньше команда деплоила только ветку develop на один общий стенд, а остальные изменения проверялись на компьютерах разработчиков. Произвольную feature-ветку CI/CD развернуть не умеет. Для агента подготовлены независимые DEV-1 и DEV-2; изменена привязка CI/CD, добавлены две служебные ветки.
Это пример схемы, аналогичной описанному подходу Модуля Сбора, а не описание его текущих настроек. Обозначения SHA-A1 и SHA-B1 ниже заменяют полные идентификаторы commit в реальном документе.
| Задача | Рабочая ветка и исходный commit | Выделенная среда | Служебная ветка | Сборочный артефакт |
|---|---|---|---|---|
| APP-42: ограничение текста | agent/APP-42-summary-limit, SHA-A1 | DEV-1 | deploy/dev-1 → SHA-A1 | image-A1 с неизменяемым digest |
| APP-43: новое поле | agent/APP-43-new-field, SHA-B1 | DEV-2 | deploy/dev-2 → SHA-B1 | image-B1 с неизменяемым digest |
Первый деплой
Агент резервирует DEV-1 под APP-42 и получает идентификатор резервирования. Уполномоченный CI-механизм переназначает deploy/dev-1 точно на SHA-A1. Это разрешённое принудительное обновление только служебной ветки; feature-ветка и её MR не переписываются.
Pipeline фиксирует SHA-A1, собирает его и публикует image-A1 в хранилище. Под блокировкой изменений DEV-1 проверяет актуальность запроса и выполняет деплой image-A1 по digest. Агент проверяет фактическую версию, данные и smoke-сценарий, затем тестирует задачу.
Одновременно такой же путь проходит APP-43 на DEV-2. Обе задачи проверяются до merge в main и не зависят от включения в общий develop. Разделены не только ветки, но и данные, моки и фоновые операции сред.
Новая ревизия и смена задачи
После замечания агент создаёт SHA-A2 в feature-ветке APP-42. Новый запрос на DEV-1 переназначает служебную ветку на SHA-A2 и публикует отдельный image-A2. Доказательства проверки A1 сохраняются; новые проверки относятся к A2.
Когда DEV-1 выделяют следующей задаче APP-44, меняется идентификатор резервирования, а deploy/dev-1 указывает на её точный commit. Старый pipeline A1/A2, даже если ещё завершается, не получает право деплоить: проверка актуальности запроса и блокировка действуют непосредственно при изменении среды. Проверка этого случая включена в PoC.
При смене задачи применяется инструкция подготовки БД: при несовместимой истории миграций восстанавливается совместимый исходный комплект схемы и данных, затем применяются изменения целевой ревизии. Моки и таймеры приводятся в исходное состояние. Смена указателя Git сама этого не делает; пример с двумя ветками показывает порядок восстановления.
Ревью, приёмка и границы полномочий
MR остаётся agent/APP-42-summary-limit → main, ревью проводится по feature-ветке. В MR добавляются ссылки на SHA, pipeline, digest и результаты проверки; deploy/dev-1 не используется как ветка для продуктового слияния.
Для приёмки уполномоченный исполнитель запускает деплой выбранного image-A2 из хранилища на UAT. Если старый CI вынуждает заново собирать тот же SHA для UAT, результат получает новый ID и собственные необходимые проверки.
В карте прав записано: CI-аккаунт может пересоздавать/принудительно обновлять только deploy/dev-1 и deploy/dev-2; merge в main выполняет Алексей по прежним условиям. Использование служебной ветки не разрешает прямую запись в main, обход ревью или изменение занятой UAT.