Деплой

Деплой

Несколько практических правил выкладки изменений на боевой сервер. Конкретные адреса, доступы и креды держите вне публичной документации и вне репозитория (в .env и в личных заметках).

Архитектура веба

Типичная боевая схема: nginx спереди отдаёт всю статику (css/js/img) напрямую, а PHP проксирует в Apache/PHP-FPM (он читает .htaccess). Из этого следуют ключевые правила ниже.

После правки шаблонов (.tpl)

Скомпилированные шаблоны кешируются в storage/cache/tpl/. После изменения .tpl на проде очистите кеш:

rm -f storage/cache/tpl/*

Локально кеш инвалидируется по времени изменения файла автоматически; в админке есть Настройки → Производительность → Очистить кеш. Также полезно перезагрузить PHP-FPM, чтобы сбросить opcache.

После правки статики (.css/.js)

nginx кеширует статику надолго (например, 30 дней). После изменения файла увеличивайте версию в подключении:

<link rel="stylesheet" href="/templates/<theme>/assets/landing.css?v=6">

?v=6 → ?v=7. Иначе вернувшиеся посетители получат старую версию из кеша. Кеш-заголовки настраиваются в конфиге nginx, а не в .htaccess (для статики .htaccess не отрабатывает — её отдаёт nginx).

Права на файлы

Файлы сайта обычно принадлежат отдельному системному пользователю. После копирования новых файлов восстанавливайте владельца (chown) и при необходимости права, чтобы PHP-процесс мог читать/писать (storage/, public/assets/plugins/).

База данных

• Локаль — PostgreSQL, прод — MySQL: пишите кросс-СУБД код (см. Миграции).
• Перед DELETE/ALTER на проде — бэкап (mysqldump нужной таблицы) и узкие условия WHERE.
• MySQL неявно коммитит DDL — учитывайте при расчёте на откат.

Грабли (не наступать)

Проверка после деплоя

Простой self-test главной страницы (с User-Agent, чтобы не сработали bot-фильтры):

curl -s -o /dev/null -w '%{http_code}' -A "Mozilla/5.0" https://<домен>/

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