laravel-verification

Laravel Verification Loop

Run before PRs, after major changes, and pre-deploy.

When to Use

• Before opening a pull request for a Laravel project
• After major refactors or dependency upgrades
• Pre-deployment verification for staging or production
• Running full lint -> test -> security -> deploy readiness pipeline

How It Works

• Run phases sequentially from environment checks through deployment readiness so each layer builds on the last.
• Environment and Composer checks gate everything else; stop immediately if they fail.
• Linting/static analysis should be clean before running full tests and coverage.
• Security and migration reviews happen after tests so you verify behavior before data or release steps.
• Build/deploy readiness and queue/scheduler checks are final gates; any failure blocks release.

Phase 1: Environment Checks

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

• Verify .env is present and required keys exist
• Confirm APP_DEBUG=false for production environments
• Confirm APP_ENV matches the target deployment (production, staging)

If using Laravel Sail locally:

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

Phase 1.5: Composer and Autoload

Phase 2: Linting and Static Analysis

If your project uses Psalm instead of PHPStan:

Phase 3: Tests and Coverage

Coverage (CI):

CI example (format -> static analysis -> tests):

Phase 4: Security and Dependency Checks

Phase 5: Database and Migrations

• Review destructive migrations carefully
• Ensure migration filenames follow Y_m_d_His_* (e.g., 2025_03_14_154210_create_orders_table.php) and describe the change clearly
• Ensure rollbacks are possible
• Verify down() methods and avoid irreversible data loss without explicit backups

Phase 6: Build and Deployment Readiness

• Ensure cache warmups succeed in production configuration
• Verify queue workers and scheduler are configured
• Confirm storage/ and bootstrap/cache/ are writable in the target environment

Phase 7: Queue and Scheduler Checks

If Horizon is used:

If queue:monitor is available, use it to check backlog without processing jobs:

Active verification (staging only): dispatch a no-op job to a dedicated queue and run a single worker to process it (ensure a non-sync queue connection is configured).

Verify the job produced the expected side effect (log entry, healthcheck table row, or metric).

Only run this on non-production environments where processing a test job is safe.

Examples

Minimal flow:

CI-style pipeline: