Как устроен процесс деплоя и инфраструктура

Что проверяют

Понимаете ли вы, как ваш PHP-код физически попадает на сервер и что его окружает: кто принимает запрос, где живут сессии и очереди, что происходит в момент переключения версии. Уточнение обычно про простой: будет ли даунтайм и что станет с запросами, пришедшими во время выкладки.

Как отвечать

Опишите реальную схему своего проекта: путь запроса и путь релиза.

Путь запроса: балансировщик, nginx, php-fpm с пулом воркеров, дальше MySQL или PostgreSQL, Redis для кеша и сессий, брокер очередей и отдельные процессы-воркеры. Если серверов несколько, сессии и загруженные файлы не должны лежать на локальном диске.

Путь релиза:

• сборка: в CI composer install --no-dev --optimize-autoloader, сборка фронта, PHPUnit и PHPStan. На сервер едет готовый артефакт или Docker-образ, а не git pull с установкой зависимостей на проде;
• атомарное переключение: Deployer или похожая схема с каталогами releases/ и симлинком current, который меняется одной операцией. В Kubernetes ту же роль играет rolling update;
• OPcache: в проде обычно opcache.validate_timestamps=0, поэтому после выкладки нужен reload php-fpm или сброс кеша, иначе крутится старый код;
• миграции: php artisan migrate --force или doctrine:migrations:migrate отдельным шагом, совместимые со старой версией кода;
• воркеры: долгоживущие процессы держат старый код в памяти, их перезапускают через php artisan queue:restart или messenger:stop-workers под присмотром Supervisor.

Где спотыкаются

Не учитывают кеш путей при деплое через симлинк. Если nginx передаёт в SCRIPT_FILENAME путь через $document_root, а не $realpath_root, OPcache и realpath-кеш продолжают отдавать файлы старого релиза.

Удаляют или переименовывают колонку в одном релизе с кодом. Пока старые воркеры ещё работают, они падают. Такие изменения разносят на два релиза: сначала код перестаёт читать колонку, потом миграция её убирает.

Отвечают общими словами про «CI/CD и облака», не назвав ни одного конфига, который правили сами.