Правку выкатывают вечером по FTP прямо на боевой сайт, что-то ломается, магазин лежит в самый трафик, а откатиться некуда — предыдущей версии никто не сохранил. Знакомая картина для многих проектов на 1С-Битрикс. Ручной деплой «перетащил файлы и надеюсь, что не упало» — это не про скорость, а про регулярный риск потерять продажи из-за одной опечатки в релизе.
Эта статья — о том, как настроить CI/CD и автодеплой для интернет-магазина на 1С-Битрикс так, чтобы выкладка была быстрой, повторяемой и без простоя, а откат занимал секунды. Разберём организацию кода в git, окружения, конвейер проверок, деплой без даунтайма, миграции базы и особенности кэша и обмена с 1С. Если проект пока «причёсан» плохо, начать разумно с аудита и оптимизации 1С, чтобы навести порядок в коде перед автоматизацией.
Коротко
- CI/CD для Битрикс реален: держите код в git, доработки в /local, не правьте ядро, исключайте изменяемые данные и секреты.
- Деплой без простоя строится на атомарном переключении релиза симлинком и вынесении upload и кэша в постоянные папки.
- Изменения базы оформляйте как идемпотентные миграции, а кэш и обмен с 1С аккуратно вписывайте в шаги деплоя.
- Откат — это переключение симлинка обратно; предыдущий релиз всегда должен оставаться на месте.
Зачем магазину CI/CD
CI/CD — это автоматизация пути изменения от коммита до боевого сайта. Для интернет-магазина, который теряет деньги за каждую минуту простоя, это не «инженерная роскошь», а способ снизить риск и ускорить развитие. Ручной деплой опасен по трём причинам: он не повторяем (каждый раз чуть по-разному), не оставляет следов (что и когда выкатили — неизвестно) и не имеет отката (сломалось — чините на живом).
Автоматизированный конвейер убирает эти проблемы: релиз всегда собирается одинаково, история выкладок сохраняется, а откат — это одна команда. В результате команда выкатывает чаще и спокойнее, а бизнес меньше зависит от «а вдруг сегодня уроним магазин». Это прямая экономия на инцидентах и ускорение изменений.
Что такое CI и CD простыми словами
За аббревиатурой стоят две связанные, но разные вещи.
| Термин | Что означает | Что делает на практике |
|---|---|---|
| CI (интеграция) | Непрерывная сборка и проверка | На каждый коммит: сборка, тесты, статический анализ |
| CD (доставка/деплой) | Автоматическая выкладка | Проверенный код едет на staging и в бой |
| Артефакт | Собранный релиз | Готовый к выкладке набор файлов |
| Пайплайн | Конвейер шагов | Последовательность: сборка → тест → деплой |
Проще говоря: CI следит, чтобы новый код не ломал сборку и проходил проверки, а CD доставляет его на сервер без ручных операций. Вместе они превращают выкладку из нервного события в рутинную кнопку.
Git и организация кода Битрикс
Фундамент любого CI/CD — код в git. Без репозитория с историей автоматизировать нечего. Для Битрикс ключевое правило — вся ваша разработка живёт в папке /local: компоненты, шаблоны, модули, обработчики событий. Так код изолирован от ядра и удобно версионируется.
- Доработки в /local. Кастомные компоненты и шаблоны, а не правки в /bitrix и тем более не в ядре.
- Модули для логики. Существенную бизнес-логику оформляют модулем, а не разбрасывают по init.php.
- Ядро отдельно. Обновляемое ядро Битрикс не смешивают с вашим кодом в основном репозитории.
- Понятная структура. Единые соглашения, чтобы релиз собирался предсказуемо.
Правильная организация кода — тема сама по себе. Как выносить логику в модули и работать без правки ядра, мы разбираем в статьях про разработку модулей под Битрикс и про D7 и ORM. Без этой дисциплины автодеплой лишь ускорит доставку хаоса.
Что нельзя коммитить
Не всё, что лежит на боевом сервере, должно быть в git. Изменяемые данные и секреты исключают из репозитория — иначе деплой будет затирать пользовательский контент и раскрывать пароли.
- Загрузки (upload). Пользовательские файлы и картинки — это данные, а не код.
- Кэш и логи. Генерируются на месте, в репозитории им не место.
- Файлы обмена с 1С. Временные выгрузки не версионируются.
- Секреты и подключение к БД. Локальные настройки и пароли выносят из репозитория в защищённое хранилище.
Окружения: staging и боевой
Предсказуемый деплой невозможен без разделения окружений. Минимум — боевой контур и staging, максимально похожий на него. На staging релиз проверяют перед выкладкой на бой, а разработку ведут на копии, а не на живом сайте.
Одинаковость окружений убирает целый класс ошибок «на моей машине работало, а на бою упало»: разные версии PHP, отсутствующие расширения, другие настройки. Чем ближе staging к продакшену, тем меньше сюрпризов при релизе. Дополнительно заводят контур для автотестов. Инфраструктура окружений строится на понятных решениях — про их настройку под Битрикс мы писали в статье про хостинг и инфраструктуру BitrixVM.
Конвейер сборки и проверок
Сердце CI — конвейер, который запускается на каждое изменение и не пускает в бой заведомо сломанный код. Для магазина на Битрикс разумный минимум проверок такой:
- Синтаксис PHP. Быстрая проверка, что код вообще парсится, — ловит опечатки до выкладки.
- Статический анализ. Линтеры и анализаторы находят потенциальные ошибки и нарушения стиля.
- Smoke-тесты. Проверка, что ключевые страницы (главная, каталог, карточка, корзина) открываются на staging.
- Проверка оформления. Прогон сценария оформления заказа на тестовом контуре.
- Сборка артефакта. Формирование готового к выкладке релиза.
Полное покрытие юнит-тестами на контентном проекте не всегда оправдано, но smoke-тесты ключевых страниц и оформления заказа ловят большинство критичных поломок дёшево. Конвейер — это страховка, которая срабатывает до того, как ошибка увидит покупатель.
Деплой без простоя
Главная задача — выкатить релиз так, чтобы пользователи не увидели ни ошибки, ни полусобранного состояния. Классический приём — атомарное переключение. Новый релиз собирается в отдельной директории, полностью готовится, и только затем симлинк «текущая версия» мгновенно переключается на него.
Пользователь в любой момент видит либо старый, либо новый релиз целиком, но никогда — промежуточное состояние. Изменяемые данные (upload, кэш, файлы обмена) выносят в отдельные постоянные папки, которые подключаются к каждому релизу симлинками, чтобы они не терялись при переключении. Такой деплой даёт нулевой простой и мгновенный откат: чтобы вернуться, достаточно переключить симлинк на предыдущий релиз, который остаётся на диске.
Миграции базы данных
Код без изменений базы деплоить легко, но реальные релизы часто меняют структуру: новые инфоблоки, свойства, типы цен, поля. Делать это руками через админку на каждом окружении — прямой путь к расхождению staging и боя. Правильно — оформлять изменения как миграции: скрипты, которые применяются автоматически на этапе деплоя и создают нужную структуру программно.
Хорошие миграции идемпотентны (применяются без вреда при повторе) и обратимы (имеют план отката). Тогда структура окружений не расходится, а релиз предсказуем. Для Битрикс это означает создание инфоблоков, свойств и настроек кодом, а не кликами. Такой подход требует дисциплины, но именно он делает автодеплой безопасным для проектов, где база меняется вместе с кодом.
Кэш и обмен с 1С при релизе
Две особенности Битрикс требуют внимания при деплое — кэш и обмен с 1С. Кэш компонентов и меню после выкладки обычно нужно сбросить, иначе пользователи увидят старую разметку или логику. Но полный сброс на нагруженном сайте вызывает всплеск нагрузки, пока кэш прогревается заново.
- Сброс кэша в шаге деплоя. Но выборочно или с прогревом, а не «всё сразу» на пике трафика.
- Папки обмена вне релиза. Файлы выгрузки 1С в постоянном хранилище, чтобы деплой их не затирал.
- Не совпадать с выгрузкой. Крупный релиз планируют вне тяжёлого обмена, иногда обмен ставят на паузу.
- Проверка агентов. После деплоя агенты и cron обмена продолжают работать корректно.
Обмен с 1С — критичный процесс, и деплой не должен портить его данные. Про надёжность и безопасность интеграций мы подробнее писали в статье про REST, вебхуки и безопасность.
Откат и защита от сбоев
Даже с проверками релиз иногда ломается на бою — поэтому откат должен быть быстрым и надёжным. При атомарном деплое откат — это переключение симлинка на предыдущий релиз, который никуда не делся. Секунды, а не паника и восстановление из бэкапа.
Дополнительно защищают релиз несколькими практиками: держать несколько последних релизов на диске для отката на любой из них, снимать резервную копию базы перед миграциями, мониторить ключевые метрики (доступность, ошибки, оформление заказа) сразу после выкладки. Если после релиза выросли ошибки или упало оформление — автоматика или дежурный откатывают версию, не дожидаясь разбора. Быстрая обработка заказов и стабильность продаж напрямую зависят от такой дисциплины — её мы закладываем в услугу автоматизации продаж и склада на 1С.
Частые ошибки
- Деплой по FTP на бой. Не повторяемо, без истории и отката — классический источник простоев.
- Правки в ядре. Затираются обновлениями и ломают автосборку.
- Данные и секреты в git. Деплой затирает загрузки, а пароли утекают в репозиторий.
- Нет staging. Релиз проверяют сразу на живом сайте — ошибки видят покупатели.
- Миграции руками. Структура окружений расходится, релизы непредсказуемы.
- Полный сброс кэша на пике. Всплеск нагрузки роняет сайт в момент релиза.
- Нет отката. Сломалось — чинят на живом, продлевая простой.
Чек-лист внедрения
- Код в git. Репозиторий с историей, доработки в /local, ядро не правится.
- Данные исключены. upload, кэш, логи, файлы обмена и секреты вне репозитория.
- Окружения разделены. Боевой и похожий на него staging, контур для тестов.
- Конвейер проверок. Синтаксис, статический анализ, smoke-тесты, сборка артефакта.
- Деплой без простоя. Атомарное переключение симлинка, общие данные вынесены.
- Миграции автоматизированы. Идемпотентные и обратимые, применяются в деплое.
- Откат и мониторинг. Прошлые релизы на диске, бэкап перед миграциями, контроль метрик после выкладки.
Вывод
CI/CD превращает выкладку из рискованного вечернего ритуала в предсказуемую кнопку. Для интернет-магазина на 1С-Битрикс это прямая защита выручки: релизы собираются одинаково, проверяются до боя, выкатываются без простоя и откатываются за секунды. Битрикс этому не мешает — мешает беспорядок в коде, поэтому автоматизацию всегда предваряет дисциплина: git, /local, отказ от правок ядра.
Соберите фундамент — код в репозитории, разделённые окружения, конвейер проверок, атомарный деплой с откатом — и аккуратно впишите в него специфику Битрикс: миграции, кэш и обмен с 1С. В результате команда выкатывает изменения чаще и спокойнее, а бизнес перестаёт бояться собственных релизов.
