Что на самом деле происходит при деплое: размещение артефактов в средах

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

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

Деплой не универсален

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

Деплой базы данных — совсем другое дело. Вы не заменяете файлы; вы запускаете миграционные скрипты, которые изменяют схемы или преобразуют данные. База данных хранит состояние — записи пользователей, заказы, конфигурации — которое должно оставаться согласованным до, во время и после изменений. Вы не можете просто «перезаписать» базу данных, как заменяете JAR-файл. Миграция, добавляющая колонку, может быть безопасной, но переименование таблицы способно сломать все выполняющиеся запросы. И в отличие от кода приложения, изменения в базе данных часто необратимы или требуют тщательно подготовленных скриптов отката.

Деплой инфраструктуры добавляет ещё один уровень сложности. Здесь вы применяете конфигурацию к облачным провайдерам или инструментам управления типа Terraform, Pulumi или Ansible. Деплой создаёт, изменяет или уничтожает ресурсы: виртуальные машины, балансировщики нагрузки, базы данных, сетевые правила. Ошибка в деплое инфраструктуры может удалить продакшен-базу данных или открыть доступ к конфиденциальным данным из интернета. Ставки высоки, а цикл обратной связи медленнее, чем при деплое приложений.

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

flowchart TD subgraph App["Деплой приложения"] A1["Замена инстансов"] --> A2["Rolling / Blue-Green / Canary"] A2 --> A3["Минимальные перебои"] end subgraph DB["Деплой базы данных"] D1["Запуск миграций"] --> D2["Изменение схемы / преобразование данных"] D2 --> D3["Всё или ничего; нужен откат"] end subgraph Infra["Деплой инфраструктуры"] I1["Применение конфигурации к облаку"] --> I2["Создание / изменение / удаление ресурсов"] I2 --> I3["Медленная обратная связь; высокие риски"] end

Разные стратегии для разных артефактов

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

Для приложений существует несколько известных стратегий:

Например, манифест Kubernetes Deployment для rolling update может выглядеть так:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2.1.0
        ports:
        - containerPort: 8080
  • Rolling update: замена инстансов по одному. Старая версия постепенно уступает место новой. Без даунтайма, но старая и новая версии некоторое время работают одновременно.
  • Blue-green: разворачивается полностью новое окружение (green) рядом с текущим (blue). Когда green готов и проверен, весь трафик переключается на него. Мгновенное переключение, но двойные затраты на инфраструктуру во время перехода.
  • Canary: новая версия отправляется небольшой подгруппе пользователей. Ведётся мониторинг ошибок и производительности. Если всё хорошо, трафик постепенно увеличивается. Если нет — canary откатывается без влияния на большинство пользователей.

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

У баз данных такой роскоши нет. Нельзя одновременно запустить две версии схемы и ожидать согласованного поведения. Rolling update для миграции базы данных редко возможен, потому что изменение схемы глобально — каждый запрос видит одну и ту же структуру. Canary-деплой для баз данных столь же сложен. Можно запустить миграцию на реплике, но как только она станет primary, изменения затронут всех пользователей. Изменения в БД обычно работают по принципу «всё или ничего»: вы применяете миграцию, проверяете её, и если что-то пошло не так — запускаете откат.

Деплой инфраструктуры находится где-то посередине. Можно использовать blue-green для инфраструктуры, развернув параллельный набор ресурсов и переключив DNS или балансировщик. Но изменения инфраструктуры часто имеют зависимости: нельзя создать новый экземпляр БД, не обновив конфигурацию приложения, которая на него указывает. К тому же изменения инфраструктуры могут быть медленными — развёртывание нового кластера серверов может занять минуты, а не секунды.

Два незыблемых принципа

Независимо от того, что вы деплоите и какую стратегию выбираете, два принципа применимы к каждому деплою.

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

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

Второй: каждый деплой должен быть записан. Логируйте, что было развёрнуто, какая версия, какой коммит, какая среда, точное время и кто или что инициировало деплой. Это не бумажная работа для аудиторов. Это ваша первая линия обороны, когда что-то идёт не так. Когда пользователи начинают сообщать об ошибках после деплоя, лог деплоя точно скажет, что изменилось. Без него вы гадаете. Это было изменение кода? Обновление конфигурации? Миграция БД? Изменение инфраструктуры? Хороший лог деплоя сразу сужает круг поиска.

Деплой не заканчивается размещением артефакта

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

Верификация после деплоя — это отдельный этап. Он проверяет, что сервис отвечает на health checks, что миграция БД завершилась без ошибок, что ресурсы инфраструктуры находятся в желаемом состоянии. Некоторые команды запускают smoke-тесты — быстрый набор критических пользовательских сценариев — чтобы убедиться, что деплой ничего не сломал.

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

Практический чек-лист перед следующим деплоем

Прежде чем нажать кнопку «деплой» или запустить пайплайн, пробегитесь по этому короткому списку:

  • Является ли артефакт тем же самым, который прошёл все тесты? (Никакой пересборки во время деплоя.)
  • Находится ли целевая среда в известном состоянии? (Никаких ручных изменений, которые могут вызвать конфликт.)
  • Соответствует ли стратегия деплоя типу артефакта? (Rolling для приложений, миграции для БД, provisioning для инфраструктуры.)
  • Есть ли план отката? (Можно ли быстро отменить изменения? Для БД — готов ли скрипт отката миграции?)
  • Будет ли деплой автоматически залогирован? (Версия, коммит, время, инициатор.)
  • Есть ли этап верификации после деплоя? (Health checks, smoke-тесты или мониторинг.)

Вывод

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