«Давай поправим прямо на боевом, там мелочь» — фраза, после которой магазин иногда ложится в самый неподходящий момент. Разработка и проверка на production — это игра, где выигрыш измеряется сэкономленными минутами, а проигрыш — потерянными заказами, испорченными данными и репутацией. И рано или поздно эта игра проигрывается.
Эта статья — о том, как выстроить правильные окружения для разработки магазина на 1С-Битрикс: зачем нужен staging, как сделать его похожим на бой, как синхронизировать и обезличивать данные и безопасно деплоить изменения. Разберём практику, которая превращает выкатку из риска в рутину. Навести порядок в существующем проекте помогает аудит и оптимизация.
Коротко
- Разработка на боевом сайте — источник простоев и потерянных заказов; изменения обкатывают на staging.
- Staging — окружение, максимально похожее на production по версиям, конфигу и структуре данных.
- Боевую базу на staging переносят с обязательным обезличиванием персональных данных.
- Деплой на бой — через git и CI/CD, атомарно и с готовым откатом, а не ручным FTP.
Почему нельзя разрабатывать на боевом сайте
Боевой сайт — это место, где покупатели прямо сейчас оформляют заказы, а обмен с 1С двигает реальные остатки и деньги. Любое изменение здесь применяется мгновенно и на всех: ошибка в коде, неудачная миграция базы, забытый тестовый режим оплаты — всё это сразу бьёт по клиентам и обороту.
Проблема не только в риске падения. На боевом сайте невозможно спокойно экспериментировать: нельзя «сломать и посмотреть», нельзя проверить обновление, нельзя прогнать тесты, не задев живых пользователей. Отсутствие отдельных окружений превращает каждое изменение в стресс и заставляет команду бояться правок — а значит, магазин развивается медленно и нервно. Правильные окружения снимают этот страх.
Три окружения: dev, staging, production
Зрелая схема разработки на 1С-Битрикс обычно опирается как минимум на три контура, у каждого своя роль.
| Окружение | Для чего | Кто пользуется |
|---|---|---|
| Dev (локальное) | Написание и первичная проверка кода | Разработчик |
| Staging | Обкатка изменений на копии боя | Команда, QA, заказчик |
| Production | Боевой сайт для покупателей | Клиенты |
Изменение движется слева направо: рождается на dev, проверяется на staging и только потом попадает на production. Каждый переход — это фильтр, отсеивающий проблемы там, где их цена минимальна. Чем раньше поймана ошибка, тем дешевле она обходится.
Что такое staging и зачем он нужен
Staging — ключевое звено схемы. Это окружение, максимально похожее на боевое, куда изменения попадают перед выкаткой на production. Его задача — воспроизвести бой настолько точно, чтобы проблема, которая проявилась бы на проде, проявилась здесь — но без последствий для покупателей.
Что даёт staging:
- Проверку в боевых условиях. Изменения тестируются на реалистичной конфигурации и данных.
- Обкатку обновлений. Апдейты Битрикса ставятся сначала здесь.
- Место для приёмки. Заказчик и QA принимают работу, не трогая бой.
- Репетицию деплоя. Сам процесс выкатки отрабатывается заранее.
Именно на staging ловятся классические «на моём компьютере работало» — расхождения между локальной средой и боем. Подробнее о механике деплоя через staging мы пишем в отдельном разборе staging-окружения и деплоя в Битрикс.
Как сделать staging похожим на бой
Ценность staging прямо пропорциональна его сходству с production. Расхождения в версиях или конфиге — главная причина, почему «на staging работало, а на проде упало». Поэтому совпадать должно максимум параметров.
- Версии. 1С-Битрикс и PHP тех же версий, что на бою.
- Конфигурация. Настройки веб-сервера, БД и модулей идентичны боевым.
- Состав системы. Тот же набор модулей, компонентов и доработок.
- Структура данных. Инфоблоки, свойства, торговый каталог совпадают по структуре.
- Отличия — только внешние. Тестовые платёжные шлюзы и песочницы обмена вместо боевых.
Различаться должны лишь реквизиты внешних сервисов и, возможно, объём данных. Всё остальное держат как на бою — иначе проверки на staging дают ложное чувство безопасности. Инфраструктурную основу для этого мы разбираем в статье про хостинг и инфраструктуру на BitrixVM.
Синхронизация и обезличивание данных
Чтобы staging был реалистичным, на него переносят боевую базу — но никогда «как есть». Персональные данные клиентов в менее защищённом окружении — это и риск утечки, и нарушение 152-ФЗ.
Практика такая: боевую базу копируют, чтобы получить реалистичный объём и структуру, а персональные данные заменяют тестовыми значениями. Тогда вы работаете с данными, похожими на боевые по количеству и связям, но без риска раскрыть чьи-то реальные контакты. Аккуратную работу с данными и такими преобразованиями удобно строить через D7 ORM, где выборки и обновления описываются явно и предсказуемо.
Обмен с 1С на непроизводственных стендах
Отдельная зона риска — обмен с 1С. Подключать staging к боевой учётной системе нельзя: тестовые заказы и проверки могут создать реальные документы и испортить настоящие остатки и данные учёта.
- Тестовая база 1С. Обмен на staging идёт с копией или песочницей, а не с боевой 1С.
- Проверка механизма. Форматы CommerceML, обработку ошибок и скорость обмена тестируют на похожих данных.
- Изоляция. Заказы со staging не попадают в реальный учёт и не двигают боевые остатки.
- Безопасность интеграций. Ключи и вебхуки staging отделены от боевых.
Так вы проверяете сам обмен — самое хрупкое место магазина — не рискуя боевыми данными. Про безопасную реализацию интеграционного слоя мы пишем в статье про REST, вебхуки и безопасность.
Деплой с staging на production
Проверенное на staging изменение нужно перенести на бой так же надёжно, как оно было проверено. Ручной перенос файлов по FTP — главный источник простоев и рассинхронизации: что-то забыли, что-то перезаписали, порядок нарушили. Правильный деплой воспроизводим и управляем.
- Код в git. Единый источник истины, а не «файлы на сервере».
- CI/CD. Выкатка автоматизирована и повторяема, а не делается руками.
- Атомарность. Новая версия включается разом (например, переключением симлинка), без промежуточного «полусломанного» состояния.
- Порядок миграций. Изменения БД и обновление кэша выполняются в правильной последовательности.
- Готовый откат. Для рискованных изменений есть быстрый путь назад.
Такой деплой превращает выкатку в рутину без адреналина. Полный разбор процесса — в статье про CI/CD и деплой в Битрикс.
Окружения для QA и приёмки
По мере роста команды к базовой тройке добавляют специализированные контуры. Их можно совмещать со staging или разносить.
- QA-стенд. Для прогона автотестов и ручной проверки перед приёмкой.
- Демо для заказчика. Где клиент принимает работу, не мешая разработке.
- Стенд под фичу. Временное окружение под крупную задачу, чтобы не смешивать её с остальным.
Главный принцип неизменен: тестирование и приёмка идут не на боевом сайте, а там, где ошибка стоит только времени. Как организовать сложные доработки в такой схеме, полезно посмотреть в контексте разработки модулей под Битрикс.
Обновления Битрикса через staging
Обновления платформы — самый очевидный сценарий, где staging окупается сразу. 1С-Битрикс регулярно выпускает апдейты ядра и модулей, в том числе по безопасности, но они меняют ядро и могут задеть кастомизации.
- Ставим на staging. Обновление применяется на копии боя.
- Проверяем сценарии. Оформление, оплата, обмен, ключевые страницы — вручную и автотестами.
- Фиксим совместимость. Если что-то отвалилось, чиним до боя, а не на бою.
- Катим на production. Только после проверки, в согласованное окно, с откатом наготове.
Этот процесс — прямая причина, почему кастомизации важно делать с сохранением обновляемости. Тогда обновления проходят предсказуемо, а не превращаются в аварийный ремонт боевого сайта.
Частые ошибки
- Разработка на бою. Правки сразу на production «по мелочи» — до первого падения.
- Staging не похож на бой. Разные версии и конфиг дают ложную уверенность.
- Реальные ПДн на staging. Утечка и нарушение 152-ФЗ.
- Staging подключён к боевой 1С. Тесты портят реальные данные учёта.
- Деплой по FTP руками. Простои и рассинхронизация файлов.
- Приёмка на production. Заказчик и QA тестируют на живых клиентах.
- Обновления сразу на бой. Апдейт Битрикса рушит кастомизации в проде.
Чек-лист организации окружений
- Три контура. Есть dev, staging и production с чёткими ролями.
- Staging = бой. Совпадают версии, конфиг, состав модулей и структура данных.
- Данные обезличены. Боевая база на staging без реальных ПДн.
- Обмен изолирован. Staging работает с тестовой 1С, не с боевой.
- Код в git. Единый источник истины для всех окружений.
- Деплой через CI/CD. Атомарный, воспроизводимый, с откатом.
- Приёмка вне боя. QA и заказчик работают на staging или демо-стенде.
- Обновления через staging. Апдейты Битрикса обкатываются до production.
Вывод
Правильные окружения — это не «излишество для больших проектов», а базовая гигиена разработки, которая делает изменения магазина предсказуемыми. Dev для написания, staging для обкатки, production для покупателей — эта простая цепочка отсекает проблемы там, где их цена минимальна, и снимает страх перед правками.
Ключевые детали — держать staging похожим на бой, обезличивать данные, изолировать обмен с 1С и деплоить через git и CI/CD, а не руками. Дополнительные окружения требуют ресурсов, но они несопоставимо дешевле простоя боевого магазина. Выстройте окружения один раз — и выкатка перестанет быть игрой с высокими ставками, превратившись в спокойную рутину.
