Это один из самых адекватных и часто используемых подходов в реальных Laravel-проектах. Он сочетает в себе автоматизацию CI/CD и надежность atomic deploy через release-папки

Фактически, это связка: - GitLab CI — оркестратор (когда и при каких условиях деплоить) - Deployer — исполнитель (как именно деплоить)

Как это работает:

1. Разработчик мержит код в ветку main 2. GitLab CI запускает pipeline, описанный в .gitlab-ci.yml 3. В pipeline есть stage деплоя, который: - подключается к серверу - запускает команду: dep deploy 4. Deployer выполняет сценарий: - создает новую папку релиза (/releases/...) - подтягивает код (git clone или archive) - выполняет composer install - подключает shared ресурсы (.env, storage) - прогоняет миграции - кеширует конфиги и роуты - переключает симлинк current на новый релиз

Что важно в такой схеме:

- GitLab CI не "деплоит сам" - Он только триггерит Deployer Вся логика деплоя лежит в deploy.php: - какие хосты - какие шаги - какие таски выполнять

Плюсы подхода:

- Полная автоматизация (деплой при мердже) - Atomic deploy (через релизы) - Быстрый rollback: dep rollback - Нет даунтайма - Чистый и предсказуемый процесс - Разделение ответственности: CI — когда Deployer — как

Минусы:

- Нужно поддерживать две конфигурации: .gitlab-ci.yml deploy.php - Требуется настройка SSH-доступов и ключей - Нужно следить за состоянием серверов (диск, права, зависимости)

Типичная структура deploy.php:

- описание хостов (prod, stage) - настройка репозитория - shared файлы: - .env - storage - writable директории - последовательность задач: - deploy:prepare - deploy:vendors - artisan:migrate - artisan:config:cache - deploy:publish

Типичный job в .gitlab-ci.yml:

deploy_production: stage: deploy script: - dep deploy production only: - main

Почему это хороший вариант:

Этот подход закрывает сразу несколько проблем: - убирает ручной деплой - снижает риск ошибок - дает rollback - делает процесс воспроизводимым При этом он не такой тяжелый, как Kubernetes, и не требует сложной оркестрации.

Когда использовать:

- есть команда разработчиков - есть staging/production окружения - важна стабильность релизов - нужно минимизировать даунтайм

Когда это избыточно:

- один разработчик - редкие деплои - небольшой проект без нагрузки В таких случаях проще использовать git pull или простой скрипт. Итог:

Связка GitLab CI + Deployer — это "золотая середина" между простотой и надежностью.

Она дает: - автоматический деплой - контроль над процессом - безопасные релизы И именно такой подход чаще всего встречается в продакшн Laravel-проектах среднего уровня.

Всем добра )