Laravel 検証ループ

PR を開く前、大きな変更後、デプロイ前に実行してください。

いつ使うか

• Laravel プロジェクトで pull request を開く前
• 大規模なリファクタリングまたは依存関係のアップグレード後
• Staging または production へのデプロイ前の検証
• lint → test → security → deployment readiness の完全なパイプラインを実行する場合

仕組み

• 各層が前の層の上に構築されるようにするため、環境チェックからデプロイ準備まで段階を順序立てて実行します
• 環境と Composer チェックはすべてをカバーします。失敗した場合は即座に停止します
• 完全なテストとカバレッジを実行する前に、lint/static analysis がクリーンである必要があります
• security および migration レビューはテスト後に行われるため、データまたはリリース手順の前に動作を検証します
• build/deployment readiness および queue/scheduler チェックは最後の門です。失敗するとリリースが阻止されます

フェーズ 1: 環境チェック

php -v
composer --version
php artisan --version

• .env が存在し、必要なキーが存在することを確認してください
• Production 環境では APP_DEBUG=false を確認してください
• APP_ENV がターゲットデプロイと一致していることを確認してください (production, staging)

ローカルで Laravel Sail を使用している場合:

./vendor/bin/sail php -v
./vendor/bin/sail artisan --version

フェーズ 1.5: Composer と Autoload

composer validate
composer dump-autoload -o

フェーズ 2: Linting と Static Analysis

vendor/bin/pint --test
vendor/bin/phpstan analyse

プロジェクトが PHPStan の代わりに Psalm を使用している場合:

vendor/bin/psalm

フェーズ 3: テストとカバレッジ

php artisan test

カバレッジ (CI):

XDEBUG_MODE=coverage php artisan test --coverage

CI の例 (format → static analysis → tests):

vendor/bin/pint --test
vendor/bin/phpstan analyse
XDEBUG_MODE=coverage php artisan test --coverage

フェーズ 4: Security と依存関係チェック

composer audit

フェーズ 5: Database と Migration

php artisan migrate --pretend
php artisan migrate:status

• 破壊的な migration は慎重にレビューしてください
• Migration ファイル名が Y_m_d_His_* 形式に従っていることを確認してください (例: 2025_03_14_154210_create_orders_table.php) および変更を明確に説明してください
• ロールバックが可能であることを確認してください
• down() メソッドを検証し、明示的なバックアップなしで回復不能なデータ損失を回避してください

フェーズ 6: Build と Deployment 準備

php artisan optimize:clear
php artisan config:cache
php artisan route:cache
php artisan view:cache

• キャッシュウォームアップが production 設定で成功することを確認してください
• Queue worker と scheduler が設定されていることを確認してください
• ターゲット環境で storage/ と bootstrap/cache/ が書き込み可能であることを確認してください

フェーズ 7: Queue と Scheduler チェック

php artisan schedule:list
php artisan queue:failed

Horizon を使用している場合:

php artisan horizon:status

queue:monitor がある場合、処理する前にジョブが蓄積されていないかチェックするために使用してください:

php artisan queue:monitor default --max=100

アクティブな検証 (staging のみ): custom queue に no-op job をディスパッチして、単一の worker で処理を実行します (non-sync queue connection が設定されていることを確認してください)。

php artisan tinker --execute="dispatch((new App\\Jobs\\QueueHealthcheck())->onQueue('healthcheck'))"
php artisan queue:work --once --queue=healthcheck

ジョブが期待される副作用を生成したことを確認してください (ログエントリ、healthcheck テーブル行、またはメトリック)。

これはテストジョブ処理が安全な non-production 環境でのみ実行してください。

例

最小限のフロー:

php -v
composer --version
php artisan --version
composer validate
vendor/bin/pint --test
vendor/bin/phpstan analyse
php artisan test
composer audit
php artisan migrate --pretend
php artisan config:cache
php artisan queue:failed

CI スタイルのパイプライン:

composer validate
composer dump-autoload -o
vendor/bin/pint --test
vendor/bin/phpstan analyse
XDEBUG_MODE=coverage php artisan test --coverage
composer audit
php artisan migrate --pretend
php artisan optimize:clear
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan schedule:list