Database GitOps with Azure DevOps Pipeline
This is part of our database GitOps series with Bytebase:
- Database GitOps with GitHub Actions
- Database GitOps with Azure DevOps Pipeline (this one)
- Database GitOps with GitLab CI
- Database GitOps with Bitbucket Pipelines
This tutorial shows you how to build a database GitOps workflow using Azure DevOps Pipeline and Bytebase API. You’ll learn to create a streamlined database release workflow where you can:
- Submit SQL migrations through Azure DevOps
- Automatically run SQL reviews on pull requests
- Auto-create and deploy Bytebase releases when merging to
main
While we use Azure DevOps Pipeline in this guide, you can apply these concepts to other CI platforms like GitHub Actions, GitLab CI, or Bitbucket Pipelines using the Bytebase API.
This tutorial code repository is at https://dev.azure.com/bytebase-hq/_git/bytebase-example
Prerequisites
Automatic Rollout across environments
Step 1 - Start Bytebase with ngrok
ngrok is a reverse proxy tunnel that provides a public network address to access Bytebase. We use ngrok here for demonstration purposes.
-
Run Bytebase in Docker with the following command:
-
Once Bytebase is running in Docker, you can access it at
localhost:8080
. -
Log in to the ngrok Dashboard and complete the Getting Started steps to install and configure ngrok. To use a consistent domain, navigate to Universal Gateway > Endpoints to find your assigned domain:
<<YOURS>>.ngrok-free.app
. -
Start ngrok with your domain by running:
You should see output similar to this:
-
You can now access Bytebase at
https://<<YOURS>>.ngrok-free.app
. -
(Optional) To configure SSO (Entra/SCIM), Log in to Bytebase, click Settings > General in the left sidebar. Scroll to the Network section, set
https://<<YOURS>>.ngrok-free.app
as the External URL and click Confirm and update.
Step 2 - Create Service Account
-
Log in as
Workspace Admin
, and go to IAM & Admin > Users & Groups. Click + Add User, fill in withapi-sample
, choose theWorkspace DBA
role sufficient for this tutorial and click Confirm. -
Find the newly created service account and Copy Service Key. We will use this token to authenticate the API calls.
If you have Enterprise Plan, you can create a Custom Role for the service account which require fewer permissions, and assign this role instead of DBA:
- plans.create
- plans.get
- plans.preview
- releases.check
- releases.create
- releases.get
- rollouts.create
- rollouts.get
- rollouts.list
- sheets.create
- sheets.get
- taskRuns.create
- planCheckRuns.list
- planCheckRuns.run
Step 3 - Configure SQL Review in Bytebase
Since you will need to run SQL review on your PRs, you need to configure the SQL review in Bytebase.
-
Go to CI/CD > SQL Review, click Create SQL Review.
-
Select the
Sample Template
and click Next. -
Select
Prod
environment as the attached resources and click Confirm. Now the SQL review is enabled for theProd
environment.
Step 4 - Copy from the Example Repository and Configure Variables
-
Create a new project. Copy
pipelines
folder from https://dev.azure.com/bytebase-hq/_git/bytebase-example. There are two workflows in this repository:pipelines/sql-review.yml
: Lint the SQL migration files after the PR is created.pipelines/rollout-release.yml
: Create a release in Bytebase after the PR is merged to themain
branch.
-
Go into
pipelines/sql-review.yml
andpipelines/rollout-release.yml
. In theenv
section, replace the variable values with your own and commit the changes.- BYTEBASE_URL: your ngrok url
- BYTEBASE_SERVICE_ACCOUNT:
api-example@service.bytebase.com
(the service account you created in the previous step) - BYTEBASE_PROJECT:
projects/project-sample
(the sample project in the Bytebase) - BYTEBASE_TARGETS:
instances/test-sample-instance/databases/hr_test,instances/prod-sample-instance/databases/hr_prod
(the two default databases in the sample project) - FILE_PATTERN:
migrations/*.sql
(the pattern of the migration files)
-
Go to branch policy for
main
branch, addcheck-release
as a required check. You don’t need to addrollout-release
as a required check because it will be triggered automatically when the PR is merged.
In pipelines/rollout-release.yml
, pay attention to BYTEBASE_TARGETS
in deploy-to-test
stage. You should put all the databases including both Test
and Prod
environments. NOT ONLY the Test
database.
Step 5 - Create the migration files
To create migration files to trigger release creation, the files have to match the following pattern:
- A migration file should start with digits, which is also its version. e.g.
202503131500_create_table_t1_ddl.sql
. - A migration file may end with ‘ddl’ or ‘dml’ to indicate its change type. If it doesn’t end with any of the two, its change type is DDL by default.
-
Within your forked repository, create the following migration files under
migrations
directory:- 202503131500_create_table_t1_ddl.sql
-
Commit to a new branch and create a pull request, the
check-release
workflow will be triggered. There will be a warning in the SQL review result. -
According to the SQL review result, you can do some changes to the SQL files and push to the branch. Then you should see the SQL review has passed. There are no warnings in the SQL review result.
-
When the SQL review is passed, you can merge the pull request. The
rollout-release
workflow will be triggered to create a release in Bytebase and then roll out automatically. -
You need to permit the release to be deployed to the production environment the first time.
-
If you click the test stage and expand the different sections, you can follow the links to Bytebase.
-
You may customize the workflow file to trigger deployment manually according to your needs.
Summary
Now you have learned how to database GitOps with Azure DevOps Pipeline. If you want to trigger a release creation with other git providers (e.g. GitLab, Bitbucket, GitHub Actions), you may customize the workflow file.