Журнал деплоев по окружениям
Что это за сервис
Заголовок раздела «Что это за сервис»Журнал деплоев для дежурных инженеров, платформенной команды и тимлидов. Он отвечает на вопрос «что сейчас работает в продакшене»: какая версия каждого сервиса выкачена в каждое окружение, из какого коммита, кем и когда, и какие деплои упали или зависли.
Без журнала статус деплоя разбросан по пайплайнам CI, облачным консолям и чатам. Во время инцидента дежурный тратит четверть часа, чтобы выяснить, какой коммит последним ушёл в продакшен. Откаты проходят без следа, и через несколько дней команда обнаруживает, что изменения молча отменены. Разбор после инцидента превращается в раскопки истории деплоев по четырём источникам.
Что он делает
Заголовок раздела «Что он делает»- Показывает текущую версию по окружениям. Для каждого сервиса видно, что сейчас работает в продакшене, стейдже и канареечном окружении, с коммитом, автором и временем.
- Ведёт полную историю деплоев. Каждый деплой — запись с сервисом, окружением, версией, статусом и ссылкой на пайплайн; историю фильтруют по сервису и периоду.
- Фиксирует откаты с контекстом. Откат хранится отдельной записью со ссылкой на отменённый деплой, инициатором и обязательной причиной.
- Поднимает упавшие и зависшие деплои. Деплой в статусе «Ошибка» дольше заданного времени возвращается автору и видит тимлид.
- Следит за отставанием стейджа. Возраст стейджа и число деплоев, на которое он отстаёт от продакшена, видны на сводке.
Нюансы и особенности
Заголовок раздела «Нюансы и особенности»- Журнал не заменяет CI/CD. Выкатку делают GitHub Actions, GitLab CI, Jenkins или Argo CD, и у многих из них уже есть экран окружений. Если все сервисы деплоятся одним инструментом и его экрана хватает, отдельный журнал не нужен. Приложение на Filament полезно, когда сервисов много, инструменты разные, а историю нужно связать с инцидентами, багами и релизами.
- Деплои не вводят руками. Записи создаёт вебхук или шаг пайплайна; автор деплоя берётся из CI автоматически. Ручной ввод означает пропуски и второй источник правды.
- Вебхуки принимают строго. Подпись проверяется, содержимое валидируется, повторная доставка того же события не создаёт дубль. Журнал только записывает события и не запускает деплой или откат сам.
- Представление по окружению — основное. Главный экран отвечает на вопрос «что сейчас в продакшене» за один клик; плоская лента всех деплоев нужна реже.
- Откат без причины — пробел в истории. Поле причины обязательное, а ссылка на исходный деплой строится автоматически по версии.
- Масштаб решают группировкой. При двадцати и более сервисах таблицу группируют по сервису или команде и добавляют сводку по окружениям; пагинация и индексы по сервису и времени обязательны.
- Пороги — настройки. Допустимое время в статусе «Ошибка» (например 2 часа) и отставание стейджа (например 5 деплоев) задают в конфиге.
Как сгенерировать через ИИ-агентов
Заголовок раздела «Как сгенерировать через ИИ-агентов»Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат каждого шага.
1. Данные и модели
Заголовок раздела «1. Данные и модели»Создай модели и миграции для журнала деплоев: Service (название, команда,репозиторий), Environment (название, порядок, признак продакшена),Deployment (сервис, окружение, версия, коммит, автор, статус: в процессе,успех, ошибка, откат; ссылка на пайплайн, время начала и окончания,ссылка на отменённый деплой, причина отката, внешний id события).Добавь индексы по сервису, окружению и времени и фабрики с демо-данными.2. Текущее состояние по окружениям
Заголовок раздела «2. Текущее состояние по окружениям»Сделай страницу Filament «Сейчас в окружениях»: таблица, где строка —сервис, колонки — окружения, в ячейке последняя успешная версия, автори возраст. Добавь фильтр по команде. Отдельно выведи сервисы, у которыхстейдж отстаёт от продакшена больше чем на порог из конфига.3. История и откаты
Заголовок раздела «3. История и откаты»Сгенерируй Filament-ресурс для Deployment с фильтрами по сервису,окружению, статусу и периоду, группировкой по сервису. Откат показывайотдельным значком со ссылкой на отменённый деплой. Причина откатаобязательна при ручном создании записи.Проверьте, что у каждого отката есть причина и ссылка на исходный деплой.
4. Приём событий из CI
Заголовок раздела «4. Приём событий из CI»Добавь эндпоинт для вебхуков CI: проверка подписи, валидация, сохранениедеплоя идемпотентно по внешнему id события, включая параллельнуюповторную доставку. Автора бери из события. Сделай задачу по расписанию,которая помечает деплои в статусе «Ошибка» дольше порога и уведомляетавтора и тимлида команды.Отправьте одно и то же событие дважды параллельно и убедитесь, что в журнале одна запись.
5. Роли и сводка
Заголовок раздела «5. Роли и сводка»Настрой доступ: инженеры видят журнал только для чтения, ручные записии правку причин отката может делать тимлид или платформенная команда.Добавь виджеты: деплои за неделю по статусам, доля неуспешных деплоеви последние откаты. Добавь экспорт истории за период.Похожие сценарии
Заголовок раздела «Похожие сценарии»- Мониторинг API и SLA эндпоинтов — сопоставление деплоев с нарушениями SLA.
- Управление фича-флагами — включение функциональности без нового деплоя.
- Штаб управления инцидентом — где журнал деплоев нужен в первую очередь.
- Чем отличается от готовности релиза: журнал фиксирует, что и куда уже выкачено, а чек-лист готовности решает, можно ли выпускать версию до выкатки.