- Concept
- Version · 6.0
- Deliver
Design your deployment pipeline
Last updated: September 29, 2026
The docs explain the pieces separately: the setup-liquibase action, flow files, policy checks, operation reports. This page is one opinionated way to assemble them, drawn from implementations that work in production.
Four workflows cover the lifecycle. Adapt the trigger conditions to your branching model; the shape holds either way.
The four workflows
Workflow | Trigger | What it does | Fails when |
|---|---|---|---|
Pre-merge CI | Pull request opened against a shared branch | Runs changelog- | A check violates at blocking severity |
Deploy (CD) | Push or merge to a shared branch | Deploys pending changesets, generates an update report | A pre-deploy check or the deployment fails |
Manual deploy | Run on demand, environment chosen at run time | Ad-hoc deployment to a named environment | Same as CD |
Rollback | Run on demand | Rolls back the last update, generates a rollback report | Rollback fails, or no rollback is defined for a changeset |
Why these four
Pre-merge is separate from deploy because feedback is cheapest before the merge. Changelog-scoped checks need no database connection, so this workflow runs in seconds on any runner and tells the developer about a problem while they still have the change in their head. Just as importantly, a policy violation blocks a merge. Leaving the branch as the only thing in a bad state, rather than an environment half-deployed.
Manual deploy exists because ad-hoc deployments always happen. A demo needs a schema change at 4pm on a Thursday. The choice is not whether that happens; it's whether it happens through the same tooling, with the same checks and the same audit trail, or by someone opening a SQL client. Give it a button.
Rollback is a button, not a runbook. The entire point of planning a rollback strategy in advance is that recovery doesn't depend on someone improvising under pressure. If rolling back requires a person to remember a command, you don't have a rollback strategy.
Put the commands in a flow, not in pipeline YAML
The single most useful structural decision: your pipeline YAML should do almost nothing.
Everything else. The command sequence, the checks, the conditionals, the report generation - lives in the flow file. Three reasons this matters:
Portability. The same flow runs identically in GitHub Actions, Azure DevOps, Jenkins, and on a developer's laptop. When you migrate CI tools, you rewrite ten lines of YAML rather than your deployment logic.
Governance. Flows live in a central repository with read-only access for application teams, so the deployment process is one reviewed artifact instead of one per project.
Reproducibility. A developer can run the exact production sequence locally to debug it.
Environment promotion
Map environments to whatever your branching model already uses. Pipeline stages under trunk-based, branches under Gitflow. Two mechanisms control what applies where:
Contexts and labels control which changesets run. A changeset tagged with a context only applies when that context is active, which is how you keep test data out of production.
Separate check-settings files per environment control how strictly changes are judged. Severity should tighten as you approach production. See Policy check roll out best practices.
Keep credentials environment-scoped too, so a QA deployment cannot reach production even by misconfiguration. See Secure your connections.
Reports are the output, not a side effect
Each deploy and rollback generates an operation report. Decide where they go before you need one: emailed, written to object storage, or kept as a pipeline artifact. In an audit, "we can regenerate it" is a much weaker answer than "here it is."
If you run Change Intelligence, these operations also feed its dashboards, which is where the history becomes queryable rather than a pile of files.
A minimal working set
For a first implementation, this is enough:
One repository containing changelogs, flow files, and a
liquibase.checks-settings.confThree environments (dev, QA, production) with scoped credentials
The four workflows above
Changelog-scoped checks in pre-merge; database-scoped checks scheduled post-deploy
Expand from there. Teams that start by building all four workflows and custom checks and multi-schema support at once generally ship none of them.