Education

How to Setup Database CI/CD with GitHub, Part 2: GitHub.com Database GitOps

Ningjing
4 min read

This is a series of articles about Database CI/CD with GitHub


In the last article How to Setup Database CI/CD with GitHub, Part 1: Enable SQL Review with GitHub Actions, you learned how to enable SQL review GitHub actions and trigger it automatically when there is a pull request in your repo.

This second part will guide you through configuring GitHub.com database GitOps with Bytebase. After following these steps, whenever SQL files carrying the database change are merged into your GitHub repository, the database change pipeline will be automatically triggered. Thus your Git repository always keeps the source of truth of your database schema, and your live database schema always evolves whenever SQL files change in the Git repository.

divided-workflow

Step 1 - Run Bytebase in Docker with the URL generated by ngrok

In this tutorial, you’ll run Bytebase locally using Docker.

ngrok is a reverse proxy tunnel, and in our case, we need it for a public network address in order to receive webhooks from GitHub.com. ngrok we used here is for demonstration purposes. For production use, we recommend using Caddy.

ngrok-reverse-proxy

  1. Login to ngrok Dashboard and follow its Getting Started steps to install and configure.
  2. Run ngrok http 8080 and obtain the public URL:

ngrok

  1. Run Bytebase in Docker with the following command.
docker run --init \
--name bytebase-github \
--restart always \
--publish 8080:8080 \
--volume ~/.bytebase/data:/var/opt/bytebase \
bytebase/bytebase:1.3.0 \
--data /var/opt/bytebase \
--external-url https://03f1-103-102-7-52.ngrok.io \
--port 8080 \
--frontend-port 80
  1. Bytebase is running successfully in Docker, and you can visit it via https://03f1-103-102-7-52.ngrok.io

docker-running

Step 2 - Add GitHub.com as a Git provider in Bytebase

  1. Open Bytebase, go to Settings > Version Control, choose GitHub.com, and click Next.

bb-vc

  1. Copy the Authorization callback URL.

fill-id-secret

  1. Open GitHub, and go to Settings > Developer Settings > OAuth Apps. Click New OAuth App. github-oauth

  2. Scroll down on the new OAuth App page, paste the Authorization callback URL, then click Update Application.

auth-callback

  1. On the same page, you can also find Client ID and Client secrets.

client-id-secrets

  1. Switch back to the Bytebase console, fill Client ID and Client secrets in the form as Application ID and Secret.

fill-id-secret

  1. Click Next. You will be redirected to the confirmation page. Click Confirm and add, and the Git provider is successfully added.

confirm-and-add

Step 3 - Use GitOps workflow to apply Schema Change

  1. Go to Instances to add two instances for Test and Prod environments respectively. In our case, we use two AWS RDS MySQL instances with the same employee data set.

add-two-instances

  1. Create a Project, click Transfer in DB and choose two identical databases belonging to Test and Prod environments respectively.

transfer-in-db

transfer-in-db-2

  1. Go to Version Control under the project, and choose GitOps workflow.

project-vc

project-vc-2

  1. Create a repository named database-gitops-sample in GitHub. Select this repository in Bytebase. Keep the default setting unless you know what you are doing. Pay attention to Branch field to make sure it’s the one you want to watch.

project-repo

  1. Click Finish, and you can see that Version Control is enabled.

vc-enable

  1. Create a bytebase folder and prod, test folders under it in your GitHub repository.

bytebase-folder

  1. Create a sql script following the name convention {{ENV_NAME}}/{{DB_NAME}}__{{VERSION}}__{{TYPE}}__{{DESCRIPTION}}.sql, and here we create employeeGitHub__202208171630__ddl__add_nickname.sql under the test directory.
  • test corresponds to {{ENV_NAME}}
  • employeeGitHub corresponds to {{DB_NAME}}
  • 202208171630 corresponds to {{VERSION}}
  • ddl corresponds to {{TYPE}}
  • add_nickname corresponds to {{DESCRIPTION}}

create-migration-sql

  1. Commit and push this script.
  2. Go back to the Bytebase Console, and you can see there is a new issue created.

new-issue

  1. Visit this issue, and click Approve. The SQL will execute against the employeeGitHub database in the Test environment, and it shows Done. You may also configure the environment to skip this manual approval step.

issue-waiting issue-done

  1. Go to database employeeGitHub > table employee, and the nickname column is added there.

table-employee

  1. Switch to your code editor, and you will find there is an auto-generated file .employeeGitHub__LATEST.sql, which is the latest schema written back by Bytebase. latest

  2. Copy the migration script file employeeGitHub__202208171630__ddl__add_nickname.sql and paste it into prod directory, and repeat the process. The schema change will execute on Prod environment.

Congratulations! Now you have 1) Enabled SQL Review GitHub Actions for your GitHub repo, 2) Tried out database GitOps with GitHub. In the upcoming final part, we’ll put these two together, and thus, implementing a complete database CI/CD workflow.

Ready to try out this workflow yourself? Join our Discord channel and share your experience.