Что даёт внедрение CI/CD и что входит в поставку
Настройка CI/CD — это автоматизация деплоя, то есть замена ручной выкатки автоматической: код попадает в репозиторий, дальше сборка, проверки, перенос на сервер и миграции базы идут сами и одинаково каждый раз. Дальше по тексту мы пишем «выкатка» — это то же самое слово по-русски. Уходят три типовые беды: «локально работало», «забыли один файл» и «релиз умеет только Петя».
Что входит. Разбор текущей выкатки, настройка репозитория и веток, пайплайн сборки и проверок, тестовый контур, выкатка на продакшн, процедура отката, уведомления, документация и обучение — чтобы релиз мог провести любой в команде.
Кому подходит. Проектам, где релизы случаются чаще раза в месяц; командам больше одного разработчика; всем, у кого правки заливаются по протоколу передачи файлов прямо на боевой сервер. Последнее — не редкость, а самый частый случай в веб-разработке, и он же причина большинства ночных аварий.
Сколько стоит. Проектная работа с понятным концом. SCG Group на сентябрь 2026 берёт от 40 000 ₽ за базовый вариант, от 70 000 ₽ за расширенный с откатом и наблюдением и от 120 000 ₽ за мультисредовый. Ориентир рынка, не наш прайс. Наша вилка по уровням: от 60 000 ₽
Три уровня внедрения: что входит в каждый
Связку «уровень — состав — цена» в этой услуге не даёт никто: уровни называют, а цену прячут, либо наоборот. Таблица ниже описывает, что именно меняется от ступени к ступени; суммы придут из договора.
| Уровень | Что настраиваем | Когда этого достаточно | Цена |
|---|---|---|---|
| Простой | Сборка, базовые проверки, выкатка на тестовый контур, уведомления | Один сайт, одна команда, релизы по готовности | от 60 000 ₽ |
| Расширенный | Всё из простого плюс выкатка на продакшн, миграции базы, откат, метрики релиза | Боевой проект с нагрузкой и регулярными релизами | от 120 000 ₽ |
| Мультисредовый | Всё из расширенного плюс несколько сред, поэтапная выкатка, права и аудит действий | Несколько команд, внешние подрядчики, требования по контролю доступа | от 150 000 ₽ |
Приём, который стоит перенять у сильных игроков, — включать в проектную цену сопровождение на несколько месяцев после сдачи. Пайплайн не заканчивается вместе с внедрением: меняются зависимости, растёт время сборки. Мы закладываем период, в который доводим его без отдельного счёта.
Как устроен пайплайн: от коммита до продакшна
Цепочка одинакова для любой платформы, различается наполнение шагов.
- Триггер. Изменение попало в ветку — запускается сборка. Для боевой выкатки триггером служит подтверждение человека, а не сам коммит: автоматизация не означает, что релиз происходит без решения.
- Сборка. Зависимости, компиляция стилей и скриптов, сжатие изображений, версионирование. Результат — артефакт, который дальше не пересобирается: на тест и на продакшн уезжает один и тот же.
- Проверки. Линтеры, автотесты, если они есть, проверка миграций на копии базы, сканирование зависимостей.
- Выкатка. Перенос в новую папку, прогон миграций, переключение ссылки на новую версию, сброс кеша, перезапуск обработчиков. Переключением ссылки релиз становится мгновенным: пользователь не попадает на полуразвёрнутый проект.
- Проверка после. Автоматический запрос к ключевым страницам, сравнение ошибок и времени ответа с уровнем до релиза, уведомление команде.
Отдельный шаг — бюджет производительности. В пайплайн встраивается замер актуальной тройки показателей загрузки: отрисовка главного элемента, отзывчивость на действия пользователя и стабильность вёрстки. Устаревшую метрику задержки первого ввода мы не измеряем: её заменили на отзывчивость, а половина отраслевых текстов этого не заметила. Ухудшение относительно прошлого релиза видно сразу.
Откат: процедура, а не строчка в списке технологий
Слово «откат» присутствует почти в каждом описании услуги на рынке — обычно в перечне возможностей рядом с названиями инструментов. Вопрос, который стоит задавать подрядчику: сколько занимает откат, кто имеет право его запустить и что происходит с базой.
С кодом просто. Предыдущие версии остаются на сервере, откат — переключение ссылки обратно и сброс кеша: секунды, без пересборки.
С базой сложнее, и именно здесь ломается большинство откатов. Правило, которое мы закладываем в процесс: миграции пишутся совместимыми со старой версией кода. Колонка сначала добавляется, и только следующим релизом, когда новая версия отработала, удаляется старая. Тогда откат кода не требует отката базы — а обратная миграция на живых данных всегда риск потерять то, что записалось после релиза.
Процедура отката описывается в документации проекта и проверяется на тестовом контуре до сдачи работы. Непроверенный откат — то же самое, что непроверенная резервная копия: он существует до момента, когда понадобился.
CI/CD для Битрикса, WordPress и Odoo: где сценарии расходятся
Универсального пайплайна не бывает, потому что платформы по-разному относятся к тому, что редактор меняет содержимое прямо на боевом сервере.
1С-Битрикс. Главная сложность — граница между кодом и контентом: часть настроек живёт в базе, загруженные файлы лежат вперемешку с исходниками. Под версионный контроль уходят шаблоны, компоненты и собственный код; пользовательские файлы и база остаются на месте и переносятся только в сторону тестового контура. Обновления ядра идут отдельной процедурой, а не через пайплайн.
WordPress. Расширения и темы фиксируются менеджером зависимостей, а не копируются руками, — иначе состав сайта на разных серверах расходится через месяц. Отдельное правило: обновления расширений проходят через тестовый контур, потому что обновление в один клик прямо на боевом сайте — самая частая причина внезапно белого экрана.
Odoo. Изменения оформляются собственными модулями, а не правками ядра, и выкатываются с прогоном обновления модулей на копии базы. Отдельный шаг — проверка, что длинные операции и отчёты после релиза не встали: в системе учёта тихо сломавшийся ночной процесс заметнее ошибок на экране.
Тестовый контур, поэтапная выкатка и когда она лишняя
Тестовый контур — копия боевого окружения с обезличенными данными, где релиз проверяется до того, как его увидят пользователи. Копия базы обновляется по расписанию, персональные данные затираются, внешние сервисы переключаются на тестовые ключи — иначе проверка отправит реальным покупателям настоящие письма.
Про поэтапные схемы скажем осторожно. Параллельная работа двух версий и постепенный перевод части пользователей — приёмы рабочие, но требуют двойных ресурсов, балансировщика и дисциплины в миграциях. Проекту, который выкатывается раз в неделю и переносит простой в секунду, это лишний слой, который тоже ломается.
Выстраивание процессов идёт в таком порядке: сначала воспроизводимая сборка, тестовый контур и проверенный откат. Поэтапную выкатку предложим, когда в ней появится смысл, а не в первом предложении ради веса.