Деплой

Деплой

Кілька практичних правил викладення змін на бойовий сервер. Конкретні адреси, доступи та креди тримайте поза публічною документацією і поза репозиторієм (у .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 — усе гаразд. Перевіряйте й ключові розділи після великих змін.