Деплой: активное действие по размещению артефакта в среде

Вы собрали приложение, упаковали его в артефакт и сохранили в репозитории. Что дальше? Артефакт, лежащий в репозитории — это просто файл. Он становится полезным только когда попадает в среду и реально запускается. Этот процесс размещения и запуска инженеры называют деплоем.

Деплой — это не пассивное состояние. Это активное действие. До деплоя ваше staging-окружение работает на версии 1.1.0. После деплоя — на версии 1.2.0. В среде что-то изменилось. Кто-то или что-то взял артефакт, переместил его на нужный сервер и запустил.

Что на самом деле происходит во время деплоя

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

Вот конкретный пример того, как эти шаги выглядят в виде shell-команд:

scp myapp-v1.2.0.jar user@staging-server:/opt/myapp/ && \
ssh user@staging-server "systemctl stop myapp && \
  cp /opt/myapp/myapp-v1.2.0.jar /opt/myapp/current.jar && \
  systemctl start myapp"

Именно поэтому деплой отличается от простого хранения файлов. У вас может быть идеальный репозиторий артефактов с каждой когда-либо собранной версией, но пока эти артефакты не размещены в средах и не запущены, ничего не доставлено. Деплой — это мост между «мы это собрали» и «это работает где-то».

Следующая диаграмма последовательности иллюстрирует разделение между деплоем и релизом:

sequenceDiagram participant AR as Artifact Registry participant DT as Deployment Tool participant S as Server participant LB as Load Balancer DT->>AR: Pull artifact v1.2.0 DT->>S: Transfer artifact DT->>S: Stop old process (v1.1.0) DT->>S: Start new process (v1.2.0) DT->>S: Verify health S-->>DT: Healthy Note over DT,LB: Deployment complete DT->>LB: Switch traffic to v1.2.0 Note over DT,LB: Release happens

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

Деплой против релиза

Деплой — это техническое действие. Вы размещаете артефакт в среде и запускаете его. Релиз — это про доступ. Он отвечает на вопрос: когда пользователи начнут использовать новую версию?

Представьте, что ваша команда деплоит версию 1.2.0 на продакшн в 2:00 ночи. Продакшн-серверы теперь работают на новой версии, но команда намеренно не направляет на неё пользовательский трафик. Деплой произошёл. Релиз — нет. Пользователи всё ещё на старой версии. Команда может проверить, что новая версия здорова, прежде чем открыть дверь.

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

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

Деплой не всегда проходит гладко

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

Вот почему каждый деплой требует проверки. После того как артефакт размещён и запущен, кто-то или что-то должен проверить, что среда действительно работоспособна. Отвечает ли приложение на запросы? Чистые ли логи? Находятся ли ожидаемые метрики в пределах нормы?

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

Практические выводы

Как только вы начинаете воспринимать деплой как активное действие, а не пассивное состояние, несколько вещей становятся понятнее.

Во-первых, деплой повторяем. Если вы можете задеплоить версию 1.2.0 сегодня, вы должны иметь возможность задеплоить версию 1.2.0 завтра в ту же среду с тем же результатом. Если это не так, в вашем процессе деплоя есть скрытые шаги или зависимости.

Во-вторых, деплой обратим. Если версия 1.2.0 вызывает проблемы, вы должны иметь возможность задеплоить версию 1.1.0 обратно в ту же среду. Это и есть откат. Если откат болезненен или рискован, ваш процесс деплоя нуждается в улучшении.

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

Простой чеклист деплоя

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

  • Артефакт размещён в правильной среде?
  • Новая версия действительно запущена и принимает трафик?
  • Базовые проверки работоспособности проходят (коды ответов, задержки, уровень ошибок)?
  • Можете ли вы подтвердить, что старая версия больше не работает (если вы не делаете постепенный rollout)?
  • Знаете ли вы, как откатиться в случае необходимости, и проверен ли этот путь отката?

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

Резюме

Деплой — это момент, когда ваш артефакт перестаёт быть файлом и становится работающим сервисом. Это активное, повторяемое, обратимое и проверяемое действие. Разделение деплоя и релиза даёт вам контроль над тем, когда пользователи видят изменения. Проверка каждого деплоя не даёт вам обнаруживать проблемы после того, как их нашли пользователи.

В следующий раз, когда ваша команда скажет «мы задеплоили», спросите: мы действительно разместили артефакт и проверили, что он работает? Или мы просто нажали кнопку и надеемся? Ответ покажет, насколько зрелый у вас процесс деплоя.