Middle: питання на співбесіді з теми «DevOps»
Найпопулярніші питання з реальних Laravel/PHP співбесід для всіх рівнів
Всі теми
API
Authentication
Authorization
Blade
Broadcasting
Caching
Collections
Database
Debugging
DevOps
Eloquent
Enums
Events
Filament
Files
HTTP та Request
Livewire
Mail
Middleware
MVC та архітектура
Notifications
Pagination
Performance
PHP
Queues
Routing
Scheduling
Search
Seeder
Service Container
Service Providers
Testing
Архітектура
Безпека
Валідація
Конфігурація
Локалізація
Міграції
Сесії
1 питання
Порядок кроків важливіший за їхній перелік: та сама команда, виконана не там, ламає деплой.
Типова послідовність:
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 - роблять саме це: викладають реліз поруч і перемикають симлінк, коли він готовий.