Питання на співбесіді: DevOps

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

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

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

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

Деплой без простою: користувачі весь час бачать робочу версію.

Atomic (symlink) deploy - кожен реліз клонується в нову папку, там встановлюються залежності й збираються ассети, після чого current атомарно перемикається через symlink:

releases/2026_06_05_120000/ ← новий
current → releases/... ← атомарне перемикання

Кроки на деплої: composer install --no-dev, npm run build, migrate --force, кеш конфіг/маршрутів, перезапуск воркерів (queue:restart) і OPcache.

Інструменти: Envoyer, Deployer, CI/CD-пайплайни, Kubernetes (rolling update). Окрема увага - сумісність міграцій із попередньою версією коду під час перемикання.

Докладніше в документації: Деплой

CI автоматично перевіряє кожен пуш, CD - автоматично доставляє код.

Типовий пайплайн (GitHub Actions / GitLab CI):

- composer install
- vendor/bin/pint --test # стиль
- vendor/bin/phpstan analyse # статичний аналіз
- php artisan test --parallel # тести
- npm ci && npm run build # ассети
# → деплой при успіху

Деплой: SSH-скрипт, Docker-образ у реєстрі + rolling update у Kubernetes, або сервіси на кшталт Forge/Envoyer. На етапі деплою - migrate --force, кешування конфіга/маршрутів, queue:restart. CI/CD дає швидкий зворотний зв'язок і знижує ризик людської помилки при релізі.

Докладніше в документації: Деплой