Первый самостоятельный релиз сервиса: что проверить до и после обновления

Приложение уже работает на сервере, и нужно поставить новую версию. На тестовом ноутбуке она запускается. Самая важная оставшаяся задача — сделать изменение объяснимым: что именно будет заменено, как заметить ухудшение и какое действие доступно, если проверка не пройдёт.

Для небольшого HTTP-сервиса достаточно компактного плана, привязанного к реальной архитектуре. Возьмём один экземпляр приложения, reverse proxy и отдельную базу. В этом устройстве замена единственного процесса может прервать запросы; команда не должна обещать бесшовное обновление только потому, что использует контейнеры.

Назовём изменяемую версию

Перед релизом сохраните идентификатор текущего артефакта и кандидата: digest образа либо иной неизменяемый номер сборки. Ветка main и тег latest могут поменяться после проверки. Для воспроизводимого решения нужны именно те байты, которые прошли тесты, и возможность снова получить прежнюю версию.

Рядом зафиксируйте версию конфигурации и миграций. Один и тот же образ с другим адресом базы — уже другое рабочее состояние. Секреты в план не копируют: достаточно ссылки на управляемый источник и имени набора конфигурации. Полезно заранее проверить, кто имеет доступ к выполнению релиза и где будет сохранён результат.

Отдельно разберём изменение данных

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

Для учебного релиза выберите совместимое расширение схемы: сначала добавление, затем использование новым приложением, а удаление старого — отдельным изменением после перехода. Перед реальной операцией подтвердите резервную копию и способ восстановления на изолированном окружении. Факт создания файла backup не подтверждает его пригодность к восстановлению.

Сформулируем проверку через действие пользователя

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

До релиза выполните ту же проверку на старой версии и сохраните результат. После релиза повторите её через обычный клиентский маршрут, включая proxy. Так сравнивается одно и то же действие. Успешный запрос непосредственно в контейнер не подтверждает, что внешняя маршрутизация работает.

Определим момент остановки

Заранее выберите признаки, при которых продолжение недопустимо: провал пользовательской проверки, рост ошибок или превышение согласованной задержки. Порог должен иметь окно и базу сравнения. «Посмотреть графики» оставляет решение на самую напряжённую минуту; «проверить долю 5xx за пять минут относительно обычного диапазона» уже задаёт объект наблюдения.

Не считайте отсутствие данных нулевой ошибкой. После изменения labels или сбоя scrape dashboard способен замолчать именно тогда, когда нужен. Поэтому отдельно проверьте свежесть измерений и доступность самого сервиса. Для редкого трафика синтетический запрос даёт более быстрый сигнал, чем ожидание случайного пользователя.

Проведём релиз как последовательность состояний

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

Если проверка провалилась, выполните заранее выбранное действие: остановить распространение, вернуть совместимую версию или применить исправление. Повторное выполнение deploy должно иметь понятный смысл, особенно для миграций. Скрипт, который при каждом повторе создаёт новый объект, требует дополнительной защиты.

Самый полезный результат первого релиза — короткая воспроизводимая инструкция именно для этого сервиса. После выполнения уберите из неё лишние догадки и добавьте сведения, которые понадобились на практике. Дальнейшая автоматизация перенесёт уже проверенную последовательность в CI/CD, сохранив точки контроля и условия остановки.

Ещё по теме

• Connection refused: как проверить, где приложение слушает порт
• Linux, Docker или CI/CD: с чего продолжить обучение после первого приложения

Продолжить изучение

Хотите связать Linux, контейнеры и автоматический деплой в один рабочий процесс? Посмотрите программу «DevOps-инженер с нуля: полный курс».