Зеленый pipeline не всегда означает успешный деплой. Он мог собрать артефакт, но не доставить его туда, где работает production.

Почему это важно

Частые причины: деплой идет в другой каталог или environment, docker tag не обновляется, сервис не перезапускается, CDN отдает старые файлы или pipeline проверяет не тот шаг.

Что проверяю в первую очередь

  • Какой commit реально работает на сервере.
  • Куда pipeline кладет artifact.
  • Обновляется ли docker image/tag.
  • Перезапускается ли сервис после деплоя.
  • Не держит ли старую версию кеш CDN или браузера.

Как исправляю

Я сверяю pipeline с реальным production: commit hash, путь файлов, контейнер, restart и публичный результат.

  • Проверяю логи deploy job.
  • Сверяю artifact и путь на сервере.
  • Добавляю вывод версии/commit на приложение.
  • Исправляю restart или image tag.
  • Проверяю сайт после сброса кеша.

Что будет после исправления

  • Новая версия реально появляется на сайте.
  • Pipeline проверяет важные этапы деплоя.
  • Проще понять, какой commit в production.
  • Релизы становятся предсказуемыми.

Что подготовить

  • Конфиг CI/CD.
  • Логи успешного pipeline.
  • Доступ к серверу или registry.
  • Ожидаемый commit/version.

Вопросы и ответы

Можно ли решить точечно?

Да. Часто проблема в последнем шаге deploy: путь, restart, tag или cache.

Почему не стоит откладывать?

Команда может считать, что исправление вышло, хотя пользователи продолжают видеть старую версию.

Нужна похожая задача?

Опишите проблему и пришлите ссылку, скрин или лог. Я разберу причину, предложу понятный план исправления и не буду обещать результат без первичного просмотра.