Выкладка на боевой - порядок, структура, откат
Раскладываем выкладку на шаги, каждый из которых можно отменить: точка возврата, код, структура, кэш и проверка.
Решение
Делаем точку возврата:
git tag -a rel-2026-08-06 -m "выкладка каталога" # к чему вернуться по кодуmysqldump --single-transaction -u user -p base | gzip > /backup/pre-rel.sql.gz# дамп снимают до выкладки: после миграций старый код с новой базой уже не работает# ключ single-transaction снимает дамп без блокировки таблиц на боевомОткат существует только там, где заранее сохранено состояние. Тег даёт возврат по коду, дамп - по данным, и без второго первый спасает лишь до первой правки структуры.
Переносим изменения структуры скриптом:
// migrations/2026_08_06_add_prop.php - применяется один раз и отмечаетсяif (Option::get('vendor.shop', 'migration_last', '') < '2026_08_06') { $prop = new CIBlockProperty(); $prop->Add(['IBLOCK_ID' => 12, 'CODE' => 'WARRANTY', 'NAME' => 'Гарантия']); Option::set('vendor.shop', 'migration_last', '2026_08_06');}Структура переносится тем же путём, что и код, а не руками через интерфейс. Ручная правка на боевом не повторится на стенде, и через месяц два сайта расходятся настолько, что выкладка ломает один из них.
Сбрасываем кэш после выкладки:
BXClearCache(true); // файловый кэш компонентов$GLOBALS['CACHE_MANAGER']->CleanAll(); // управляемый кэш$GLOBALS['stackCacheManager']->CleanAll(); // и стековый заодно// композитные страницы сбрасываются отдельно, из настроек модуляНовый код и старый кэш дают самые непонятные поломки. Половина «правка не доехала» объясняется страницей, собранной до выкладки и живущей в кэше по своему расписанию.
Проверяем ключевые сценарии:
for url in / /catalog/ /catalog/filter/brand-acme/ /personal/cart/; do code=$(curl -o /dev/null -s -w "%{http_code}" "https://example.org$url") printf "%s %s\n" "$code" "$url"done# коды ответа - это минимум: покупку и вход проходят рукамиПроверяют не главную страницу, а деньги: карточку, корзину, оформление и вход. Ошибка в оформлении заказа стоит дороже всех остальных, а видна она только при проходе сценария целиком.
Выкладку стоит делать в спокойное время и вдвоём с тем, кто знает откат. В час пик даже удачная выкладка ощущается как сбой: кэш холодный, база под нагрузкой.
Обмен на время выкладки останавливают. Правка структуры, встретившая запущенный обмен, оставляет половину товаров с новым свойством и половину со старым.
Список шагов стоит держать записанным, а не в голове. Через полгода выкладку делает другой человек, и порядок действий должен быть у него перед глазами.
Каждая выкладка стоит одного короткого разбора после неё. Что задержалось, что пришлось делать руками и чего не хватило в списке шагов - именно из этих ответов и вырастает спокойный релиз.
Типичные проблемы
Правки не видны на боевом сайте.
Страница отдаётся из кэша, собранного до выкладки. Кэш сбрасывают отдельным шагом сразу после переноса файлов.
Откатили код, а сайт всё равно не работает.
Миграция уже поменяла структуру базы. Возврат данных требует дампа, снятого до выкладки.
На боевом нет свойства, которое есть на стенде.
Структуру правили руками через интерфейс. Такие изменения переносят скриптом вместе с кодом.
После выкладки посыпались ошибки прав доступа.
Файлы приехали от другого владельца и с другими правами. Владельца и права выравнивают в том же шаге выкладки.
Половина товаров осталась без нового свойства.
Во время выкладки шёл обмен с учётной системой. Точку обмена останавливают на время работ.
Частые вопросы
Нужно ли выключать сайт на время выкладки?
При изменении структуры и данных - да, коротким окном. Выкладка одного кода обычно проходит незаметно.
Как переносить настройки модулей?
Скриптом миграции вместе с кодом. Значения из интерфейса теряются при следующем переносе базы.
Как понять, что выкладка удалась?
По журналу ошибок за первые минуты и проходу ключевых сценариев. Тишина в журнале - тоже результат.
Что делать, если откат уже невозможен?
Чинить вперёд, а не назад: готовить правку под текущее состояние. Поэтому дамп до выкладки и снимают всегда.
Смежное
-
Git и выкладка - оглавление подтемы
-
После выкладки сайт сломался: разбор причин - что делать, когда выкладка сломала сайт
-
Три контура проекта: разработка, тест, бой и порядок переноса - схема контуров вокруг этой процедуры
-
Git в проекте на платформе: состав репозитория и выкладка - что вообще переносится
-
Сторонняя библиотека в проекте: composer, автозагрузка, выкладка - установка зависимостей в порядке выкладки
-
Миграции структуры: перенос инфоблоков и настроек между стендами - как устроен сам перенос структуры
-
Настройки проекта: файл ядра, опции модуля, разные стенды - что отличается на стендах
-
Резервное копирование: расписание, состав, хранение и проверка - откуда брать дамп
-
Проверки перед выкладкой: синтаксис, стандарт, тесты, миграции - что проверяют до начала выкладки
-
Архитектура проекта - что где лежит в проекте
-
Стенд из копии боевого: подъём, обезличивание, отрезанные связи - откуда правки приезжают
-
Обновление сторонних решений: совместимость, проверка, откат - тот же порядок для чужого кода
-
Тесты для своего кода: что покрывать и как запускать - что прогоняют до выкладки
-
Правки не доехали на боевой: разбор причин - что проверять, когда сайт работает по-старому
-
Перенос инфоблока через XML: структура и данные - перенос данных инфоблока между стендами
-
Сайт на технических работах: заглушка и доступ для своих - чем закрыть сайт на окно простоя