Перейти к содержимому
BXWiki

После выкладки сайт сломался - разбор причин

Код выложили, а сайт отвечает ошибкой или ведёт себя не так, как на стенде. Разбираем причины по убыванию частоты, начиная с журналов и состава выкладки.

С чего начать

Смотрим, что именно приехало на сервер:

Окно терминала
cd /home/bitrix/www && git log --oneline -3 && git status --short | head
tail -30 /var/log/php-fpm/bx0-error.log | grep -iE 'fatal|undefined'
# незакоммиченные изменения на боевом - отдельная проблема, видная сразу
# фатальная ошибка в журнале называет файл и строку: с них и начинают разбор

Первый вопрос - совпадает ли выложенное с ожидаемым. Локальные правки прямо на боевом сайте объясняют половину случаев «на стенде работало, а здесь нет».

Сверяем структуру данных со стендом:

$res = CIBlock::GetList([], ['CHECK_PERMISSIONS' => 'N']);
while ($row = $res->Fetch()) { printf("%d %s\n", $row['ID'], $row['CODE']); }
// код ждёт свойство или инфоблок, которых на боевом ещё нет

Код и структура данных едут разными путями. Новое свойство инфоблока, тип плательщика или highload-блок появляются на боевом сайте только миграцией, и забытая миграция даёт ошибку сразу.

Проверяем файл настроек и права:

Окно терминала
git diff HEAD~1 -- bitrix/.settings.php .htaccess | head -20
ls -l /home/bitrix/www/bitrix/.settings.php /home/bitrix/www/local | head
# реквизиты базы и настройки окружения у боевого сайта свои

Файл настроек и файл правил веб-сервера у боевого сайта свои. Их случайная выкладка со стенда меняет реквизиты базы и адреса и роняет сайт мгновенно.

Сбрасываем кэш и проверяем ещё раз:

Окно терминала
rm -rf /home/bitrix/www/bitrix/cache/* /home/bitrix/www/bitrix/managed_cache/*
chown -R bitrix:bitrix /home/bitrix/www/bitrix /home/bitrix/www/local
# сброс кэша и выравнивание прав - два обязательных шага после выкладки

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

Причины

  1. Структура данных не перенесена примерно 30% случаев

    ПризнакОшибка о неизвестном свойстве, пустые выборки или падение на первой странице с новым кодом.

    ПроверкаСверяем список инфоблоков, свойств и своих таблиц с тем, что ждёт код.

    Что делатьПрогоняем миграции структуры: код без них работать не может, а откат кода лечит только симптом.

  2. Выложены чужие настройки окружения примерно 25% случаев

    ПризнакСайт не подключается к базе или уходит на чужой домен сразу после выкладки.

    ПроверкаСмотрим изменения в файле настроек ядра и в файле правил веб-сервера.

    Что делатьВозвращаем боевые настройки и исключаем эти файлы из выкладки навсегда.

  3. Права на файлы после выкладки не те примерно 20% случаев

    ПризнакОшибки записи в кэш и каталог загрузок, административная часть частично не работает.

    ПроверкаСмотрим владельца и режим доступа у новых файлов и каталогов.

    Что делатьВыравниваем владельца и права после выкладки: выкладка от другого пользователя меняет их.

  4. Работает старый кэш примерно 15% случаев

    ПризнакЧасть страниц показывает прежнюю вёрстку или прежние данные, часть работает правильно.

    ПроверкаСбрасываем кэш компонентов и композита и проверяем страницу ещё раз.

    Что делатьДобавляем сброс кэша в порядок выкладки, а не сбрасываем его руками по памяти.

  5. Потерялись файлы, которых нет в репозитории примерно 10% случаев

    ПризнакПропали картинки, загруженные документы или сгенерированные файлы решения.

    ПроверкаСравниваем каталог загрузок и служебные каталоги до и после выкладки.

    Что делатьИсключаем пользовательские файлы из синхронизации: репозиторий хранит код, а не загрузки.

Частые вопросы

Что откатывать в первую очередь?

Код, если сайт не работает целиком, и только потом разбираться. Данные и структуру откатывают из копии, и это дольше, поэтому копию делают до выкладки.

Почему на стенде работает, а на боевом нет?

Обычно из-за структуры данных и настроек окружения: они на стенде свои. Код одинаковый, а инфоблоки, свойства и настройки модулей - нет.

Нужно ли выкладывать файл настроек ядра?

Нет, он у каждого стенда свой. Общие значения выносят в отдельный файл окружения, а реквизиты базы держат вне репозитория.

Как избежать проблем с правами?

Выкладывать от того же пользователя, от которого работает веб-сервер, и проверять права после выкладки. Разовое выравнивание прав скриптом решает уже случившееся.

Что делать с загруженными файлами?

Держать их вне репозитория и синхронизировать отдельно. Каталог загрузок растёт независимо от кода, и его перенос - отдельная задача.

Смежное

Первоисточник