Сегодня поговорим о том, что заставляет ИТ-директоров седеть быстрее, чем просмотр логов в 3 утра — о деплое в продакшн. Как можно и как правильно.
Деплой (deployment) — это процесс доставки твоего прекрасного кода до пользователя.
Как доставка пиццы. Можно просто кинуть коробку через забор (FTP upload), а можно организовать целую логистическую сеть с отслеживанием, проверкой качества и возможностью вернуть обратно, если что-то пошло не так.
Почему это вообще тебе важно?
Потерянные деньги (простой = убытки)
Стресс команды (и твой лично)
Недовольные пользователи
Звонки в 2 ночи от техподдержки или директора
Хороший деплой — это магия, которая работает незаметно. В этом предложении вся суть.
Театр деплоя, какие бывают:
1. “Ковбойский” деплой (YOLO Deployment)
Что это: Берём код, заливаем на сервер через FTP, молимся. Иногда не проносит.
✅ Плюсы:
Быстро
Просто
Адреналин в крови
💩 Минусы:
Может сломать нахрен всё
Откат = ещё один деплой
Твоя нервная система
Когда использовать: Pet-проект джуна. На работе – Никогда. Серьёзно. Не делай так.
Твой ковбойский деплой
2. Rolling Deployment (Раскатывающий деплой)
Что это: Обновляем серверы по очереди, как домино.
Как работает:
Останавливаем сервер #1
Обновляем код
Запускаем, проверяем
Переходим к серверу #2
И так до конца
✅ Плюсы:
Нет простоя (если всё идёт по плану)
Можем остановиться на любом этапе
Относительно просто
❌ Минусы:
Долго для больших кластеров
Проблемы совместимости версий
Если что-то пошло не так на середине — будет весело
3. Symlink Deployment (Атомарный деплой)
Как работает:
Храним несколько версий в папках releases/
Веб-сервер смотрит на символическую ссылку current
Деплой = атомарная смена ссылки
Откат = смена ссылки обратно
✅ Плюсы:
Мгновенное переключение
Моментальный откат — просто переключить ссылку обратно
История версий — можем вернуться к любому из последних релизов
Простота реализации — не нужны сложные инструменты
Общие данные сохраняются (uploads, логи, кеш)
❌ Минусы:
Требует в 2-3 раза больше места на диске
Проблемы с БД миграциями
Только для одного сервера — не подходит для кластеров
4. Blue-Green Deployment (Главный герой сегодня)
Что это: У нас есть две одинаковые среды — “синяя” и “зелёная”. Пользователи работают с одной, мы готовим обновление на другой.
Алгоритм действий:
Blue работает, пользователи счастливы
Деплоим новую версию на Green
Тестируем Green (у тебя же есть тесты?)
Переключаем трафик с Blue на Green
Blue становится fallback’ом (если Green говно сломался, переключаем всё раньше, чем прибежит директор)
На уровне веб сервера:
# nginx.confupstream backend {server blue.internal:8080 weight=100; # Активная среда server green.internal:8080 weight=0; # Готовим обновление}# После деплоя меняем веса:upstream backend { server blue.internal:8080 weight=0; # Резерв server green.internal:8080 weight=100; # Новая активная}
✅ Плюсы:
Мгновенный откат (просто переключаем обратно)
Нулевой простой
Полное тестирование перед переключением
Спокойный сон ИТ-директора
💰 Минусы:
Двойные ресурсы (два одинаковых окружения)
Сложности с базой данных (миграции)
Более сложная инфраструктура
Нужно пояснить за шмот шарить в DevOps
5. Canary Deployment (Канарейка в угольной шахте)
Что это: Выкатываем новую версию только части пользователей. Если “канарейка” выживает — выкатываем всем.
Blue-Green с базой данных — это как жонглирование бензопилами. Одна ошибка и… привет, восстановление из бэкапа в 3 утра.
Главная проблема: У тебя две среды, но база данных одна. Как обновить схему БД без поломки старой версии приложения?
Стратегии выживания:
1. Shared Database (Одна база на всех)
Как работает: Blue и Green используют одну БД. Миграции должны быть совместимы с обеими версиями.
-- ❌ Плохо: удаляем колонку сразуALTERTABLE users DROP COLUMN old_field;-- ✅ Хорошо: поэтапная миграция-- Деплой 1: добавляем новую колонку ALTERTABLE users ADD COLUMN new_field VARCHAR(255);-- Деплой 2: переносим данные, обе версии работают UPDATE users SET new_field = old_field WHERE new_field ISNULL;-- Деплой 3: удаляем старую (через несколько релизов) ALTERTABLE users DROP COLUMN old_field;
Плюсы:
✅ Просто в настройке
✅ Нет проблем с синхронизацией
✅ Одна точка правды
Минусы:
❌ Медленные миграции (backward compatibility)
❌ Накапливается технический долг
❌ Разработчики тебя ненавидят за “костыли”
2. Database Per Environment (Своя база для каждой среды)
Плюсы:
✅ Полная изоляция
✅ Можно тестировать любые миграции
✅ Быстрый откат = переключение базы
Минусы:
❌ Синхронизация данных = чистый ад
❌ Двойные ресурсы
❌ Сложность с пользовательскими данными
3. Read Replicas для тестирования (очень мало где сможет пригодиться)
production_db: master (для Blue) green_environment: read_replica (для тестов)
Плюсы:
✅ Реальные данные для тестирования
✅ Не влияем на продакшн
✅ Дешевле полного дублирования
Минусы:
❌ Read-only ограничения
❌ Лаг репликации (данные отстают)
❌ Нельзя тестировать миграции записи
4. Database Branching (Современный подход)
Database Branching – это возможность создавать “ветки” базы данных, как в Git для кода. Каждая ветка – это полная копия БД, которую можно независимо изменять, тестировать и затем сливать обратно.
Инструменты: PlanetScale (MySQL), Neon (PostgreSQL), Xata или собственные решения
# Создаём ветку базы для Greenplanetscale branch create myapp green-deployment# Применяем миграции к веткеplanetscale schema apply myapp green-deployment# Тестируем на ветке# Если всё ОК — мержим в mainplanetscale deploy-request create myapp green-deployment
Плюсы:
✅ Как Git, но для базы данных
✅ Безопасные миграции
✅ Лёгкий откат
Минусы:
❌ Не все БД поддерживают
❌ Дополнительные инструменты
❌ Стоимость
5. Event Sourcing + CQRS (Для продвинутых и богатых)
Event Sourcing – храним историю, а не состояние. Вместо хранения текущего состояния БД мы храним все события, которые к этому состоянию привели. Можем “перемотать” базу к любому моменту.
В обычной БД:
Баланс: 1000₽
В Event Sourcing:
События: 1. Счёт открыт: +0₽ 2. Пополнение: +1500₽ 3. Покупка кофе: -150₽ 4. Зарплата: +50000₽ 5. Аренда: -30000₽ 6. Покупка: -350₽ --- Текущий баланс = сумма всех событий = 21000₽
CQRS – читаем и пишем в БД раздельно. Суть: Разделяем операции чтения (Query) и записи (Command) на разные модели.
Плюсы:
✅ Полная история изменений
✅ Лёгкий откат к любому состоянию
✅ Аудит из коробки
Минусы:
❌ Сложность архитектуры – намного сложнее обычного CRUD
❌ Нужно переучивать разработчиков
❌ Не подходит для простых CRUD приложений
Как не проспать катастрофу?
Базовые метрики для старта:
HTTP статус-коды — рост 4xx/5xx ошибок = проблема
Время ответа — увеличение в 2+ раза = тормозит
Доступность эндпоинтов — /api/health, /login, /checkout должны отвечать
Health Checks уровнем выше
Глубокие проверки — не просто HTTP 200, а реальная работа БД/кэша
Зависимости — проверяй внешние API, очереди, файловое хранилище
🟢 GitLab CI/CD — вся инфраструктура и конфигурация описаны в Git-репозитории 🟢 Canary + Feature Flags — двойная страховка 🟢 Blue-Green per microservice — каждый сервис независимо 🟢 Chaos Engineering — сломай систему контролируемо
Как понять когда пора апгрейдить деплой?
Пора переходить с YOLO на Symlink:
Первый платящий клиент
Команда больше 1 человека
Деплой чаще 1 раза в неделю
Пора переходить с Symlink на Blue-Green:
Простой стоит дороже второго сервера
Клиенты жалуются на нестабильность
Есть SLA с клиентами
Пора внедрять Feature Flags:
A/B тестирование критично для бизнеса
Нужно быстро отключать проблемные фичи
Разные версии для разных клиентов
Сложность деплоя должна расти вместе с бизнесом, а не опережать его.
Kubernetes для блога — это как Камаз для поездки в магазин за хлебом. Но в то же время, помни: лучший твой деплой — тот, о котором никто не знает.
Да прибудет с вами спокойствие!
Если статья была полезной, загляни в мои другие статьи: