Введение
Деплой PHP-проекта — это не просто скопировать файлы на сервер и нажать кнопку. Вроде бы элементарная задача, а при реальном деплое часто возникают самые дикие баги и ошибки, которые могут свести с ума любого разработчика или администратора. Сегодня постараюсь разложить по полочкам, как делать деплой максимально надежно и спокойно, чтобы утром не просыпаться от паники с письменным кодом и ошибками на боевом сайте.

Что такое деплой и почему он не такой простой
Прозвучит, может, банально, но деплой — это процесс переноса и запуска вашего PHP-кода в среде, где работают реальные пользователи. То есть у вас есть локальная версия, тестовая (staging) среда, и есть боевой сервер (production). Если код нормально работает локально и в тестах, но после запуска на бою начинаются проблемы — значит процесс деплоя не налажен или сделан “в лоб”.

Деплой — это не только перенос файлов, это ещё и синхронизация конфигураций, зависимостей, подготовки базы, кешей и многих других штук, которые часто упускают из виду. Из-за этого и появляются фатальные ошибки и баги.

Где и когда нужен продуманный деплой
Практически любой проект на PHP требует продуманного деплоя. Даже если у вас простой сайт на WordPress, где кажется, что достаточно просто обновить плагины и залить свежие темы, правильный деплой убережёт вас от внезапных проблем. Если же речь идёт о более серьёзных проектах на Laravel, Symfony, Yii или любом другом фреймворке, то тут процесс почти всегда более сложный и требует автоматизации и строгого подхода.

Кроме публичных веб-сайтов, деплой важен и для внутренних сервисов, API, микросервисов, скриптов и вообще любых систем, где важна стабильность и непрерывность работы.

Практические примеры типичных вариантов деплоя

1. Классический FTP-деплой
Самый топорный способ — залить файлы через FTP/SFTP вручную. Часто это происходит просто потому, что нет настроенного git или CI. Недостаток — человеческий фактор: можно забыть пропустить важный файл конфигурации, случайно перезаписать чужой файлик, а иногда и просто пропустить важный обновлённый скрипт. FTP-деплой не гарантирует атомарности — если процесс оборвётся на середине, сайт окажется в неполной работоспособности.
Пример: залил файлы, забыл обновить config.php на сервере, пошла ошибка с базой данных, сайт уходит в 500.

2. Git + CI/CD пайплайн
Более современный способ — использовать git-репозиторий и запускать автопроцессы (CI/CD), которые при загрузке кода сразу делают деплой. Например, при пуше в ветку main можно запускать скрипты, которые:
— сбрасывают кеши;
— запускают миграции базы;
— компилируют assets;
— перезапускают фоновые процессы.
Здесь вероятность ошибок резко снижается, особенно если автоматизация покрывает все этапы, а код проверяется перед деплоем.
Пример: после пуша в main автоматически срабатывает GitLab CI, который запускает деплой и пересобирает приложение без простоев.

3. Зависимости с composer
Если в проекте используются сторонние библиотеки и фреймворки через composer, важно не забывать запускать composer install после каждого обновления. Иначе сайт может ломаться, потому что не подтягиваются нужные обновления или автозагрузка.
Пример: обновили код, добавили новую зависимость, но не запустили composer install — при вызове функций из новой библиотеки сайт падает с ошибкой “класс не найден”.

4. Миграции базы данных
База данных — это отдельная боль для многих. Чтобы структура таблиц соответствовала новому коду, миграции должны запускаться при деплое. Иногда их запускают вручную, что приводит к человеческому фактору и забывчивости. Хорошая практика — запускать миграции как часть автопроцесса деплоя.
Пример: забыли обновить таблицу users — в коде ожидается новое поле, которого нет в базе, PHP падает с ошибкой.

5. Режим только для чтения (read-only) на время деплоя
При крупных обновлениях удобно "заморозить" базу в режиме для чтения, чтобы никто не создавал и не изменял данные во время деплоя. Это позволяет избежать потенциальной потери данных и несогласованности из-за обновлений с миграциями.
Пример: ставим приложение в maintenance mode на 5 минут, выполняем миграции и обновления, снимаем maintenance — все плавно и без 500 ошибок.

Типичные ошибки и как их избежать

— Конфиг из development не адаптирован под production — например, включена отладка, или неправильные учётные данные для базы. В итоге сайт падает сразу после деплоя. Кабинет разрабатывайте конфигурации под каждую среду и следите, чтобы переменные окружения были корректными.

— Миграции запускаются вручную и там что-то ломается — никто не успел или забыл, база и код рассинхронизированы. Совсем плохо, когда миграции висят в подвешенном состоянии.

— OPcache не сбрасывается либо используется кеш старых версий файлов — из-за этого PHP продолжает работать по старым скриптам, а обновления игнорируются. Важно после копирования кода делать перезагрузку веб-сервера или сброс кеша.

— Неправильные права доступа — когда web-сервер не может прочитать или записать нужные файлы, приводит к ошибкам 403 или 500. Чекать права надо обязательно, особенно если деплой идёт с разными юзерами.

— Деплой “на горячую”, когда копируется поверх работающего приложения без switched версии (zero downtime) — могут возникать ситуации, когда в какой-то момент кода нет или он частично загружен, зеленые функции вызывают ошибки. Отличное решение — деплой с переключением через симлинки или специальные инструменты.

Полезные инструменты для хорошего деплоя

— Git + вебхуки (GitLab CI, GitHub Actions, Jenkins) для автоматизации и контроля процесса. Так вы можете быть уверены, что каждый деплой пройдет по одинаковой схеме.

— Deployer (deployer.org) — очень удобный PHP-фреймворк для деплоев, который делает миграции, чистку кеша, переключение версий и многое другое “из коробки”. Помогает избежать рутины и человеческих ошибок.

— Envoyer — сервис от Laravel для деплоя без простоев с автоматическим переключением. Особенно полезен, если у вас нагрузка и нельзя позволить даже пару секунд недоступности.

— Composer — управление всеми зависимостями проекта. Используйте всегда composer, чтобы гарантировать, что на сервере точно рабочий набор библиотек.

— Supervisor — если у вас есть фоновые процессы (очереди, воркеры), обязательно организуйте их автоподнятие и рестарт после деплоя. Это облегчит работу с воркерами и не даст им зависнуть на старом коде.

Чек-лист перед деплоем

1. Убедиться, что все миграции базы готовы и протестированы.
2. Проверить актуальность и корректность конфигов для текущей среды.
3. Запустить composer install/update на сервере.
4. Очистить кеш (OPcache, кеш фреймворка).
5. Проверить и выставить корректные права на файлы и папки.
6. Поставить сайт в maintenance mode (если необходимо).
7. Автоматически или вручную выполнить миграции.
8. Перезапустить фоновые процессы (если есть).
9. Снять maintenance mode и проверить сайт.
10. Мониторить логи на предмет ошибок после деплоя.

FAQ по деплою PHP-проектов

В: Что делать, если после деплоя сайт падает с ошибкой 500?
О: Проверяйте логи веб-сервера и PHP, возможно, проблемы с правами, отсутствием зависимостей или неправильным конфигом. Проверьте, запущены ли миграции, и перезагрузите кеш OPcache.

В: Как сделать, чтобы деплой не ломал пользователей и не вызывал downtime?
О: Используйте zero-downtime деплой через инструменты типа Envoyer или deployer с переключением между версиями через симлинки. Также можно ставить проект в maintenance mode на время обновления.

В: Нужно ли запускать миграции автоматически?
О: Желательно, чтобы миграции запускались как часть CI/CD, это снижает риск забыть или запустить их неправильно вручную.

В: Что делать, если изменился состав зависимостей?
О: Запускайте composer install на сервере каждый раз после изменения composer.json.

В: Как работать с кешами после деплоя?
О: После копирования нового кода нужно сбрасывать кеш OPcache (перезапуск PHP-FPM/Apache) и кеши фреймворка (архивы, сессии и т.п.).

В: Как обеспечить безопасность конфигурации при деплое?
О: Отделяйте конфиги для продакшена от development, используйте переменные окружения и не храните секреты в публичном репозитории.

Если вкратце — хороший деплой это про автоматизацию, контроль и внимание к деталям. Иначе от мелких ляпов утром ничто не спасёт. Удачного кодинга!