Release Phase Migrations Bundle Laravel Package

Product Decisions This Supports

• Deployment safety for rolling/blue-green releases. The core value is narrow but real: wrapping Doctrine Migration execution in a database advisory lock so that when several app containers boot a "release phase" simultaneously, exactly one runs migrations and the rest wait or no-op. This directly informs whether we invest in deploy-time concurrency guards versus accepting occasional duplicate-migration failures.
• Build vs. buy (and the honest answer here is "build small"). At 5 stars, zero dependents, and a last release in October 2021, this is a ~100–300 line utility, not a platform. The PM decision it best supports is: do we vendor the advisory-lock pattern into our own deploy tooling? The pattern is the asset; the package is not.
• Platform/runtime fit check. Despite being catalogued among PHP packages, this is a Symfony bundle built around Doctrine Migrations, not a Laravel package. For a Laravel roadmap it is a reference implementation, not a dependency — Laravel's migrator has no advisory-lock semantics, so the decision is whether to replicate this pattern in a custom Artisan command or release script.
• Release-phase architecture. It validates the Heroku/Kubernetes "release phase" or init-container model as a first-class deployment stage, informing roadmap work on CI/CD pipeline standardization and whether migrations should be a separate, single-owner job rather than an app-boot side effect.
• Risk-register input. Stale maintenance plus a single-maintainer, low-signal repo is a concrete data point for our dependency intake policy — useful when arguing for minimum-maintenance thresholds.

When to Consider This Package

• You are on Symfony with Doctrine Migrations, deploy multiple concurrent app instances, and run migrations during a release phase or container startup.
• Your database is PostgreSQL (advisory locks are the mechanism; the guarantee is Postgres-specific — MySQL's GET_LOCK is a different contract, and SQLite/others have nothing comparable).
• You want a minimal, auditable guard rather than adopting a heavier migration orchestration tool.
• You are comfortable vendoring or forking it, since upstream activity has effectively stopped.

Look elsewhere — or write ~50 lines yourself — when:

• You are on Laravel. Different migrator, no Doctrine, and the Symfony bundle's service wiring does not transfer. Reimplement the lock around php artisan migrate --force.
• Your deploys are single-instance or serialized by CI; the lock adds complexity with no payoff.
• You need active maintenance, security patching, or support — last release 2021, no dependents, 5 stars. Treat as unmaintained.
• Your orchestration already provides a single-owner migration job (Kubernetes Job with a lease, a dedicated migration pipeline stage). Prefer the platform primitive over an in-process lock.
• You need rollback coordination, migration linting, drift detection, or multi-tenant sharding — this does none of that.

How to Pitch It (Stakeholders)

To executives: This is a small utility that prevents a specific, recurring class of deployment failure — two servers starting at once and both trying to alter the same table. The idea is sound and cheap to reproduce. The package itself is a five-star, unmaintained, zero-adopter project last touched in 2021, so I do not recommend taking it as a dependency. Recommendation: adopt the pattern (serialize migrations behind a database lock during the release phase) and implement it in-house in under a day. Net effect is fewer failed deploys and no new supply-chain risk.

To engineering: It wraps Doctrine Migrations in a PostgreSQL advisory lock during the release phase, so concurrent pods contend for the lock instead of racing on DDL. Correct instinct, thin implementation. We are Symfony-adjacent only if we go that route — for our Laravel services the equivalent is a guarded artisan migrate in a dedicated job. Either way, the durable design is: migrations run in exactly one place, gated by a lock with a timeout, and the app never migrates itself on boot. Treat this repo as the spec, not the dependency.