Database GitOps with Azure DevOps Pipeline

• Database GitOps with GitHub Actions
• Database GitOps with Azure DevOps Pipeline (this one)
• Database GitOps with GitLab CI
• Database GitOps with Bitbucket Pipelines

• Submit SQL migrations through Azure DevOps
• Automatically run SQL reviews on pull requests
• Auto-create and deploy Bytebase releases when merging to main

​

Prerequisites

• A Bytebase instance (Bytebase Cloud or self-hosted)
• For self-hosted version, you need Docker to run Bytebase

​

Automatic Rollout across environments

​

Step 1 - Set up Bytebase

​

Step 2 - Create Service Account

1. Log in as Workspace Admin, and go to IAM & Admin > Users & Groups. Click + Add User, fill in with api-sample, and assign the Workspace Member and GitOps Service Agent roles, which are sufficient for this tutorial, then click Confirm.
2. Find the newly created service account and Copy Service Key. We will use this token to authenticate the API calls.

​

Step 3 - Configure SQL Review in Bytebase

1. Go to CI/CD > SQL Review, click Create SQL Review.
2. Select the Sample Template and click Next.
3. Select Prod environment as the attached resources and click Confirm. Now the SQL review is enabled for the Prod environment.

​

Step 4 - Copy from the Example Repository and Configure Variables

1. 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 the main branch.
2. Go into pipelines/sql-review.yml and pipelines/rollout-release.yml. In the env section, replace the variable values with your own and commit the changes.
   • BYTEBASE_URL: Your Bytebase instance URL (e.g., https://bytebase.your-company.com or your Bytebase Cloud 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)
3. Go to branch policy for main branch, add check-release as a required check. You don’t need to add rollout-release as a required check because it will be triggered automatically when the PR is merged.

​

Step 5 - Create the migration files

• 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.

1. Within your forked repository, create the following migration files under migrations directory:
   • 202503131500_create_table_t1_ddl.sql
   Copy

   Ask AI

   CREATE TABLE t1 (
    id SERIAL PRIMARY KEY,
    name TEXT
   );
   

2. 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.
3. 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.
   Copy

   Ask AI

    CREATE TABLE t1 (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
   );
   

   
4. 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 deploy automatically.
5. You need to permit the release to be deployed to the production environment the first time.
6. If you click the test stage and expand the different sections, you can follow the links to Bytebase.
7. You may customize the workflow file to trigger deployment manually according to your needs.

​

Summary