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

Порядок кроків важливіший за їхній перелік: та сама команда, виконана не там, ламає деплой.

Типова послідовність:

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

Докладніше в документації: Розгортання