Weave Code
Release Phase Migrations Bundle Laravel Package
fervo/release-phase-migrations-bundle
A Symfony bundle for Doctrine migrations that adds release phases, letting you group schema and data changes and run them in a controlled order during deployment. Tag migrations by phase, run the right set per release, and keep deployments predictable across environments.
A small bundle allowing you to run Doctrine Migrations within an advisory lock
Frequently asked questions about Release Phase Migrations Bundle
- Can I use fervo/release-phase-migrations-bundle in a Laravel application?
- No. It is a Symfony bundle built on Doctrine Migrations: it ships a Bundle subclass, a dependency-injection extension, and YAML configuration, none of which Laravel's service-provider model uses. No code is directly reusable in a Laravel app. What does transfer is the idea of splitting migrations into ordered deployment phases, which is roughly 150 to 250 lines to reimplement with an artisan command.
- What are release-phase migrations and why split schema changes from data backfills?
- Release-phase migrations tag each migration with a phase such as schema change, data backfill, or post-deploy cleanup, then run each phase at the right moment in a deployment instead of all at once. Phases execute in a deterministic order, so every environment behaves the same way. Rollback is scoped to a single phase, so you can undo one step without unwinding the rest. The bundle plugs into existing Doctrine migration directories rather than introducing new tooling.
- Does fervo/release-phase-migrations-bundle support Laravel 10 or Laravel 11?
- No. There is no Laravel service provider, no migration integration, and no support for Laravel 10 or 11. The package targets Symfony's bundle system and Doctrine Migrations, and its last release was October 2021, well before recent Laravel versions. Installing it in a Laravel app would only add an unused, unmaintained dependency.
- How do I install and configure fervo/release-phase-migrations-bundle?
- You would require it via Composer, register the bundle in config/bundles.php, and supply YAML configuration for phase definitions, all of which are Symfony-specific steps. There is no Laravel installation path, so there is nothing to publish or configure inside a Laravel app. If you only want the behavior, treat the README as a design reference and build the equivalent artisan command yourself.
- How do I stop two deploy replicas from running Laravel migrations at the same time?
- Laravel has no built-in answer, so the practical approach is a custom command such as php artisan migrate:locked that opens a dedicated connection, takes a database-native advisory lock with a bounded wait, runs migrate --force, and releases the lock in a finally block. Use pg_try_advisory_lock on Postgres, GET_LOCK on MySQL, or sp_getapplock on SQL Server; SQLite has no advisory lock, so use a file lock or skip locking. Name the lock per database rather than per application so unrelated apps on a shared instance do not collide. Expect two to four engineer-days including tests.
- Why not use Cache::lock to guard migrations in Laravel?
- Cache locks carry a TTL, so a long-running migration that exceeds it lets a second runner start mid-DDL. Database advisory locks are tied to the session and disappear when the process dies, which is the failure semantic you actually want for migrations. That is why the advisory-lock pattern is materially better than Cache::lock for this use case.
- Will release-phase migrations work behind PgBouncer or a connection pooler?
- The bundle itself does not implement concurrency locking, but if you reimplement the pattern with Postgres advisory locks, the pooler matters: PgBouncer in transaction mode can silently break session-level advisory locks because your session may not stay pinned to one backend connection. Use session pooling or connect directly to Postgres for the migration runner. Verify the lock actually holds before relying on it in production.
- Is fervo/release-phase-migrations-bundle still maintained?
- No. The last release was 2021-10-06, it has around 5 stars and 0 dependents, and there has been no maintainer activity since. Doctrine Migrations major versions released after that will likely break its version constraints outright. Adopting it means adopting an abandoned dependency that does not target Laravel at all.
- How do I test that only one deploy replica runs migrations?
- Spike it on staging with two concurrent runners started at the same moment against one database. Confirm exactly one executes migrations and the other fails fast or waits according to your configured timeout, then measure the lock wait against your deploy pipeline's timeout budget. Also test the failure path: kill the lock holder mid-migration and confirm the lock is released when the session ends. Add alerting on lock failure before enabling it in production.
- Should I fork the Symfony bundle or reimplement the pattern for Laravel?
- Reimplement. The package's only useful content is a pattern worth roughly 150 to 250 lines, so forking and porting the Symfony bundle would take an estimated 5 to 8 days and leave you owning a stale Doctrine dependency. A native artisan migrate:locked command is about 2 to 4 engineer-days with tests and adds no third-party supply-chain risk. Keep plain migrate available as a manual escape hatch.
Weaver
How can I help you explore Laravel packages today?