Simplytestable Base Migrations Bundle Laravel Package

Product Decisions This Supports

• Multi-service schema governance: This bundle exists to centralize "base" Doctrine migrations shared between two applications (app.simplytestable.com and worker.simplytestable.com) that presumably share a database. It informs build-vs-buy decisions around how you keep schema in sync across worker/web process splits — a common pattern in queue-driven architectures.
• Migration ownership boundaries: Useful mental model for deciding whether shared tables (jobs, tasks, users) live in a "base" migration layer consumed by multiple services, versus being owned by one service with the other reading via APIs or read replicas.
• Roadmap input for platform/schema work: If your roadmap includes splitting a monolith into a web tier + worker tier, this is an example of the coordination cost you'll inherit. It argues for either (a) a dedicated schema/migrations repository, or (b) explicit service ownership with no shared tables.
• Not a Laravel decision: This is a Symfony bundle with zero adoption (1 star, 0 dependents). It is not a candidate for composer require. Its value is as a reference implementation and a cautionary tale, not a dependency.
• Use cases where it maps cleanly: Continuous integration for worker/web parity, database provisioning in test environments, and blue-green deployments where both services must agree on schema version before rollout.

When to Consider This Package

Consider the pattern, not the package, when:

• You run two or more PHP services against a single relational database and need a canonical, versioned base schema before app-specific migrations run.
• Your worker processes (queue consumers, cron, CLI daemons) must start only after the web app's schema is at a compatible version.
• You want an explicit contract layer: "base migrations" that neither service owns, plus per-service migrations layered on top.

Do not adopt this package itself if:

• You are on Laravel — it's a Symfony bundle built around Doctrine migrations and Symfony's bundle registration; it will not integrate cleanly with Laravel's migration system.
• You expect community support or maintenance — 1 star, 0 dependents, and a name tightly coupled to a specific company's domains means it is effectively abandoned/personal.
• You need anything beyond the exact scenario it was built for. It encodes assumptions about SimplyTestable's specific table set.
• You have fewer than two services — a single app should just use its own migration tooling.
• You need documented extensibility, versioning policy, or security review — none of that is present here.

Look elsewhere: Doctrine Migrations directly, a shared "schema" Composer package of your own, or an event-driven/API-boundary approach that avoids shared tables entirely.

How to Pitch It (Stakeholders)

For executives: This is a tiny, single-maintainer Symfony bundle that solves one narrow problem — keeping database structure in sync between a web app and a background worker that share a database. It has effectively no adoption and should not be added as a dependency. It is valuable to us only as a reference point: it shows the coordination overhead of shared-database architectures and helps us decide whether to (a) own a shared schema package ourselves, or (b) avoid shared tables by giving each service clear ownership. Recommendation: no procurement, no integration; treat as prior art.

For engineering: This bundle packages base Doctrine migrations common to two SimplyTestable services. It is a pattern, not a library: a versioned "base schema" applied before each service's own migrations, ensuring worker and web agree on shared tables before startup. We are not going to depend on it (Symfony-only, unmaintained, 1 star, 0 dependents). If we pursue a shared-schema strategy, we should build an equivalent internal package under our own namespace with: explicit ownership of base tables, a compatibility matrix between service versions and base schema versions, CI that fails if a service declares an incompatible base version, and a migration path to eventually remove shared tables. If we pursue service ownership instead, we skip this entirely and use Doctrine/Laravel migrations per service with cross-service contracts enforced by integration tests.

Bottom line: Reference architecture, not a dependency. Adopt the idea only if we have a genuine multi-service shared-database constraint; otherwise, this package is a signal to design around it.