Blue-Green деплойменты

Blue-Green деплоймент — это стратегия выкладки приложений, при которой в инфраструктуре одновременно существуют две полностью идентичные среды: Blue (текущая рабочая версия) и Green (новая версия). В каждый момент времени пользовательский трафик направляется только на одну из них. Переключение между средами происходит атомарно, без промежуточных состояний.

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

Архитектура Blue-Green для фронтенд-приложений

В классическом варианте фронтенд деплоится как статическое приложение, обслуживаемое CDN или веб-сервером. Blue-Green в таком случае реализуется на уровне:

  • URL / доменов

    • app-blue.example.com
    • app-green.example.com

  • CDN версий

  • Reverse proxy (Nginx, HAProxy, Traefik)

  • Feature routing на уровне ingress (Kubernetes)

Inferno-приложение не требует специальных изменений для поддержки Blue-Green — вся логика находится вне кода, на уровне инфраструктуры.

Сборка Inferno-приложения под Blue-Green

Inferno обычно используется с кастомной сборкой (Rollup, Vite, Webpack). Для Blue-Green важно обеспечить:

  • детерминированную сборку;
  • изоляцию ассетов;
  • контроль версий.

Пример структуры сборки

/dist
  /blue
    index.html
    app.3f92a.js
    vendor.a81cd.js
  /green
    index.html
    app.7b12c.js
    vendor.4e91f.js

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

Контроль точки входа Inferno

Inferno инициализируется строго в одном месте:

import { render } from 'inferno';
import App from './App';

render(<App />, document.getElementById('root'));

Blue-Green стратегия не влияет на этот код, но важно:

  • не использовать глобальные синглтоны с побочными эффектами;
  • избегать shared-state между вкладками;
  • инициализировать все сервисы строго при загрузке страницы.

Это гарантирует, что новая версия (Green) не зависит от состояния Blue.

Переключение трафика

Через reverse proxy (пример Nginx)

upstream inferno_app {
    server app-blue.example.com;
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://inferno_app;
    }
}

Переключение выполняется изменением upstream:

upstream inferno_app {
    server app-green.example.com;
}

Перезагрузка конфигурации Nginx происходит без разрыва соединений.

Работа с кэшем и CDN

Blue-Green деплоймент для фронтенда невозможен без строгого контроля кэширования.

Ключевые принципы:

  • Хэшированные имена файлов (app.[hash].js)
  • Cache-Control: immutable для JS/CSS
  • no-cache или короткий TTL для index.html

Inferno-приложение, как SPA, критично зависит от корректного обновления index.html, так как именно он определяет, какую версию бандлов загрузит браузер.

Совместимость API и контрактов

При Blue-Green деплойменте фронтенд и backend могут временно работать в разных версиях. Для Inferno-приложения это означает:

  • запрет на breaking-changes API;
  • версионирование REST / GraphQL;
  • поддержка обратной совместимости.

Практика:

  • Green-версия фронтенда должна корректно работать с текущим backend;
  • после переключения фронтенда можно обновлять backend.

Feature Flags внутри Inferno

Blue-Green часто комбинируется с feature flags, позволяя:

  • включать новые возможности только в Green;
  • тестировать поведение без смены среды.

Пример простого флага:

const ENABLE_NEW_DASHBOARD = window.__FLAGS__.newDashboard;

Флаги загружаются из:

  • JSON-конфига;
  • HTTP-endpoint;
  • inline-скрипта в index.html.

Это позволяет развернуть код, но активировать функциональность позже.

Rollback без redeploy

Главное преимущество Blue-Green — мгновенный откат.

При проблеме:

  • трафик возвращается на Blue;
  • Green остаётся доступной для анализа;
  • не требуется пересборка Inferno-приложения.

Время отката измеряется секундами и не зависит от размера проекта.

Логирование и мониторинг

Для корректной эксплуатации необходимо разделять метрики:

  • отдельные логи для Blue и Green;
  • разные source-map файлы;
  • version-tag в runtime.

Пример добавления версии:

console.info('App version:', __APP_VERSION__);

__APP_VERSION__ подставляется на этапе сборки через define-плагин.

Интеграция с CI/CD

Типовой pipeline:

  1. Сборка Inferno-приложения
  2. Деплой в Green-среду
  3. Smoke-тесты
  4. Переключение трафика
  5. Очистка старой Blue (по необходимости)

Inferno хорошо подходит для такого подхода из-за:

  • минимального времени сборки;
  • отсутствия runtime-зависимостей;
  • простоты деплоя как статических файлов.

Ограничения и подводные камни

  • Удвоенные ресурсы инфраструктуры
  • Необходимость строгого контроля кэша
  • Повышенные требования к совместимости API
  • Ошибки при использовании localStorage/sessionStorage между версиями

Особое внимание требуется при изменении:

  • форматов данных в хранилищах браузера;
  • схем IndexedDB;
  • структуры cookies.

Когда Blue-Green особенно оправдан для Inferno

  • высоконагруженные SPA;
  • корпоративные панели;
  • приложения с жёсткими SLA;
  • проекты с частыми релизами.

Inferno, за счёт своей производительности и минимализма, хорошо вписывается в Blue-Green стратегию, не усложняя ни кодовую базу, ни процесс выкладки.

Оглавление