- Is marein/symfony-lock-doctrine-migrations-bundle a Laravel package?
- No. It is a Symfony bundle that bridges symfony/lock with doctrine/migrations so concurrent migration runs are serialized behind a shared lock. Laravel ships its own migrator, its own service providers, and has no Doctrine Migrations lifecycle to hook into, so there is no architectural fit for a Laravel application. The functional equivalent in Laravel is a Redis or cache atomic lock wrapped around php artisan migrate in your release script, which is a few dozen lines rather than a dependency.
- What problem does this bundle actually solve for concurrent Doctrine migrations?
- It prevents two deploy workers from running Doctrine migrations at the same time by wrapping the migration run in a lock from the Symfony Lock component. This is the canonical fix for the 'two deploy pods both run migrations at once' problem in horizontally scaled rollouts. Without it you risk race conditions, duplicate schema changes, and partial migrations during a release.
- How do I install and register it in a Symfony application?
- Install it with composer require marein/symfony-lock-doctrine-migrations-bundle and register the bundle in config/bundles.php if Symfony Flex does not do it for you. Then add a small config block pointing at a lock store such as database/PDO, Redis, or a Postgres advisory lock. No changes to your existing migration classes are required.
- How do I prevent concurrent migrations in Laravel without this package?
- Wrap the migrator in an atomic cache lock inside your deploy job, for example Cache::lock('migrations', 300)->block(60, fn () => Artisan::call('migrate', ['--force' => true])). This gives you the same serialization guarantee using Laravel's own lock driver, with no extra Composer dependency. Add a check against the migrations table so re-runs stay idempotent. The lock store then becomes the only new operational dependency.
- Do I need to modify my existing Doctrine migration classes to use it?
- No. The bundle decorates the migration command and runtime rather than the migrations themselves, so it is a low-blast-radius insertion into an existing deploy pipeline. Your migration classes stay exactly as they are. The only change is at the deployment entrypoint that invokes doctrine:migrations:migrate.
- Which lock store should I configure, and what happens if the lock store is down?
- You can point it at a database or PDO store, Redis, or a Postgres advisory lock depending on what your infrastructure already provides. The lock is a hard dependency of the deploy path, so if the store is unavailable, migrations will not run at all. Pick a highly available store and set the lock TTL and retry policy so they align with your deploy timeout and readiness probes.
- Which Symfony and PHP versions does this bundle support?
- It targets Symfony 6 and 7 applications that use Doctrine Migrations. Version 1.0.4 adds PHP 8.4 to the CI matrix and widens the accepted version constraints for symfony/lock and doctrine/migrations. There are no breaking changes, deprecations, or API surface changes in that release.
- What are the production risks and maintenance concerns for this bundle?
- Technical risk is low because the code surface is small and the change is purely additive to the deploy pipeline. The real risks are governance and dependency resolution: it has a single maintainer, low release cadence, and a narrow user base, and the widened constraints mean Composer may resolve combinations the maintainer's CI does not exercise. Treat composer.lock as the contract, gate updates to symfony/lock and doctrine/migrations on staging migration runs, and remember the small surface is cheap to vendor or reimplement if the maintainer goes dark.
- What alternatives exist for preventing concurrent Doctrine migrations?
- If your platform already guarantees single-runner execution, such as a dedicated migration job or a Kubernetes Job with --wait, this bundle is defense in depth rather than a requirement. Database-native options include a Postgres advisory lock or MySQL GET_LOCK around the migration command. Because the code surface is small, vendoring or reimplementing the lock wrapper is also a realistic fallback.
- How can I verify that only one deploy worker runs migrations during a rollout?
- Roll it out first to a non-production environment with two concurrent replicas, then confirm that exactly one acquires the lock and the other blocks and no-ops. Check the lock store for contention and watch the deploy logs for the waiting process timing out or proceeding cleanly. Only promote to production once the serialized behavior is observed end to end.