Question 1

Що має відбуватися під час деплою Laravel-застосунку?

Accepted Answer

Порядок кроків важливіший за їхній перелік: та сама команда, виконана не там, ламає деплой.
Типова послідовність:
composer install --no-dev --optimize-autoloader
npm ci && npm run build

php artisan migrate --force

php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache

php artisan queue:restart

Чому саме так:

Кешування - після викладення коду. Інакше в кеш потрапить попередня версія конфігурації й маршрутів.
--force для міграцій потрібен, бо в проді Artisan питає підтвердження, а деплой неінтерактивний. Це стосується лише migrate; migrate:fresh у проді не запускають ніколи.
queue:restart обовʼязковий. Воркери - довгоживучі процеси: вони тримають у памʼяті стару версію коду й працюватимуть з нею, поки їх не перезапустити. Це найчастіша причина «код виклали, а черга робить по-старому».

Про що забувають:

Порядок міграції та коду. Видалення колонки у тому ж випуску, що й код, який її ще читає, ламає застосунок у проміжку між кроками. Такі зміни розводять на два випуски.
storage:link після першого розгортання, інакше публічні файли не віддаються.
Права на storage і bootstrap/cache - веб-сервер має писати в обидві.
php artisan down дає режим обслуговування, але з ним застосунок недоступний; безпростійний деплой роблять перемиканням симлінка на новий реліз.

Готові рішення - Envoyer, Deployer, Laravel Cloud - роблять саме це: викладають реліз поруч і перемикають симлінк, коли він готовий.
Докладніше в документації: Розгортання

Question 2

Як перезапускати воркери черг і інші довгоживучі процеси після деплою?

Accepted Answer

Воркер черги, Horizon, Octane, Reverb, schedule:work завантажують код один раз і тримають його в пам'яті. Після деплою вони продовжують виконувати старий код, доки їх не перезапустити.
Команда в Laravel 13:
php artisan reload

Вона завершує ці процеси, а підняти їх знову має монітор процесів: Supervisor, systemd чи оркестратор. Без монітора процеси просто зупиняться.
Окремі команди для конкретних сервісів:

php artisan queue:restart - воркери завершать поточне завдання й вийдуть;
php artisan horizon:terminate - те саме для Horizon;
php artisan octane:reload.

Приклад Supervisor:
[program:laravel-worker]
command=php /var/www/app/artisan queue:work --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
numprocs=2
stopwaitsecs=3600

stopwaitsecs має бути більшим за найдовше завдання, інакше Supervisor уб'є воркер посеред роботи.
Порядок деплою: новий код і optimize → міграції → reload. Воркер, що стартує зі старою схемою й новим кодом (чи навпаки), - типове джерело помилок одразу після релізу.
Докладніше в документації: Перезавантаження сервісів

Question 3

Як запускати Laravel у Docker правильно?

Accepted Answer

Один образ - кілька процесів. Той самий образ запускається як вебсервер, воркер черги й планувальник - різними командами. Код у всіх однаковий, масштабуються вони окремо.
services:
  app:       { image: app:1.4.2, command: frankenphp run }
  worker:    { image: app:1.4.2, command: php artisan queue:work --max-time=3600 }
  scheduler: { image: app:1.4.2, command: php artisan schedule:work }

Що робити під час збирання образу: composer install --no-dev --optimize-autoloader, збирання ассетів, view:cache, event:cache, route:cache.
Що НЕ робити під час збирання: config:cache. У кеш потрапить оточення збирання, а не продакшену - конфігурацію кешують на старті контейнера, коли змінні оточення вже є.
Стан - назовні:

сесії, кеш, черги - Redis чи база, а не файли контейнера;
завантаження - S3-сумісне сховище чи том;
журнали - у stdout/stderr (канал stderr), їх збирає платформа.

Інше:

права на storage і bootstrap/cache для користувача PHP-процесу;
міграції - окремим кроком деплою, не в старті кожного контейнера;
пінити версію базового образу: плаваючий тег може принести нову версію PHP чи бібліотек без вашого відома;
/up - для перевірки стану контейнера.

Докладніше в документації: Оптимізація

Middle: питання на співбесіді з теми «Деплой і DevOps»