Flamingock: Stages & Pipelines
|
This section documents schema/database evolution using version-controlled migration tools — Liquibase (relational/SQL), Mongock (MongoDB, Java-native) and Flamingock (Mongock’s successor, generalized to any external system) — as described by each tool’s own official documentation: liquibase.org and docs.liquibase.com for Liquibase, docs.mongock.io for Mongock, and docs.flamingock.io for Flamingock — which are the references these pages are written and verified against. This content was generated with the assistance of AI and should be verified against those official docs before being relied on in production. Mongock is now maintained under the Flamingock GitHub organization (github.com/flamingock/mongock), and Flamingock is positioned as its successor — see Coming from Mongock. Readers starting a new project should default to Flamingock unless they have a specific reason to stay on Mongock. This section’s bibliography lists the reference material consulted while preparing these pages. |
Stages
A stage is an ordered group of Changes that execute sequentially, in the order their order attribute defines — the same ordering guarantee Mongock gives a flat list of @ChangeUnit classes
(Mongock: ChangeUnits), but scoped to a named subset
rather than everything Flamingock finds.
Pipelines
A pipeline is one or more stages. Flamingock guarantees ordering within a stage, but explicitly does not guarantee ordering across stages — two stages can, depending on configuration, execute independently of each other’s internal ordering. This is the key structural difference from a single flat changelog: grouping into stages lets you say "these changes must happen in this order" for one subset while leaving a different subset free to run on its own schedule.
Why This Matters for Lifecycle-Scoped Rollout
Splitting changes into stages maps naturally onto deployment lifecycle phases. A common shape is a "pre-deploy" stage (schema changes the new application code depends on, which must complete before the new code starts) and a "post-deploy" stage (cleanup, backfills, or changes that are safe to apply once the new code is already running) — the same expand/contract shape covered in Best Practices:
Configuring stages is done via Flamingock’s setup configuration — see Setup & Stages for the exact configuration shape and how a pipeline ties multiple stages together at startup.