Релиз без сюрпризов: от сборки до отката

Один артефакт на весь путь

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

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

Миграция должна пережить две версии

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

Откат приложения не отменяет миграцию. Удаление данных и смену форматов нужно разбирать отдельно, включая резервную копию и процедуру восстановления.

Готовность важнее факта запуска

В Kubernetes readiness определяет готовность Pod получать трафик через Service. Startup probe даёт приложению время запуститься, а liveness помогает перезапустить зависший контейнер. Эти проверки отвечают на разные вопросы.

# Пример проверки уже настроенного Deployment
kubectl rollout status deployment/web --timeout=180s
kubectl get pods -l app=web
kubectl describe deployment/web

Имена условные. Выполняйте команды в нужном контексте и namespace. После завершения rollout отдельно проверьте пользовательский сценарий через внешний адрес.

Наблюдение и решение об откате

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

Перед выпуском можно пройти интерактивную памятку и скачать её текстовую версию.