Автоматизация Laravel: как сделать процесс разработки быстрой и надёжной
Автоматизация 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.
#!/bin/bash
echo "=== Остановка всех контейнеров ==="
docker-compose down
echo "=== Сборка контейнеров ==="
docker-compose build
echo "=== Запуск контейнеров в фоне ==="
docker-compose up -d
# Пауза для запуска сервисов
echo "=== Ждем 5 секунд для старта сервисов ==="
sleep 5
echo "=== Проверка состояния контейнеров ==="
# Получаем статус всех контейнеров
STATUS=$(docker-compose ps --services --filter "status=running")
if [ -z "$STATUS" ]; then
echo "Ошибка: ни один контейнер не запущен!"
exit 1
else
echo "Запущенные контейнеры:"
docker-compose ps
fi
# Дополнительно можно проверять HEALTHCHECK каждого контейнера
echo "=== Проверка состояния HEALTH ==="
docker ps --filter "health=unhealthy" --format "table {{.Names}}\t{{.Status}}"
echo "=== Скрипт завершен ==="
exit 0
Таким образом, перед деплоем или важными изменениями можно убедиться, что сборка полностью работоспособна и готова к развёртыванию.
Итоги и ключевые принципы
Автоматизация в Laravel — не «фича», а часть рабочего процесса.
Вот основные практики:
настроенное окружение через Docker Compose;
автоматические проверки стиля (Pint);
статический анализ (PHPStan + Larastan);
Git Hooks и скрипты — «сторожи качества» при коммите и пуше;
обязательное тестирование новых и изменённых классов.
Если внедрить всё это, можно:
сократить время на исправления;
поддерживать единообразный стиль кода;
повысить предсказуемость и стабильность приложения;
и главное — освободить команду для работы над функционалом, а не над «ремонтами кода».
