Готовность релиза: чек-лист гейтов

Что это за сервис

Чек-лист готовности релиза для релиз-менеджера, владельцев гейтов и руководителя разработки. Гейт — условие выпуска: пройденные тесты, согласование безопасности, обновлённая документация, настроенные фича-флаги. Сервис собирает все гейты версии в один список с владельцами и сроками и фиксирует решение «выпускать или нет».

Без чек-листа условия выпуска разбросаны по дашборду CI, трекеру задач, вики и чатам. Релизное совещание полчаса выясняет, что уже пройдено. Блокеры всплывают в день выкатки, хотя могли быть видны за несколько дней. Владелец гейта не назначен явно, поэтому, когда проверка встала, непонятно, кто её разблокирует, а после неудачного релиза цепочку решений восстанавливают неделю.

Что он делает

Собирает гейты версии в один список. Тесты, безопасность, документация, флаги и другие условия привязаны к версии релиза и видны на одной странице.
Создаёт чек-лист из шаблона. Для каждого типа релиза свой набор гейтов: хотфиксу хватает двух, мажорной версии нужно двенадцать. При новом релизе шаблон копируется, и все гейты начинаются с нуля.
Назначает владельцев и сроки. У каждого гейта есть ответственный и целевая дата, а у ответственного — заместитель на время отсутствия.
Заранее показывает блокеры. Гейт, не закрытый к своей дате, подсвечивается и уведомляет релиз-менеджера за дни до выкатки.
Фиксирует решение о выпуске. Релиз получает статус «Одобрен», только когда пройдены все критичные гейты; исключения и решения записываются в журнал.

Нюансы и особенности

Чек-лист поверх CI, а не вместо него. Результат пайплайна — один из гейтов, который подтягивается автоматически. Если релизы выходят с каждой слитой веткой и все проверки автоматические, хватит защиты веток и правил окружений в GitHub или GitLab; отдельный чек-лист нужен, когда есть ручные согласования, внешние стороны или регламентные требования.
Гейт без владельца невидим. Гейт нельзя создать без ответственного. Если владелец в отпуске, гейт переходит заместителю, и уведомление о блокере уходит ему.
Статус «в работе» устаревает. Гейт, застрявший в работе после своей даты, автоматически становится блокером, а не остаётся «почти готов».
Одобрение заблокировано правилом. Переключатель «выпускать» недоступен, пока открыт хотя бы один критичный гейт. Обойти это можно только явным исключением с причиной и автором.
Шаблон копируется, а не переиспользуется. Если отмечать галочки в одном и том же списке для каждого релиза, данные прошлого релиза смешиваются с текущим. История предыдущих чек-листов остаётся для разбора.
Автоматические гейты честнее ручных. Результаты CI, регрессий и бюджетов производительности подтягиваются из своих систем; вручную отмечают только то, что автоматизировать нельзя.
Журнал решений. Каждая смена статуса гейта и релиза записывается с автором и временем, и разбор неудачного релиза начинается с готовой хронологии.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат перед следующим шагом.

1. Данные и модели

Создай модели и миграции для готовности релиза: ReleaseType (название),
GateTemplate (тип релиза, название гейта, критичность, владелец
по умолчанию, заместитель, смещение срока от даты выпуска, признак
автоматического гейта), Release (версия, тип, плановая дата, статус:
подготовка, одобрен, выпущен, отменён), Gate (релиз, название,
критичность, владелец, заместитель, срок, статус: не начат, в работе,
пройден, не пройден), ReleaseLog (релиз, объект, действие, автор, время,
причина). Владелец гейта обязателен. Добавь фабрики.

2. Релиз из шаблона

Сгенерируй Filament-ресурсы для ReleaseType с шаблонами гейтов и для
Release. При создании релиза копируй гейты из шаблона его типа со
статусом «не начат» и сроками от плановой даты. В карточке релиза выведи
гейты через relation manager с быстрыми действиями смены статуса.

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

3. Правила одобрения

Запрети переход Release в «Одобрен», пока есть критичный гейт не в статусе
«пройден». Добавь действие «Одобрить с исключением» только для
руководителя разработки, с обязательной причиной. Каждое изменение гейта
и релиза пиши в ReleaseLog.

4. Автоматические гейты и блокеры

Сделай приём результатов CI по вебхуку с проверкой подписи: автоматический
гейт «Тесты» релиза меняет статус по результату пайплайна его версии.
Сделай задачу по расписанию, которая помечает гейты с истёкшим сроком
как блокеры и уведомляет владельца, а если владелец отмечен отсутствующим —
заместителя, плюс релиз-менеджера.

Отметьте владельца гейта отсутствующим и убедитесь, что уведомление о блокере получает заместитель.

5. Роли и доска релизов

Настрой роли: владелец гейта меняет только свои гейты, релиз-менеджер —
все гейты и релизы, одобрение с исключением — только руководитель.
Добавь доску ближайших релизов с долей пройденных гейтов и числом
блокеров и экспорт журнала решений по релизу.