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

Правки не доехали на боевой - разбор причин

Код выложен, а боевой сайт ведёт себя по-прежнему. Разбираем причины по убыванию частоты, начиная с самого простого: доехал ли файл до сервера.

С чего начать

Сверяем файл на сервере с тем, что в репозитории:

Окно терминала
md5sum /home/bitrix/www/local/php_interface/init.php
git -C /home/bitrix/www show HEAD:local/php_interface/init.php | md5sum
# разные суммы означают, что файл на сервере другой, и разбор на этом заканчивается

Сверка контрольных сумм отвечает на главный вопрос за секунду. Совпали - файлы доехали, и причина в кэше или в другом контуре; не совпали - разбираем саму выкладку.

Смотрим, что выложено на сервере:

Окно терминала
git -C /home/bitrix/www log --oneline -3
git -C /home/bitrix/www status --short | head
# лишние изменения в рабочем дереве означают правки прямо на боевом сервере

Проверяем кэш кода в памяти:

$status = function_exists('opcache_get_status') ? opcache_get_status(false) : null;
printf("кэш кода: %s, файлов в кэше: %d\n",
    $status ? 'включён' : 'выключен', $status['opcache_statistics']['num_cached_scripts'] ?? 0);
// кэш кода держит прежнюю версию файла до истечения проверки или до перезапуска

Сбрасываем кэш платформы и композит:

$GLOBALS['CACHE_MANAGER']->CleanAll();
\Bitrix\Main\Data\StaticHtmlCache::getInstance()->deleteAll();
BXClearCache(true);
// после выкладки шаблонов и компонентов кэш сбрасывают целиком

Причины

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

    ПризнакКонтрольная сумма файла на сервере не совпадает с суммой из репозитория.

    ПроверкаСверяем суммы и смотрим журнал выкладки: дошла ли она до конца без ошибок.

    Что делатьПовторяем выкладку и разбираем её ошибку, а не ищем причину на стороне сайта.

  2. Кэш кода в памяти держит прежнюю версию примерно 25% случаев

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

    ПроверкаСмотрим настройки кэша кода: включена ли проверка изменений и как часто.

    Что делатьСбрасываем кэш кода после выкладки или включаем проверку изменений по времени.

  3. Страница отдаётся из кэша платформы примерно 20% случаев

    ПризнакИзменения видны под администратором или после сброса кэша, а гостю - нет.

    ПроверкаОткрываем страницу в окне без входа на сайт и сравниваем её содержимое.

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

  4. Правка сделана не в том контуре или не в той ветке примерно 15% случаев

    ПризнакНа боевом сервере нет ни файла, ни коммита с этой правкой в журнале.

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

    Что делатьПереносим правку в нужную ветку и повторяем выкладку по обычному порядку.

  5. Файл перекрыт другим файлом проекта примерно 10% случаев

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

    ПроверкаИщем одноимённые файлы в каталогах проекта и платформы, включая шаблоны.

    Что делатьУбираем лишнюю копию файла и оставляем один источник правды для этого кода.

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

Как быстро понять, доехал ли файл?

Сверить контрольную сумму файла на сервере с суммой из репозитория. Это одна команда, и она делит разбор надвое.

Почему помогает перезапуск обработчика PHP?

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

Нужно ли сбрасывать кэш после каждой выкладки?

После правки шаблонов и компонентов - да, это дешевле разбора жалоб. Шаг сброса включают в саму процедуру выкладки, чтобы о нём не вспоминали.

Почему изменения видит только администратор?

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

Что делать с правками прямо на боевом сервере?

Забрать их в репозиторий, пока они не потерялись при следующей выкладке. Дальше договориться, что боевой сервер меняется только выкладкой.

Смежное

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