Schneider Electric -- мировой лидер в области энергоменеджмента и автоматизации. Когда их российское подразделение столкнулось с проблемами в скорости доставки обновлений, они обратились к нам. Рассказываем, что было, что сделали и каких результатов добились. Подробнее о проекте можно прочитать в нашем портфолио.
Проблема: деплой занимал 45 минут
На момент обращения процесс выглядел так: разработчик завершает фичу, создаёт pull request, ждёт ревью. После мержа DevOps-инженер вручную запускает скрипт деплоя, который последовательно обновляет 12 микросервисов. Весь цикл от мержа до продакшена занимал 45 минут при удачном сценарии и до 2 часов при ошибках.
Команда из 15 разработчиков релизила в среднем 2 раза в неделю. При этом каждый деплой требовал присутствия конкретного человека, который знал "магические команды". Если он был в отпуске -- деплой откладывался.
Аудит: что мы обнаружили
Первым шагом мы провели полный аудит CI/CD-инфраструктуры. Основные проблемы:
- Последовательная сборка. Все 12 сервисов собирались один за другим, хотя 8 из них были независимы и могли собираться параллельно.
- Отсутствие кеширования. Docker-образы каждый раз собирались с нуля, включая скачивание всех зависимостей.
- Ручной rollback. В случае ошибки откат производился вручную, что занимало ещё 20-30 минут.
- Нет автоматических проверок. Smoke-тесты запускались вручную после деплоя, из-за чего баги обнаруживались только через часы.
Решение: параллелизация и автоматизация
Мы перестроили весь пайплайн за 3 недели:
- Параллельная сборка. Разделили сервисы на 3 группы по зависимостям. Независимые сервисы собираются одновременно. Это сократило время сборки с 25 до 8 минут.
- Multi-stage Docker builds + кеширование. Внедрили layer caching и multi-stage builds. Повторная сборка без изменений в зависимостях занимает 40 секунд вместо 5 минут.
- Blue-green деплой. Новая версия запускается параллельно со старой. После прохождения health checks трафик переключается. Откат -- мгновенное переключение обратно.
- Автоматические smoke-тесты. После деплоя автоматически запускаются проверки критических эндпоинтов. При ошибке -- автоматический откат без участия человека.
Результаты
Конкретные метрики до и после:
- Время деплоя: 45 минут -> 14 минут (ускорение в 3.2 раза)
- Частота релизов: 2 раза в неделю -> ежедневно
- Время отката: 20-30 минут -> менее 1 минуты
- Зависимость от конкретного инженера: полностью устранена
- Количество инцидентов при деплое: сократилось на 80%
Что это дало бизнесу
Ускорение деплоя -- это не просто техническая метрика. Команда стала выкатывать фичи быстрее, получать обратную связь от пользователей раньше и реагировать на баги в течение часов, а не дней. По оценке CTO, новый пайплайн высвободил около 40 часов инженерного времени в месяц, которые теперь тратятся на развитие продукта, а не на борьбу с инфраструктурой. Узнайте больше о наших DevOps-услугах.