Staging-окружение и деплой магазина на Битрикс

Магазин на 1С-Битрикс живёт в постоянных правках: то новое свойство в каталог, то доработка корзины, то интеграция с новым сервисом доставки. Пока таких изменений мало, соблазн велик — открыть боевой сайт и поправить прямо там. До первого белого экрана на витрине в час пик, потерянного заказа или сломанного обмена с 1С, который тихо перестал грузить остатки. Отдельное staging-окружение и дисциплинированный деплой превращают выкладку изменений из рулетки в предсказуемую процедуру.

Ниже — практическая схема: как устроить контур dev/stage/prod для магазина на Битрикс, как переносить данные, не затирая боевые заказы, как оформлять правки каталога и кода миграциями и как выкатывать релиз так, чтобы его можно было мгновенно откатить. Это выжимка из наших проектов по DevOps и автоматизации для 1С-Битрикс — без теории ради теории, только то, что реально спасает боевую базу.

Зачем магазину на Битрикс отдельный staging

Начнём с честного вопроса: зачем усложнять, если можно поправить сайт напрямую и сэкономить время? Ответ в том, что «сэкономленное» время возвращается сторицей в момент первой же аварии. Интернет-магазин — это не блог: тут крутятся деньги, заказы, остатки, интеграции с 1С и платёжными системами. Ошибка на витрине — это не «некрасиво», это прямые потери выручки за каждую минуту простоя.

Staging-окружение решает сразу несколько задач, которые иначе решить невозможно. Во-первых, оно даёт место для проверки: можно установить обновление модуля, прогнать оформление заказа, проверить обмен с 1С — и всё это на копии, а не на живом сайте. Во-вторых, оно ловит различия окружений: код, который работал на ноутбуке разработчика с PHP 8.2, может упасть на боевом сервере с PHP 8.1 и другим набором расширений. Staging, повторяющий боевую конфигурацию, вскрывает это до релиза, а не после.

В-третьих, staging делает деплой повторяемым. Когда есть заранее описанная процедура «как выкатить релиз», её может выполнить не только тот единственный разработчик, который «держит всё в голове». Это снижает зависимость бизнеса от конкретного человека и делает выкладку рутиной, а не подвигом. И, наконец, staging — это фундамент для автоматизации: без него бессмысленно строить CI/CD, потому что автоматизировать выкладку прямо на prod без проверочного контура — значит автоматизировать аварии.

Контур окружений: dev, stage, prod

Классический контур состоит из трёх окружений, каждое со своей ролью. Понимание этих ролей важнее, чем конкретные технологии: технологии меняются, а логика разделения остаётся.

• Dev (окружение разработки). Здесь живёт код в момент написания. Часто это локальная машина разработчика или личный контейнер. Данные тут неважны и могут быть «мусорными»: главное — быстро писать и проверять код. Dev-окружений может быть много — по одному на каждого разработчика или на каждую задачу.
• Stage / staging (предпродакшн). Единая для команды копия боевого окружения. Сюда собирается релиз-кандидат, накатываются миграции, заливается свежий слепок боевых данных. На staging проводят приёмочное тестирование, проверяют интеграции и производительность. Это последний рубеж перед боем.
• Prod (боевое, production). То, что видят покупатели. Здесь лежат настоящие заказы, пользователи, платежи. На prod нельзя разрабатывать и экспериментировать — только выкатывать проверенные релизы и снимать резервные копии.

Иногда добавляют четвёртое окружение — QA/test для тестировщиков или preview для показа заказчику отдельных фич. Но для большинства магазинов на Битрикс трёх контуров достаточно. Главное — не смешивать роли: dev не должен работать с боевыми данными без обезличивания, а prod не должен быть местом отладки.

Чем staging должен отличаться от dev и совпадать с prod

Главная ценность staging — в его похожести на боевое окружение. Чем ближе staging к prod, тем больше проблем он ловит заранее. Расхождения между ними — это именно те щели, в которые проваливаются релизы. Разберём, что обязано совпадать.

А вот отличаться staging обязан в другом: он должен быть закрыт от поисковых систем (иначе схлопотаете дубли сайта в индексе) и от посторонних глаз (базовая авторизация или доступ по IP). Платёжные системы на staging переключают в тестовый режим, отправку писем и SMS глушат или заворачивают на тестовый ящик, а обмен с боевой 1С отключают, чтобы тестовые заказы не улетели в реальную учётную систему. Об этих различиях — отдельный раздел про конфиги ниже.

Данные: что и в какую сторону переносить

Здесь кроется главная сложность работы с окружениями на Битриксе. В базе данных магазина перемешаны два принципиально разных типа информации, и путать их — прямой путь к потере заказов.

• Структура и настройки. Свойства инфоблоков, типы инфоблоков, highload-блоки, настройки модулей, права доступа, почтовые события, агенты. Это то, что разработчик создаёт и изменяет. Такие изменения должны ехать от dev к prod — их делают в разработке, проверяют на stage, применяют на бою.
• Боевые данные. Заказы, зарегистрированные пользователи, актуальные остатки и цены, история платежей, отзывы. Это генерируют покупатели и учётная система. Такие данные ехать «вниз» (на dev/stage) не должны — их наоборот снимают слепком с prod на stage для реалистичного тестирования.

Отсюда золотое правило: структура едет вверх, данные едут вниз, и эти потоки нельзя смешивать. Если вы зальёте всю базу с dev на prod целиком, вы затрёте боевые заказы, которые появились за время разработки. Если зальёте всю боевую базу на dev без обезличивания — получите утечку персональных данных покупателей на машину разработчика. Ни то, ни другое недопустимо.

Практически это означает: боевую базу для staging снимают дампом, обезличивают персональные данные (почты, телефоны, ФИО заменяют на тестовые), отключают боевые обмены и платежи — и только потом заливают на stage. А структурные изменения переносят не дампом, а миграциями, о которых следующий раздел. Дамп базы для переноса структуры — плохая идея: он тащит с собой и данные, и невозможно применить «частично» только нужное изменение.

Миграции структуры вместо правок в админке

Самая частая беда проектов на Битриксе — изменения структуры, которые живут только в базе и нигде не записаны. Разработчик добавил свойство «Гарантия» в каталог через админку на своей копии, всё заработало, задачу закрыли. А на бою этого свойства нет, шаблон падает с ошибкой, и никто не помнит, что именно нужно было создать. Классика.

Лечится это миграциями. Миграция — это версионированный скрипт, который описывает одно изменение структуры или данных кодом, умеет применяться (up) и откатываться (down), и хранится в git вместе с проектом. Вместо «зайди в админку и создай свойство руками» вы пишете миграцию, которая создаёт это свойство программно через API Битрикса, и применяете её одинаково на всех окружениях.

Что это даёт на практике:

• Повторяемость. Одна и та же миграция применяется на dev, stage и prod и даёт идентичный результат. Никакого «а на бою я забыл нажать галочку».
• История в git. Каждое изменение структуры видно в истории коммитов: кто, когда и зачем добавил свойство. Ревью изменений структуры становится возможным.
• Откат. У миграции есть метод отката. Неудачное изменение можно отменить обратной миграцией, а не восстанавливать всю базу из бэкапа.
• Автоматизация. Применение миграций встраивается в деплой: выкатили код — автоматически накатились новые миграции. Ничего не забудется.

Для Битрикса есть готовые инструменты: модуль sprint.migration — самый популярный, с удобной генерацией миграций из уже сделанных в админке изменений, и библиотека arrilot/bitrix-migrations для проектов на composer. Оба решают одну задачу: превратить хаотичные клики в админке в версионированный, воспроизводимый код.

Код против контента: главный конфликт Битрикса

В отличие от «чистых» фреймворков, Битрикс хранит в базе не только данные, но и часть логики: настройки компонентов, цепочки бизнес-процессов, шаблоны почтовых событий, правила ЧПУ. Это создаёт фундаментальное напряжение: одни и те же таблицы содержат и то, что должно ехать с кодом (структура), и то, что генерят покупатели (данные). Разделить их — центральная задача организации деплоя.

Практический подход — провести чёткую границу и для каждой сущности решить, где её «источник правды»:

Отдельного внимания требует контент, который создаёт контент-менеджер прямо на боевом сайте: тексты страниц, баннеры, SEO-настройки разделов. Если такой контент правится на prod, а разработка идёт на stage, эти изменения не должны затираться при деплое. Именно поэтому деплой кода не трогает базу напрямую, а работает только через миграции — контент, введённый на бою, остаётся на месте.

Для аккуратного управления выкаткой отдельных доработок хорошо помогают фича-флаги и управление релизами на Битрикс: код можно выкатить на prod заранее, но включить новую функциональность отдельным флагом только после проверки. Это развязывает момент деплоя кода и момент запуска фичи для покупателей.

Схема безопасного деплоя релиза

Деплой — это не «залил файлы по FTP», а последовательность шагов, каждый из которых можно проверить и при необходимости откатить. Безопасная выкладка релиза на боевой магазин выглядит так:

1. Заморозка релиз-кандидата. Код собран в git-ветке релиза, все миграции добавлены, ветка проверена на stage. Ничего нового в неё уже не вливается.
2. Прогон на staging. На свежий слепок боевых данных накатываются код и миграции. Прогоняются ключевые сценарии: оформление заказа, оплата в тестовом режиме, обмен с тестовой 1С, работа фильтра и корзины.
3. Резервная копия prod. Перед выкладкой снимается бэкап боевой базы и файлов. Это точка возврата на случай худшего сценария.
4. Выкладка кода. Новый релиз разворачивается в отдельную папку, символическая ссылка переключается на неё атомарно. Покупатели не видят полусобранного сайта.
5. Применение миграций. На боевой базе накатываются новые миграции структуры. Данные при этом не затираются — меняется только структура.
6. Сброс кэша и прогрев. Чистится кэш компонентов и композита, прогреваются ключевые страницы, чтобы первый покупатель не попал на «холодный» сайт.
7. Дымовая проверка (smoke-тест). Быстро проверяются главная, карточка товара, корзина, оформление заказа — что ничего не сломалось на бою.
8. Наблюдение. После выкладки 15–30 минут смотрят логи ошибок и метрики: не полезли ли 500-е, не упала ли конверсия оформления.

Ключевая идея — атомарность и обратимость. Выкладка кода через переключение символической ссылки атомарна: в любой момент на сайте либо старый релиз целиком, либо новый целиком, но не «половина файлов старых, половина новых». А наличие бэкапа и обратных миграций делает каждый шаг обратимым. Подробнее автоматизацию этого процесса мы разбираем в статье про CI/CD и автоматический деплой на Битрикс.

Реализация в 1С-Битрикс

Перейдём от принципов к конкретике платформы. У Битрикса есть свои особенности, которые нужно учитывать при построении контура окружений, — и штатные инструменты, которые помогают.

Структура файлов. Битрикс делит файлы на ядро (папка bitrix/), которое обновляется через SiteUpdate, и код проекта: шаблоны в local/templates/ или bitrix/templates/, свои компоненты и модули в local/. Под git берут именно код проекта — папку local/, публичную часть с шаблонами и скрипты миграций. Ядро bitrix/ и загруженные пользователями файлы (upload/) в репозиторий обычно не кладут: ядро обновляется своим механизмом, а upload синхронизируют отдельно.

Использование папки local/. Это ключ к чистому деплою. Весь кастомный код — компоненты, модули, обработчики событий, шаблоны — держат в local/, отделяя от ядра. Тогда обновление Битрикса не затирает ваши доработки, а деплой касается только предсказуемого набора папок. Проекты, где кастом размазан по bitrix/, деплоить безопасно почти невозможно.

Миграции через sprint.migration. Модуль устанавливается в проект, хранит миграции в отдельной папке под git и умеет две вещи: генерировать миграцию из уже сделанного в админке изменения (удобно — покликал, получил код) и применять миграции пачкой. Схематично рабочее место с миграциями выглядит так:

Резервное копирование. У Битрикса есть штатный модуль резервного копирования, но для боевого магазина надёжнее серверные средства: mysqldump (или xtrabackup для больших баз) по расписанию плюс копия файлов. Важно не только делать бэкапы, но и регулярно проверять восстановление — бэкап, из которого ни разу не разворачивали копию, стоит считать несуществующим.

Композитный кэш и деплой. На боевом магазине почти всегда включён композит. При деплое его нужно корректно сбрасывать и прогревать, иначе покупатели увидят кэш старой версии страницы поверх нового кода. Сброс кэша — обязательный шаг процедуры выкладки.

Как поднять staging пошагово

Разберём минимальный, но рабочий вариант — отдельный staging на том же или соседнем сервере. Это тот уровень, с которого стоит начинать, даже если пока нет Docker и CI/CD.

1. Выделите окружение. Заведите поддомен вида stage.magazin.ru с отдельным виртуальным хостом. Убедитесь, что версии PHP, СУБД и веб-сервера совпадают с боевыми.
2. Снимите слепок prod. Сделайте дамп боевой базы и копию файлов проекта (папку local/, публичную часть, upload/). Это основа staging.
3. Обезличьте данные. В дампе замените реальные почты, телефоны и ФИО клиентов на тестовые. Так вы не нарушите работу с персональными данными и не разошлёте случайно письма реальным покупателям.
4. Разверните копию. Залейте базу и файлы на staging, пропишите новые настройки подключения в .settings.php и dbconn.php, поправьте лицензионный ключ, если требуется отдельный.
5. Отключите боевые интеграции. Переведите платёжные системы в тест, заглушите или заверните почту и SMS, отключите обмен с боевой 1С. На staging не должно быть ни одного канала, ведущего в реальный мир.
6. Закройте от чужих и от поисковиков. Поставьте базовую HTTP-авторизацию или доступ по IP, добавьте запрет индексации (robots.txt с Disallow: / и заголовок X-Robots-Tag: noindex).
7. Подключите git и миграции. Заведите репозиторий с кодом проекта, установите модуль миграций, зафиксируйте текущее состояние структуры как исходную точку.
8. Пропишите процедуру обновления staging. Опишите, как регулярно освежать слепок боевых данных, чтобы staging не «протухал» и отражал актуальное состояние prod.

Docker, CI/CD и автоматизация выкладки

Ручной staging — хорошая отправная точка, но у него есть слабое место: окружения всё равно чуть-чуть разъезжаются. У одного разработчика PHP 8.1, у другого 8.2, на сервере третья конфигурация. Здесь на сцену выходит контейнеризация.

Docker упаковывает окружение — версию PHP, набор расширений, веб-сервер, настройки — в образ, который одинаково запускается на ноутбуке разработчика, на staging и на боевом сервере. Это убивает целый класс проблем «у меня локально работало». Разработчик поднимает у себя ровно ту же связку, что крутится на бою, и расхождения окружений просто исчезают. Подробно связку Docker и Битрикса мы разбираем в статье про Docker и контейнеризацию 1С-Битрикс.

CI/CD (непрерывная интеграция и доставка) автоматизирует то, что раньше делалось руками. Пайплайн срабатывает на пуш в git и по шагам: собирает проект, прогоняет линтеры и тесты, деплоит на staging, а после подтверждения — на prod с применением миграций и сбросом кэша. Человек нажимает одну кнопку (или процесс идёт сам по правилам), а не выполняет двадцать ручных операций, в каждой из которых можно ошибиться.

Не нужно сразу прыгать на продвинутый уровень — это частая ошибка. Двигайтесь по зрелости: сначала стабильный staging и миграции, потом скрипт деплоя с откатом, и только когда релизы станут частыми — Docker и полноценный CI/CD. Автоматизация имеет смысл там, где есть что автоматизировать; на проекте с релизом раз в квартал сложный пайплайн будет простаивать.

Откаты и резервные копии

Никакой staging не даёт стопроцентной гарантии: боевые данные всегда чуть отличаются, нагрузка выше, всплывают неожиданные сценарии. Поэтому второй столп безопасного деплоя после проверки на stage — готовность откатиться. Откат нужно проектировать заранее, а не изобретать в момент аварии под давлением.

Что откатывать и как:

• Код. При деплое релизов в отдельные папки откат — это переключение символической ссылки на предыдущий релиз. Секундная операция. При деплое через git — откат до предыдущего тега/коммита.
• Структура базы. Обратные миграции (метод down) отменяют изменения структуры. Важно: обратные миграции нужно тоже тестировать на stage, иначе в момент аварии выяснится, что откат не работает.
• Данные. Если релиз повредил данные (редкий, но тяжёлый случай), восстановление идёт из резервной копии, снятой прямо перед деплоем. Поэтому бэкап перед выкладкой обязателен.

Ключевая метрика зрелости — время восстановления. Задайте себе вопрос: если релиз положил витрину, за сколько мы вернём её в рабочее состояние? Если ответ «за минуты» — вы готовы к деплою. Если «за часы» или «надо разбираться» — деплой преждевременен, сначала нужно настроить быстрый откат. Практику отката через git-workflow для Битрикса подробно разбирают в отдельных материалах по DevOps.

Секреты, конфиги и различия окружений

Окружения обязаны отличаться настройками: разные базы, разные ключи платёжных систем, разные адреса интеграций. Хранить эти различия прямо в коде — ошибка: рано или поздно боевой пароль утечёт в git или staging начнёт стучаться в боевую платёжку. Правильный подход — вынести настройки окружения наружу и не коммитить секреты.

Практические приёмы для Битрикса:

• Разделяйте конфиг и код. Файлы подключения (.settings.php, dbconn.php) и локальные настройки не кладите в общий репозиторий или храните шаблонами с подстановкой значений на каждом окружении.
• Определяйте окружение флагом. Заведите константу или переменную окружения (например, APP_ENV = prod|stage|dev) и по ней переключайте поведение: боевые платежи только при prod, тестовые — на остальных.
• Глушите опасные каналы на не-prod. Почта, SMS, боевые обмены, эквайринг — всё это должно активироваться только на prod, а на stage/dev автоматически уходить в заглушку.
• Секреты — вне git. Пароли, токены, ключи держите в защищённом хранилище или переменных окружения сервера, а не в коммитах. Утёкший в историю git секрет считается скомпрометированным навсегда.

Хорошая проверка зрелости конфигурации: можно ли развернуть новое окружение, просто подставив набор переменных, не трогая код? Если да — конфиги отделены правильно. Если для нового окружения нужно править исходники — различия зашиты в код, и это техдолг, который аукнется при следующем деплое.

Обмен с 1С и staging: отдельная головная боль

Для интернет-магазина обмен с 1С — критичная и капризная часть, которую staging обязан учитывать особо. Здесь есть две противоположные ловушки, и обе опасны.

Первая — оставить на staging боевой обмен. Тогда тестовые заказы, созданные при проверке, улетят в реальную учётную систему, а тестовые правки товаров могут перезаписать боевые данные в 1С. Категорически нельзя: staging должен быть отрезан от боевой 1С.

Вторая ловушка тоньше — вообще не проверять обмен на staging. Тогда изменение структуры каталога (новое свойство, переименование, другой формат выгрузки) выкатывается на prod непроверенным, и обмен ломается уже на бою: остатки перестают обновляться, цены застывают, заказы не уходят в учёт. Для магазина это тихая, но дорогая авария.

Правильное решение — тестовый контур обмена: отдельная тестовая база 1С или тестовый узел обмена, подключённый к staging. На нём прогоняют выгрузку каталога и загрузку заказов ровно с теми изменениями структуры, что идут в релиз. Так проверяется, что новое свойство корректно маппится, формат выгрузки не сломан, а заказы доезжают. Если полноценную тестовую 1С поднять нельзя, минимум — проверить, что структура инфоблоков после миграций совместима с текущим форматом обмена. Про архитектуру интеграций подробнее — в материалах рубрики Интеграции.

Частые ошибки

• Правят структуру и код прямо на боевом сайте — без staging и без миграций, полагаясь на память и удачу.
• Staging отличается от prod версией PHP или редакцией Битрикса — проверки проходят, а на бою всё равно падает.
• Заливают всю базу с dev на prod целиком — и затирают боевые заказы, накопившиеся за время разработки.
• Тащат боевую базу на dev без обезличивания — персональные данные клиентов утекают на машины разработчиков.
• Оставляют на staging боевые платежи, почту или обмен с 1С — тестовые действия бьют по реальному миру.
• Деплоят без бэкапа и без заранее протестированного отката — при аварии восстановление занимает часы.
• Меняют структуру кликами в админке боя вместо миграций — окружения неизбежно разъезжаются.
• Забывают сбросить композитный и компонентный кэш после деплоя — покупатели видят старую версию поверх нового кода.
• Не обновляют слепок данных на staging месяцами — предпрод «протухает» и перестаёт отражать боевое состояние.
• Хранят пароли и ключи прямо в git — секреты утекают в историю репозитория навсегда.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно оценивать готовность контура окружений и деплоя перед тем, как доверить ему боевой магазин.

1. Контур разделён. Есть отдельные dev, stage и prod, роли не смешиваются, на prod никто не разрабатывает.
2. Staging совпадает с prod. Версии PHP, СУБД, веб-сервера и редакция Битрикса идентичны боевым; данные близки по объёму.
3. Потоки данных разделены. Структура едет вверх миграциями, боевые данные — вниз слепком с обезличиванием, полный дамп «вверх» запрещён.
4. Структура в миграциях. Изменения каталога и настроек оформляются миграциями в git, а не кликами в админке боя.
5. Секреты вынесены. Конфиги окружений отделены от кода, пароли и ключи не лежат в репозитории.
6. Опасные каналы заглушены. На staging платежи в тесте, почта и SMS в заглушке, боевой обмен с 1С отключён.
7. Деплой описан и обратим. Есть регламент выкладки с бэкапом, атомарным переключением релиза и протестированным откатом.
8. Обмен с 1С проверяется. Изменения структуры каталога прогоняются на тестовом контуре обмена до боя.
9. Кэш и прогрев учтены. Процедура деплоя сбрасывает композит и компонентный кэш и прогревает ключевые страницы.
10. Восстановление за минуты. Проверено на учебной тревоге, что prod возвращается в рабочее состояние быстро, а команда знает порядок.

Вывод

Безопасный деплой магазина на 1С-Битрикс держится на трёх опорах: разделённый контур dev/stage/prod, изменения структуры через миграции вместо ручных правок и заранее готовый откат с резервной копией. Staging при этом обязан быть точной копией боевого окружения, а потоки кода и данных — идти навстречу и никогда не смешиваться. Настройте эти вещи — и выкладка изменений перестанет быть рулеткой: релиз станет предсказуемой процедурой, которую не страшно провести даже в высокий сезон. Начать можно с простого поддомена и миграций, а Docker и CI/CD добавить, когда релизы участятся и автоматизация начнёт окупаться.