Шаблон развертывания, который действительно используют

В каждой команде был тот самый деплой, который пошел не по плану, потому что кто-то забыл шаг. Может, артефакт сборки так и не попал в registry. Может, smoke-тесты пропустили, потому что «это же просто мелкое изменение». Может, план отката обсуждали на созвоне, но так и не записали — и когда что-то сломалось, никто не мог договориться, что делать.

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

Шаблон развертывания решает это. Это не бюрократический документ. Это страховочная сеть.

Что делает шаблон развертывания

Шаблон развертывания — это список шагов, которые должны выполняться каждый раз, когда вы пушите новую версию приложения в любое окружение. Он не говорит, как делать вашу работу. Он говорит, что нельзя забыть.

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

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

flowchart TD A[Build and Verify] -->|pass| B[Deploy to Staging] A -->|fail| A B -->|pass| C[Deploy to Production] B -->|fail| A C -->|pass| D[Rollback Plan] C -->|fail| D D -->|rollback triggered| A D -->|no rollback| E[Deployment Complete]

Фаза первая: сборка и проверка

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

Шаги просты:

Вот workflow GitHub Actions, который реализует первую фазу для Node.js приложения:

name: Build and Verify
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test
      - run: npm run build
      - name: Push Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} registry.example.com/myapp:${{ github.sha }}
          docker push registry.example.com/myapp:${{ github.sha }}

Этот workflow запускается при каждом пуше в main, выполняет тесты, собирает приложение и пушит Docker-образ в registry. Если любой шаг завершается ошибкой, деплой останавливается автоматически.

  • Получить код из правильной ветки. Не из той, которая кажется правильной. Из той, которую вы действительно проверили.
  • Запустить сборку. Она создает артефакт — Docker-образ, JAR-файл, скомпилированный бинарник, что использует ваш стек.
  • Запустить модульные и интеграционные тесты. Они подтверждают, что код ведет себя как ожидается и что части системы работают вместе.
  • Проверить ошибки и предупреждения, которые остановят процесс. Сборка с предупреждениями все еще считается успешной, но некоторые предупреждения сигнализируют о реальных проблемах.
  • Загрузить артефакт в registry, доступный для целевых окружений. Если артефакт не сохранен, вы не сможете развернуть его позже.

Если любой шаг в этой фазе завершается ошибкой, деплой останавливается. Вы исправляете код и начинаете заново. Без исключений.

Фаза вторая: деплой на стейджинг

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

Шаги здесь включают:

  • Забрать артефакт из registry. Используйте тот же самый артефакт, который прошел первую фазу.
  • Развернуть на стейджинге. Используйте тот же механизм деплоя, что и в продакшне.
  • Запустить smoke-тесты. Это быстрые проверки, которые подтверждают, что приложение отвечает на запросы, подключается к базе данных и общается со своими зависимостями.
  • Проверить логи на предмет неожиданных ошибок. Здоровое приложение выдает предсказуемые логи. Все необычное стоит исследовать.
  • Запустить интеграционные тесты, которым нужно полное окружение. Некоторые тесты имеют смысл только когда вся система работает.

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

Фаза третья: деплой в продакшн

Это критическая фаза. Реальные пользователи зависят от вашего приложения. Ошибки здесь влияют на реальную работу.

Продакшн-деплой должен быть постепенным. Blue-green деплой, canary releases или rolling updates — все подходит. Ключ в том, что вы не заменяете все сразу.

Шаги:

  • Убедиться, что нет другого активного деплоя. Два деплоя одновременно создают хаос.
  • Забрать тот же артефакт, который прошел стейджинг. Не пересобирать. Использовать проверенный артефакт.
  • Развернуть, используя выбранную стратегию. Если используете canary releases, начните с небольшого процента трафика.
  • Мониторить метрики: время ответа, процент ошибок, загрузку CPU, потребление памяти, пропускную способность запросов. Эти цифры говорят, здорова ли новая версия.
  • Запустить health checks и smoke-тесты после деплоя. Они подтверждают, что приложение действительно корректно обслуживает трафик.

Если метрики выглядят плохо, не ждите. Запускайте откат.

Фаза четвертая: план отката

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

План отката отвечает на три вопроса:

  • Когда откатывать? Определите триггер. Например: процент ошибок превышает 5%, время ответа увеличилось на 50% или критическая точка перестала отвечать.
  • Как откатывать? Укажите механизм. Это может быть перенаправление трафика на предыдущую версию, повторный деплой старого артефакта или запуск скрипта отката миграции базы данных.
  • Кто принимает решение? Назовите человека или роль, уполномоченную запустить откат. Во время инцидента ожидание консенсуса тратит время.

Запишите план отката. Поделитесь им с командой. Получите согласие до начала продакшн-деплоя.

Практический чек-лист для деплоя приложения

Вот короткий чек-лист, который вы можете адаптировать для своей команды. Он не исчерпывающий, но покрывает essentials.

Сборка и проверка

  • Код получен из проверенной ветки
  • Сборка успешна
  • Модульные и интеграционные тесты пройдены
  • Артефакт загружен в registry

Деплой на стейджинг

  • Артефакт получен из registry
  • Деплой завершен без ошибок
  • Smoke-тесты пройдены
  • Логи не содержат неожиданных ошибок

Деплой в продакшн

  • Нет параллельного деплоя
  • Использован артефакт со стейджинга
  • Применена стратегия постепенного деплоя
  • Метрики мониторились 10-15 минут
  • Health checks пройдены

План отката

  • Определен триггер отката
  • Указан механизм отката
  • Назначен ответственный за решение
  • План согласован до деплоя

Адаптируйте шаблон под свою команду

Команда, которая только начинает, может использовать простую версию: сборка, деплой на стейджинг, деплой в продакшн, откат. Зрелая команда может добавить сканирование безопасности, тесты производительности или approval gates на каждой фазе.

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

Вывод

Шаблоны развертывания существуют, потому что память ненадежна, особенно под давлением. Запишите шаги. Поделитесь ими. Используйте их каждый раз. Когда что-то пойдет не так, вы будете точно знать, что делать — и все остальные в команде тоже.