Стратегии развёртывания

Updated Jul 2026

Место тестов в развёртывании

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

Blue-Green-развёртывание

Как это работает

Существуют два идентичных окружения: blue (текущий продакшен) и green (новая версия). Новая версия развёртывается в green. После валидации трафик переключается с blue на green. Если что-то пойдёт не так, переключение обратно происходит мгновенно.

                    Load Balancer
                    /           \
              Blue (v2.3)    Green (v2.4)
              [текущий]      [новый, тестируется]
                              ↑
                         Запуск полного набора тестов здесь
                         перед переключением трафика

Где запускаются тесты

До переключения: запустите полный набор браузерных тестов, интеграционных тестов и дымовых тестов производительности на green-окружении
После переключения: запустите дымовые тесты в продакшене, чтобы убедиться, что переключение прошло чисто
Триггер отката: если дымовые тесты после переключения падают, немедленно переключитесь обратно на blue

# Example: Blue-green deployment with testing gates
deploy-to-green:
  runs-on: ubuntu-latest
  steps:
    - run: ./deploy.sh green

test-green:
  needs: deploy-to-green
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: npm ci
    - run: npx playwright test --project=regression
      env:
        BASE_URL: https://green.example.com

switch-traffic:
  needs: test-green
  runs-on: ubuntu-latest
  steps:
    - run: ./switch-traffic.sh blue-to-green

smoke-production:
  needs: switch-traffic
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: npm ci
    - run: npx playwright test --project=smoke
      env:
        BASE_URL: https://production.example.com

Уровень риска: низкий

Мгновенный откат путём переключения трафика обратно на blue. Полный набор тестов запускается на новой версии до того, как реальные пользователи её увидят.

Последствия для QA

Вам нужен полный, надёжный набор тестов, который может запускаться на изолированном окружении
Тесты должны быть не зависящими от окружения (настраиваемыми через BASE_URL)
Тестовые данные в green-окружении должны соответствовать условиям, приближенным к продакшену
Набор тестов должен завершаться за разумное время (блокировка развёртывания на 2 часа неприемлема)

Канареечное развёртывание

Как это работает

Новая версия развёртывается на небольшую часть серверов («канарейка»). Небольшой процент реального трафика (обычно 1-5%) направляется на канарейку. Если метрики выглядят хорошо, трафик постепенно увеличивается, пока канарейка не становится новым продакшеном.

                    Load Balancer
                   /      |      \
              v2.3     v2.3     v2.4 (canary)
              95%                5% трафика
                                ↑
                           Мониторинг метрик здесь:
                           - Частота ошибок
                           - Задержка p99
                           - Бизнес-метрики

Где запускаются тесты

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

# Example: Canary monitoring
canary-monitoring:
  runs-on: ubuntu-latest
  steps:
    - name: Wait for canary stabilization
      run: sleep 300  # 5 minutes for metrics to accumulate

    - name: Compare canary metrics
      run: |
        CANARY_ERROR_RATE=$(curl -s "$METRICS_API/canary/error-rate")
        BASELINE_ERROR_RATE=$(curl -s "$METRICS_API/baseline/error-rate")

        if (( $(echo "$CANARY_ERROR_RATE > $BASELINE_ERROR_RATE * 1.1" | bc -l) )); then
          echo "Canary error rate ($CANARY_ERROR_RATE) exceeds baseline ($BASELINE_ERROR_RATE) by >10%"
          exit 1
        fi

    - name: Run synthetic smoke tests
      run: npx playwright test --project=smoke
      env:
        BASE_URL: https://canary.example.com

Уровень риска: средний

Реальные пользователи видят новый код рано, но лишь небольшой процент. Если канарейка плохая, затронуты только 5% пользователей, и откат происходит автоматически.

Последствия для QA

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

Rolling-развёртывание

Как это работает

Экземпляры обновляются по одному (или небольшими группами) по всему флоту. В любой момент во время раскатки некоторые экземпляры работают на старой версии, а некоторые — на новой.

Start:    [v2.3] [v2.3] [v2.3] [v2.3]
Step 1:   [v2.4] [v2.3] [v2.3] [v2.3]  ← Health check на v2.4
Step 2:   [v2.4] [v2.4] [v2.3] [v2.3]  ← Health check на v2.4
Step 3:   [v2.4] [v2.4] [v2.4] [v2.3]  ← Health check на v2.4
Step 4:   [v2.4] [v2.4] [v2.4] [v2.4]  ← Завершено

Где запускаются тесты

До развёртывания: стандартный набор тестов на staging
Во время раскатки: health check на каждом обновлённом экземпляре перед продолжением
После полной раскатки: дымовые тесты в продакшене

Уровень риска: средний

Смешанные версии работают одновременно во время раскатки. Это может вызвать проблемы, если старая и новая версии имеют несовместимые схемы базы данных или контракты API.

Последствия для QA

Тесты должны учитывать обратную совместимость во время окна раскатки
Эндпоинты health check должны быть содержательными (а не просто возвращать 200)
Миграции базы данных должны быть обратно совместимыми (паттерн expand-contract)
Версионирование API становится важным — могут ли старые клиенты взаимодействовать с новыми серверами и наоборот?

Сравнение стратегий

Стратегия	Как работает	Где запускаются тесты	Уровень риска	Скорость отката	Лучше всего для
Blue-Green	Два окружения; трафик переключается	Полный набор на green перед переключением	Низкий	Мгновенный	Команд с надёжными наборами тестов
Canary	Малый % трафика на новую версию	Мониторинг и синтетические тесты	Средний	Быстрый (автоматический)	Высоконагруженных приложений с хорошей наблюдаемостью
Rolling	Экземпляры обновляются по одному	Health check на каждом экземпляре	Средний	Медленный (раскатка вперёд/назад)	Stateless-сервисов с большими флотами

Feature flags как стратегия тестирования

Feature flags отделяют развёртывание от релиза. Вы развёртываете код, но скрываете новые функции за флагами, затем включаете их постепенно.

// Feature flag check in application code
if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
  return newCheckoutFlow();
} else {
  return legacyCheckoutFlow();
}

Последствия feature flags для QA:

Тестируйте оба состояния каждого флага (включён и выключен)
Тестируйте комбинации флагов, если функции взаимодействуют
Убедитесь, что отключение флага чисто откатывает к старому поведению
Убирайте старые флаги — устаревшие флаги создают технический долг и увеличивают сложность тестирования

// Test both flag states
test('checkout flow with new feature enabled', async () => {
  await setFeatureFlag('new-checkout-flow', true);
  // ... test new behavior
});

test('checkout flow with new feature disabled', async () => {
  await setFeatureFlag('new-checkout-flow', false);
  // ... test legacy behavior
});

Тестирование самого пайплайна развёртывания

Пайплайн развёртывания — это программное обеспечение. В нём могут быть баги. Тестируйте его.

Что проверять:

Откат работает корректно (инициируйте откат и убедитесь, что старая версия восстановлена)
Health check действительно обнаруживают нездоровые экземпляры (разверните сломанную версию и убедитесь, что пайплайн останавливается)
Дымовые тесты запускаются на правильном окружении (а не случайно тестируют staging, когда вы думаете, что тестируете продакшен)
Уведомления срабатывают при сбое (намеренно сломайте пайплайн и убедитесь, что оповещения в Slack/email приходят)

Практическое упражнение

Определите, какую стратегию развёртывания использует ваша команда. Если вы не знаете, спросите у DevOps-/платформенной команды.
Отобразите, где в вашем процессе развёртывания сейчас запускаются тесты. Есть ли пробелы?
Напишите набор дымовых тестов, который может запускаться на любом окружении (настраиваемый через BASE_URL)
Если вы используете канареечное развёртывание, определите ключевые метрики, которые вы должны мониторить во время раскатки
Протестируйте процедуру отката. Можете ли вы откатить развёртывание менее чем за 5 минут?
Если ваша команда использует feature flags, напишите тесты, покрывающие оба состояния флага для текущей функции