SqlDBM + GitLab

Everything else in your stack is defined as code and shipped through a pipeline. This is how the data model joins them.

THE PROBLEM

Everything ships through the pipeline except the database

GitLab teams have spent years getting to one place: infrastructure declared in a repository, configuration under version control, and a pipeline that builds, tests and deploys on every merge request. Then there’s the schema. Someone writes an ALTER, someone else runs it during a maintenance window, and the change most likely to break production is the only one that never ran a job.

No job ever runs. Every other change triggers a pipeline. A schema change triggers nothing.
Approval rules stop at the database. Every merge request has required approvers. The script that reshapes production has none.
Defined nowhere durable. Infrastructure, configuration and application logic all live in the repository. The schema they depend on lives only in the database.

THE PATH

The schema joins the pipeline it was always missing from

SqlDBM commits the generated DDL and dbt YAML to the branch you name and opens a merge request against main. From there it’s an ordinary change: your .gitlab-ci.yml runs against it, your approval rules apply to it, and nothing reaches the database until both are satisfied. The same path serves a first build from Forward Engineering and an incremental alter from DataOps.

Without the integration, an ALTER runs by hand and no job runs, no approver. With SqlDBM and GitLab, the data model pushes to a repository, opens a merge request, triggers the pipeline, then merges to the database.

ON EVERY MERGE REQUEST

Your jobs run against the schema

The merge request shows its pipeline the way any other does — stages, jobs, pass or fail — except the change being tested is a table definition. A failing job blocks the schema exactly as it blocks code, and nobody had to build a separate gate to make that true.

GitLab merge request pipeline widget showing lint, validate, dry-run and deploy:staging jobs passed, with approval rules satisfied and the branch protected

Connecting SqlDBM to GitLab

1

Create a personal access token

In GitLab, create a personal access token with read and write access, held by a user with the Developer role or above. GitLab displays it once, so copy it immediately.

2