Кейс U-Team - Blue-Green деплой для Realt.by без простоев
О клиенте
Компания: Realt.by - крупнейший портал недвижимости в Беларуси с высоким трафиком и критической зависимостью от доступности сайта.
Задача: обеспечить возможность частых обновлений фронтенда без остановки сервиса и риска выкатить «сломанную» версию для пользователей.
Ситуация (Контекст и проблематика)
Realt.by развивает сайт интенсивно: новые функции, исправления, A/B-тесты. До внедрения нового процесса любое обновление было стрессом.
Ключевые боли:
- Релиз = простой - чтобы заменить версию, приходилось останавливать сервис, пусть и на короткое время.
- Риск отката - если новая версия «падала», пользователи видели ошибки, пока инженеры вручную возвращали предыдущую сборку.
- Долгий цикл проверки - команда боялась выкатывать часто, потому что каждый релиз мог превратиться в инцидент.
- Отсутствие автоматической «защиты от дурака» - иногда в прод уезжала версия, которая проходила ручные тесты, но «валилась» под реальным трафиком.
Решение
Мы предложили не просто «настроить CI/CD», а внедрить стратегию Zero-downtime Blue-Green deployments с автоматическими проверками здоровья. Заказчик получил готовую автоматизированную систему, которая исключает человеческий фактор при релизах.
Как работает схема:
На сервере всегда работают два одинаковых окружения:
- Blue - текущая продакшн-версия.
- Green - новая версия, которая разворачивается параллельно.
Что выполнила наша команда:
- Задекларировали пайплайн из 5 стадий (Build - Deploy - Health-check - Switch - Cleanup).
- Настроили переменные окружения (CURRENT_WWW_COLOR, TAG_GREEN, TAG_BLUE), чтобы пайплайн сам знал, какая сейчас активная среда.
- Написали health-check.sh, который проверяет не только «жив ли контейнер», но и отдает ли он нужный контент (статус 200, ключевые блоки HTML).
- Интегрировали переключение через обновление конфига Nginx + graceful reload (без потери соединений).
- Всё завернули в GitLab CI с изолированными раннерами и безопасным хранением секретов.
Важно: Если Health-check не проходит - переключение не происходит, пользователи продолжают сидеть на старой стабильной версии. Инженер видит в GitLab, что релиз «застрял» на проверке, ничего не сломав.
Результаты и преимущества для клиента
- Ноль даунтайма при релизах - пользователи даже не замечают, что сайт обновился.
- Автоматическая защита от «битых» релизов - если новая версия не проходит health-check, она не попадает на пользователей, а команда получает уведомление в GitLab.
- Релизы без страха и в любое время - разработчики могут выкатывать обновления 5 раз в день - процесс безопасен и предсказуем.
- Мгновенный откат - откатить релиз - это просто запустить пайплайн ещё раз (текущая зелёная станет синей, а синяя - зелёной). Занимает меньше минуты.
- Прозрачность - в GitLab видно, на какой стадии какой релиз, кто его запустил и прошел ли health-check.
- Экономия времени инженеров - раньше релиз занимал часы с ручными проверками и страхом. Теперь - несколько минут полностью автоматически.
Роль нашей компании
- Анализ процесса релизов и выявление узких мест.
- Проектирование Blue-Green архитектуры под инфраструктуру клиента.
- Реализация пайплайна GitLab CI из 5 стадий.
- Написание health-check скриптов под конкретное приложение.
- Настройка атомарного переключения Nginx с graceful reload.
- Настройка безопасного хранения секретов (SSH-ключи, логины в registry).
- Обучение команды и передача документации.
- Сопровождение первых релизов.
Формула успеха
Blue-Green пайплайн + автоматический health-check + атомарное переключение Nginx + изолированные окружения + GitLab CI = релизы без простоев и без стресса.
Отправить заявку
Оставьте заявку, и мы свяжемся с вами в течение суток
