Что происходит после завершения пайплайна: пост-действия, очистка и артефакты

Вы только что увидели, как ваш пайплайн стал зелёным. Все тесты пройдены, деплой выполнен, а в командный чат ушло короткое «готово». Большинство закрывает вкладку и переходит к следующей задаче. Но если остановиться на этом, пайплайн остаётся незавершённым.

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

Уведомления, которые действительно помогают

Первое, что должен сделать пайплайн после завершения — сообщить кому-то. Но не все уведомления полезны. Сообщение, в котором просто написано «деплой выполнен» или «сборка упала» — это шум. Оно заставляет людей открывать логи пайплайна, чтобы просто понять, что произошло.

Хорошее уведомление несёт контекст. Оно должно включать:

• Какое изменение было обработано (хэш коммита или ID merge request)
• Кто запустил пайплайн
• В каком окружении прошёл деплой
• Всё ли прошло успешно или что-то упало
• Прямую ссылку на запуск пайплайна

Для небольшой команды достаточно сообщения в чат. Для крупных организаций может потребоваться отправка уведомлений на email, в трекеры задач или дашборды мониторинга. Способ доставки не так важен, как содержание. Если ваше уведомление не помогает человеку решить, нужно ли действовать, это просто ещё один отвлекающий фактор.

Подумайте о человеке, которого вызывают в 2 часа ночи, потому что продакшн ведёт себя странно. Ему нужно сразу узнать: был ли недавний деплой? Кто его сделал? Что изменилось? Хорошо структурированное уведомление отвечает на эти вопросы ещё до того, как кому-то придётся открывать браузер.

Вот практичный YAML-фрагмент для шага уведомления в Slack, который включает необходимый контекст:

notify-slack:
  stage: post-deploy
  image: curlimages/curl:latest
  script:
    - |
      curl -X POST -H "Content-type: application/json" \
        --data "{
          \"text\": \"Deployment complete\",
          \"blocks\": [
            {
              \"type\": \"section\",
              \"text\": {
                \"type\": \"mrkdwn\",
                \"text\": \"*Pipeline finished*\nCommit: \`$CI_COMMIT_SHORT_SHA\`\nAuthor: $GITLAB_USER_LOGIN\nEnvironment: production\nStatus: $CI_JOB_STATUS\nLink: $CI_PIPELINE_URL\"
              }
            }
          ]
        }" \
        $SLACK_WEBHOOK_URL
  only:
    - main

Этот шаг выполняется только на ветке main, отправляет хэш коммита, автора, окружение и прямую ссылку на пайплайн, так что любой получивший сообщение может сразу оценить ситуацию без открытия логов.

Очистка временных ресурсов

Каждый раз, когда запускается пайплайн, создаются временные ресурсы. Рабочая область на раннере. Контейнеры, запущенные для тестирования. Временные тома для хранения. Артефакты сборки, которые были нужны только на этапе сборки. Скачанные зависимости.

Если их не очищать, они накапливаются. Дисковое пространство заканчивается. Раннеры замедляются. И что ещё хуже, остатки от одного пайплайна могут помешать следующему запуску. Тест, который проходит локально, может упасть в CI, потому что в рабочей области остались файлы от предыдущей сборки.

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

Самый безопасный подход — сделать очистку явным шагом в конце пайплайна. Удалите то, что создали. Отмонтируйте то, что смонтировали. Удалите то, что закэшировали. Если ваша платформа пайплайнов обрабатывает часть этого автоматически — отлично. Но добавьте шаг для того, что она может пропустить.

Хранение артефактов: та часть, которую все забывают

Это самое важное пост-действие, и именно его большинство команд пропускает.

Артефакты — это полная запись всего, что происходило во время запуска пайплайна. Не только финальный статус, а полная история:

• Что запустило пайплайн
• Какой коммит был обработан
• Вывод сборки и логи
• Результаты тестов, включая то, какие тесты прошли, а какие упали
• Отчёты сканирования безопасности
• Точный артефакт, который был создан (с его хэшем или URL в реестре)
• Логи деплоя
• Результаты верификации после деплоя

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

Почему это важно? Потому что когда-нибудь кто-то спросит:

• «Та версия, которую мы задеплоили в продакшн три недели назад, проходила ли она сканирование безопасности?»
• «У нас инцидент в продакшне. Было ли то изменение протестировано с миграцией базы данных?»
• «Аудитор хочет увидеть подтверждение, что каждый деплой был проверен перед выходом в продакшн.»

Без артефактов вы не сможете ответить на эти вопросы. Придётся гадать. А гадание при инцидентах в продакшне или аудитах — это то, как портят карьеру.

Как хранить артефакты на практике

Не нужен один гигантский файл, содержащий всё. Это быстро становится неуправляемым. Вместо этого храните ссылки и указатели.

Ваш пайплайн должен создавать сводку, содержащую:

• ID сборки и ссылку на логи сборки
• URL артефакта в вашем реестре
• Ссылку на отчёт о тестировании
• Ссылку на результаты сканирования безопасности
• Расположение логов деплоя
• Любые записи о ручных утверждениях

Эту сводку можно хранить в вашей системе управления изменениями, в объектном хранилище или даже в базе данных. Формат может быть JSON, YAML или обычный текст. Важно, чтобы и люди, и машины могли его прочитать.

Некоторые команды прикрепляют эти артефакты к коммиту или merge request. Другие хранят их в специальном репозитории артефактов. Любой способ работает, если он доступен для поиска и не удаляется автоматически.

Артефакты не только для аудиторов

Да, аудиторы любят артефакты. Но реальная ценность проявляется при отладке.

Когда продакшн падает, первый вопрос всегда: «Что изменилось?» С хорошими артефактами вы можете открыть последний запуск пайплайна и увидеть, что именно произошло. Был ли тест, который упал, но его проигнорировали? Отличался ли артефакт от ожидаемого? Было ли изменение конфигурации, которое никто не задокументировал?

Без артефактов вы отлаживаете вслепую. Вы полагаетесь на память, логи чата и догадки. С артефактами у вас есть фактическая запись того, что действительно произошло.

Завершение цикла пайплайна

Как только уведомления отправлены, ресурсы очищены, а артефакты сохранены, цикл пайплайна действительно завершён. Пайплайн готов к следующему запуску, и та же последовательность повторится.

Этот ритм делает CI/CD надёжным. Каждое изменение проходит один и тот же путь. Каждое изменение оставляет один и тот же след. Каждое изменение создаёт результат, который можно проверить позже.

Краткий чек-лист для этапа пост-действий вашего пайплайна

• Уведомления включают коммит, автора, окружение и статус с прямой ссылкой
• Временные ресурсы очищаются автоматически
• Логи сборки, результаты тестов и отчёты сканирования сохраняются постоянно
• Ссылки на артефакты (URL в реестре, хэш) записываются
• Логи деплоя сохраняются и на них есть ссылка
• Артефакты хранятся в доступном для поиска месте без срока истечения

Конкретный вывод

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