Автоматизация Laravel: как сделать процесс разработки быстрой и надёжной⁠⁠

Разработка на Laravel становится действительно эффективной, если автоматизировать каждую стадию — от поднятия окружения до тестирования и проверки кода. В этой статье я расскажу, как выстроить рабочий процесс, который минимизирует рутинную работу, повышает качество кода и ускоряет выпуск новых фич.

Материал рассчитан на тех, кто уже знаком с Laravel и хочет внедрить автоматизацию: проверки, стиль, статический анализ, готовый Docker-Compose и др. Ниже — конкретные инструменты, советы и примеры из реального проекта.

Все актуальные скрипты и примеры можно посмотреть в репозитории:
https://github.com/prog-time/git-hooks

Буду рад если вы поддержите репозиторий ⭐️ или напишете свои предложения в раздела Issues

Подготовка окружения через Docker Compose

Я предпочитаю начинать любой Laravel-проект с надёжной конфигурации Docker Compose.

Это даёт:

• изолированное окружение разработки, тестирования, мониторинга;

• независимые контейнеры, чтобы компоненты не мешали друг другу;

• быстрое развёртывание и минимизацию «работы вручную».

Сервисы, которые я поднимаю:

• php-fpm — чтобы исполнять PHP-код,

• PostgreSQL — база данных,

• Redis — кэш и очереди,

• Grafana + Loki — для логов и мониторинга,

• pgAdmin — интерфейс к БД,

• queue - контейнер для очередей запускает php artisan queue:work.

Каждый сервис — в отдельном контейнере. Это даёт гибкость: можно обновлять один сервис без простоя остальных, менять версии без конфликта, и так далее.

Пример docker-compose.yml

Совет: Используйте готовые шаблоны docker-compose.yml, сразу поднимающие весь стек. Это экономит время при старте проекта.

Поддержка единого стиля кода с Laravel Pint

Чтобы соблюдать PSR-12 и единый стиль кода, я пользуюсь laravel/pint.

Пакет Pint для Laravel:

• автоматически форматирует файлы PHP по заданным правилам,

• позволяет не думать вручную о расстановке скобок, отступах и т.д.

Пример конфигурации pint.json

Запуск Pint перед коммитом гарантирует, что весь код будет в нужном стиле — не нужно править вручную после ревью.

Статический анализ: PHPStan + Larastan

Чтобы ловить ошибки на раннем этапе, я использую связку phpstan/phpstan + nunomaduro/larastan.

Они помогают:

• находить ошибки типов,

• выявлять недостающие проверки,

• предупреждать баги до запуска приложения.

Пример phpstan.neon

Преимущества:

• баги выявляются ещё до запуска кода;

• повышается стабильность и надёжность проекта;

• интеграция в процесс разработки минимально мешает.

Git Hooks и shell-скрипты для проверок

Для поддержания качества кода я использую Git Hooks, которые автоматически проверяют код перед коммитом и пушем. Все проверки вынесены в отдельные shell-скрипты, что позволяет гибко настраивать их для разных проектов.

Основные подходы:

1. Pre-commit: проверка изменённых файлов

• Проверяются только новые или изменённые файлы, что ускоряет процесс;

• Скрипты запускают Pint и PHPStan, автоматически исправляют стиль и выявляют ошибки;

• Если проблем нет, коммит продолжается без задержек.

2. Постепенное исправление старых ошибок

• Для старых проектов скрипты проверяют, что количество ошибок в файле уменьшилось хотя бы на 1–2 по сравнению с предыдущим коммитом;

• Такой подход позволяет внедрять проверки без блокировки разработки.

3. Проверка наличия тестов для классов

4. Проверка работы Docker-сборки

Совет: интегрируйте эти скрипты с самого начала проекта, чтобы автоматизация стала частью привычного рабочего процесса.

Shell скрипт для работы с PHPStan

Скрипт для работы с PHPStan

Shell скрипт для работы с Pint

Скрипт для работы с Pint

Проверка наличия тестов для классов

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

Скрипт получает список изменённых и добавленных PHP-файлов и ищет соответствующий тестовый файл в директории tests.

Например, если в проекте есть класс app/Services/UserService.php, скрипт потребует создать файл теста tests/Unit/Services/UserServiceTest.php. Таким образом, любой новый или изменённый класс обязательно должен иметь соответствующий тест, что помогает поддерживать качество и надёжность кода.

Это скрипт, который постоянно дополняется, поэтому актуальную версию вы можете посмотреть здесь - https://github.com/prog-time/git-hooks

Проверка работы Docker сборки

Не менее важно регулярно проверять работу Docker сборки. Для этого я создаю отдельный shell-скрипт, который перезапускает все контейнеры и проверяет, что они успешно запустились. Такой подход позволяет убедиться, что изменения в конфигурации или коде не нарушили работу сервисов и приложение корректно поднимается в локальной среде.

Скрипт может автоматически останавливать текущие контейнеры, заново собирать их и запускать в фоне. После запуска выполняется проверка состояния через docker ps или docker compose ps, чтобы убедиться, что все контейнеры находятся в статусе healthy или up.

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

Итоги и ключевые принципы

Автоматизация в Laravel — не «фича», а часть рабочего процесса.

Вот основные практики:

• настроенное окружение через Docker Compose;

• автоматические проверки стиля (Pint);

• статический анализ (PHPStan + Larastan);

• Git Hooks и скрипты — «сторожи качества» при коммите и пуше;

• обязательное тестирование новых и изменённых классов.

Если внедрить всё это, можно:

• сократить время на исправления;

• поддерживать единообразный стиль кода;

• повысить предсказуемость и стабильность приложения;

• и главное — освободить команду для работы над функционалом, а не над «ремонтами кода».