Перейти к содержимому

Журнал деплоев по окружениям

Журнал деплоев для дежурных инженеров, платформенной команды и тимлидов. Он отвечает на вопрос «что сейчас работает в продакшене»: какая версия каждого сервиса выкачена в каждое окружение, из какого коммита, кем и когда, и какие деплои упали или зависли.

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

  • Показывает текущую версию по окружениям. Для каждого сервиса видно, что сейчас работает в продакшене, стейдже и канареечном окружении, с коммитом, автором и временем.
  • Ведёт полную историю деплоев. Каждый деплой — запись с сервисом, окружением, версией, статусом и ссылкой на пайплайн; историю фильтруют по сервису и периоду.
  • Фиксирует откаты с контекстом. Откат хранится отдельной записью со ссылкой на отменённый деплой, инициатором и обязательной причиной.
  • Поднимает упавшие и зависшие деплои. Деплой в статусе «Ошибка» дольше заданного времени возвращается автору и видит тимлид.
  • Следит за отставанием стейджа. Возраст стейджа и число деплоев, на которое он отстаёт от продакшена, видны на сводке.
  • Журнал не заменяет CI/CD. Выкатку делают GitHub Actions, GitLab CI, Jenkins или Argo CD, и у многих из них уже есть экран окружений. Если все сервисы деплоятся одним инструментом и его экрана хватает, отдельный журнал не нужен. Приложение на Filament полезно, когда сервисов много, инструменты разные, а историю нужно связать с инцидентами, багами и релизами.
  • Деплои не вводят руками. Записи создаёт вебхук или шаг пайплайна; автор деплоя берётся из CI автоматически. Ручной ввод означает пропуски и второй источник правды.
  • Вебхуки принимают строго. Подпись проверяется, содержимое валидируется, повторная доставка того же события не создаёт дубль. Журнал только записывает события и не запускает деплой или откат сам.
  • Представление по окружению — основное. Главный экран отвечает на вопрос «что сейчас в продакшене» за один клик; плоская лента всех деплоев нужна реже.
  • Откат без причины — пробел в истории. Поле причины обязательное, а ссылка на исходный деплой строится автоматически по версии.
  • Масштаб решают группировкой. При двадцати и более сервисах таблицу группируют по сервису или команде и добавляют сводку по окружениям; пагинация и индексы по сервису и времени обязательны.
  • Пороги — настройки. Допустимое время в статусе «Ошибка» (например 2 часа) и отставание стейджа (например 5 деплоев) задают в конфиге.

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

Создай модели и миграции для журнала деплоев: Service (название, команда,
репозиторий), Environment (название, порядок, признак продакшена),
Deployment (сервис, окружение, версия, коммит, автор, статус: в процессе,
успех, ошибка, откат; ссылка на пайплайн, время начала и окончания,
ссылка на отменённый деплой, причина отката, внешний id события).
Добавь индексы по сервису, окружению и времени и фабрики с демо-данными.
Сделай страницу Filament «Сейчас в окружениях»: таблица, где строка —
сервис, колонки — окружения, в ячейке последняя успешная версия, автор
и возраст. Добавь фильтр по команде. Отдельно выведи сервисы, у которых
стейдж отстаёт от продакшена больше чем на порог из конфига.
Сгенерируй Filament-ресурс для Deployment с фильтрами по сервису,
окружению, статусу и периоду, группировкой по сервису. Откат показывай
отдельным значком со ссылкой на отменённый деплой. Причина отката
обязательна при ручном создании записи.

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

Добавь эндпоинт для вебхуков CI: проверка подписи, валидация, сохранение
деплоя идемпотентно по внешнему id события, включая параллельную
повторную доставку. Автора бери из события. Сделай задачу по расписанию,
которая помечает деплои в статусе «Ошибка» дольше порога и уведомляет
автора и тимлида команды.

Отправьте одно и то же событие дважды параллельно и убедитесь, что в журнале одна запись.

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