Шаблон: ветки, MR и код-ревью
Заполнить для репозиториев выбранного потока. Инструкция определяет, как изменение кода проходит от ветки до интеграции. Статусы и переходы задачи — в процессе трекера; запуск агентов, паузы HITL и адресаты их запросов — в маршруте работы с агентами.
Заполненный пример. Режимы проверки — в регламенте ревью.
1. Паспорт и права
- Область, репозитории, версия документа, владелец: …
- Подтвердившие, дата и ссылка: …
- Связанный процесс задач: …; маршрут работы с агентами, если применяется: …
| Репозиторий | Аккаунт / роль исполнителя | Разрешённые операции | Защищённые ветки и ограничения | Кто выполняет merge / выпуск | Подтверждение доступа |
|---|---|---|---|---|---|
| … | … | … | … | Имя | Проверка сети, аутентификации и операций |
Права берутся из реестра Git-доступов; здесь достаточно ссылки на актуальные строки. Не дублировать секреты или приписывать аккаунту непроверенные права.
2. Ветки и изменения
| Правило | Значение проекта |
|---|---|
| От какой ветки/ревизии начинается работа и как проверяется её актуальность | … |
| Именование рабочей ветки и связь с ID задачи | … |
| Границы ветки: задача, часть задачи, несколько репозиториев | … |
| Целевая ветка MR и владелец её выбора | … |
| Именование/содержание коммитов, допустимый состав изменений | … |
| Когда и как обновляется ветка: merge/rebase по принятому процессу | … |
| Кто разбирает конфликты и когда подключается человек | … |
| Правила переписывания истории / force push, если вообще разрешены | … |
| Как ведутся связанные MR кода, тестов и других репозиториев | … |
| Что происходит с веткой после merge, отмены или передачи человеку | … |
Выбранная модель может быть trunk-based, с release-ветками или иной действующей моделью клиента. Существующую схему сохраняют, если она обеспечивает независимую проверку выбранной ревизии задачи на подготовленной среде. Если развёртывается только одна общая ветка на один стенд, нужно адаптировать CI/CD и при необходимости правила веток. Одних договорённостей об очереди задач и локального тестирования разработчиком для параллельной работы агента недостаточно. Полномочия на запись, merge, удаление веток и переписывание истории фиксируются отдельно.
Развёртывание ревизии задачи
Цель — выбрать точную ревизию задачи, собрать её и выполнить деплой опубликованного артефакта на выделенную среду, без предварительного включения задачи в общую интеграционную ветку. Выбрать способ:
| Вариант | Что заполнить |
|---|---|
| CI/CD принимает исходную ревизию и целевую среду | Как фиксируется commit SHA, запускается сборка, выбирается среда и передаётся неизменяемый ID артефакта |
| CI/CD собирает feature-ветки, деплой выбирает готовый артефакт | Как найти артефакт нужной ревизии и независимо запустить его деплой |
| CI/CD привязан к фиксированным веткам | Карта служебных деплойных веток по средам и порядок их пересоздания/переназначения на commit задачи |
Выбранный вариант, ограничения и работы по адаптации: … . Если схема ещё не готова, указать зависимые кейсы и срок готовности, а не отмечать независимый деплой как выполненный.
При использовании служебных деплойных веток заполнить:
| Среда | Деплойная ветка | Кто резервирует среду и обновляет ветку | Разрешённое пересоздание / принудительное обновление | Pipeline сборки и деплоя | Где фиксируется связь с исходной ревизией |
|---|---|---|---|---|---|
| … | … | Аккаунт / роль | Точный перечень веток и условия | … | Задача → feature-ветка → SHA → pipeline → ID артефакта → запись деплоя |
Деплойная ветка — служебная ссылка на выбранный commit, запускающая существующий CI/CD. Она не является веткой разработки, местом накопления задач или целью продуктового MR. Код и ревью остаются в feature-ветке и её MR. Пересоздание или принудительное обновление разрешается только для явно перечисленных служебных веток; оно не расширяет полномочия на feature-, main- или release-ветки.
Порядок резервирования среды, смены задачи, очистки состояния и защиты от запоздалых pipeline — по гайду инфраструктуры. Для новой сборки сохраняется точный SHA: имя переиспользуемой ветки не идентифицирует проверенную версию.
Инструкция подготовки БД при смене ветки, исходные комплекты схемы/данных и временные ручные шаги: … (форма). Смена ветки не отменяет применённые ранее миграции; подготовка БД и деплой входят в одну защищённую от конкурирующих запусков операцию.
3. Жизненный цикл MR
Состояния ниже смысловые; сопоставить с реальными статусами, метками, approvals и обсуждениями Git-системы.
| Состояние / событие | Действие и исполнитель | Проверки и условия | Решение / ответственная роль | Следующее состояние / связь с задачей |
|---|---|---|---|---|
| Создание MR / черновик | … | … | … | … |
| Готов к ревью | … | … | … | … |
| Ревью кода и тестов | … | … | Назначенные ревьюеры клиента | … |
| Запрошены изменения | … | … | … | … |
| Исправления готовы | … | … | … | … |
| Одобрен, ожидает интеграции | … | … | … | … |
| Merge выполнен | … | … | … | … |
| MR закрыт без merge / передан человеку | … | … | … | … |
Состав ревьюеров и необходимые решения задаются правилами команды. Включение агента и изменение маршрута между PoC и Пилотом описываются в работе с агентами; они не меняют требования к содержанию ревью автоматически.
4. Состав MR и передача на ревью
- Задача, причина изменения и реализованное поведение: …
- Границы изменения, целевая ветка и связанные MR: …
- Миграции, совместимость, влияющие на интеграцию ограничения: …
- Выполненные проверки с версиями, результатами и ссылками; что не проверено и почему: …
- Признаки риска, требуемые ревьюеры и ожидаемые действия: …
- Команды или инструкции воспроизведения, если нужны: …
| Вид проверки | Кто проверяет | Режим: все / риск и выборка | Обязательные основания подробного ревью | Где фиксируется решение |
|---|---|---|---|---|
| Код продукта | … | … | … | … |
| Код и смысл автотестов | … | … | … | … |
| Архитектура / миграции / контракты по риску | … | … | … | … |
| Продуктовая приёмка, связанная с MR | … | По процессу продукта | … | … |
Режимы кода и тестов задаются отдельно. Уменьшение глубины проверки не следует автоматически из начала Пилота. Права и условия выборки — по регламенту клиента.
5. Замечания и повторное ревью
| Ситуация | Действие исполнителя | Кто решает / как подтверждается |
|---|---|---|
| Подтверждённый недостаток исходного результата | Исправление, нужные проверки, ответ со ссылкой на изменения и результат | … |
| Неоднозначное или противоречивое замечание | Запрос решения ответственному; для агента применяется маршрут HITL | … |
| Новое требование | Фиксация изменения объёма, не скрытая бесконечная доработка | … |
| Изменились код, тесты или база после проверки | Обновление доказательств и повторная проверка по правилам проекта | … |
| Замечание не принято | Аргументированный ответ и решение владельца вопроса | … |
Указать, кто может закрывать обсуждения: … . Статус обсуждения не является доказательством исправления. Ответ автора не заменяет решение назначенного ревьюера.
Указать условия сохранения/сброса approvals и повторного ревью после новых коммитов или обновления базы: … . Результат проверки должен относиться к фактически интегрируемой версии. Предел повторных запусков агента и передача выполнения человеку — по маршруту работы с агентами.
6. Условия merge и дальнейшие действия
| Условие | Проверяемое подтверждение | Кто проверяет |
|---|---|---|
| Нужные ревью выполнены, обязательные замечания закрыты по существу | … | … |
| Обязательные проверки относятся к интегрируемой версии | … | … |
| Целевая ветка актуальна, конфликты и связанные изменения обработаны | … | … |
| Критерии продуктовой приёмки выполнены на нужном шаге процесса | … | … |
| Интеграцию выполняет уполномоченный участник/механизм | … | … |
- Способ merge и сведения, сохраняемые в трекере: …
- Кто и как подтверждает фактическое успешное слияние: …
- Как merge/выпуск связан с завершением задачи: ссылка на правило трекера …
- Процедура дальнейшей сборки, публикации артефакта и деплоя: …
Merge не означает автоматический выпуск. Для всех стендов: исходный код → сборка → хранилище артефактов → деплой по ID. Если приёмка проводится до merge, её доказательства связываются с проверенной ревизией; изменения после приёмки требуют проверки затронутого поведения.