Your app pipeline stays. Database promotion gets a product.
Migratrix does not replace GitHub Actions or GitLab CI for application delivery. GitOps writes the change script as SQL in Git, opens the pull request, and on merge imports it into a pipeline. Execution still honours per-environment approvals. Merge is not a back door around production.
Write, review, merge, promote
Author in Migratrix
Write the SQL in the editor. Risk analysis and rollback generation attach to the change script before anyone merges.
Review in GitHub or GitLab
OAuth + webhooks. The artefact is SQL, not a proprietary blob. Branch policy stays with the repository you already operate.
Merge imports, it does not execute prod
GitOps pipelines bind to a repository and can auto-start the first environment after import. Later environments still need their gates.
Promote with rollback ready
Approvals, live logs, and a generated down script. The hash-chained audit records who approved and who ran.
What database CI/CD here is not
Not a Flyway or Liquibase runner
Those tools own changelog formats and version tables. Migratrix can review and promote SQL they produce. It does not parse Liquibase XML or apply Flyway version tables. See vs Liquibase and vs Flyway.
Not your application CD
Keep deploying services the way you do today. Migratrix governs the database change that too often remains a manual step in an otherwise automated pipeline.
Not schema-as-HCL
If the team will only accept Atlas-style desired state, that is a different shape. Migratrix vs Atlas.