Integrating GitLab with Bytebase to Version Control Database Schema Similar to Code
Tags: gitlab, database, versioncontrol
Published: 2022-05-11 09:36:39

We have gone through UI workflow in [Bytebase](https://bytebase.com/) in the previous article: 
[Using Bytebase to facilitate Database Collaboration Between Developer and DBA](https://devrel.bytebase.com/using-bytebase-to-facilitate-database-collaboration-between-developer-and-dba)

Based on the concept of [Database-as-Code](https://www.bytebase.com/blog/database-as-code), Bytebase provides you with another advanced Version Control workflow (GitOps).

This article will guide you through the version control workflow between GitLab and Bytebase. Ensure you have a working GitLab installed with an admin role and a working Bytebase with an owner role.

We'll still use our sample database Employee in
[Import sample database into AWS RDS MySQL using Shell & Workbench](https://devrel.bytebase.com/import-sample-database-into-aws-rds-mysql-using-shell-and-workbench)

## GitLab
- Create a project called EmployeeBytebase in GitLab.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652258651965/2sR9PA9fk.png align="left")


![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652258805981/lmn4623gB.png align="left")

- Clone it to local.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652258837071/Q2srF1SRO.png align="left")

It's now almost empty; we'll add more files along the way.

## Bytebase
To start the workflow, we need first do some configuration.

### Workspace level

If you haven't used bytebase before, you need to do Enviroment and Instance configuration first, check [this article](https://devrel.bytebase.com/how-to-start-using-bytebase-for-team-database-collaboration) to prepare.

#### [Step 1 Add Git Provider](https://www.bytebase.com/docs/use-bytebase/vcs-integration/add-git-provider)
- Add a Git provider under Settings->Version Control, you need to have [owner role](https://www.bytebase.com/docs/concepts/roles-and-permissions) to do this. 
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652259091132/5u04RKakC.png align="left")

- Follow the three steps. You need to have GitLab Admin role to do configuration there and complete the whole process.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652259197797/eptQSf5VP.png align="left")

### Project level
#### [Step 2 Enable Version Control Workflow in Project](https://www.bytebase.com/docs/use-bytebase/vcs-integration/enable-version-control-workflow)

- Create a project called EmployeeGitLab.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652259658220/nSqIvb3Ak.png align="left")

- Prepare two databases in our [configured instances Test and Prod](https://devrel.bytebase.com/how-to-start-using-bytebase-for-team-database-collaboration), it's similar to [what we did before](https://devrel.bytebase.com/import-sample-database-into-aws-rds-mysql-using-shell-and-workbench), but we can adjust the database name to distinguish.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652259699724/65dqLUmUT.png align="left")

- Transfer in these two databases.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652259934905/y6yfLR2jn.png align="left")

- Within this new project, under version control,  choose GitOps workflow.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652259956380/X1JpTiohK.png align="left")

- Choose the GitLab project we just created.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652259982793/NsfRt2taW.png align="left")

- Make sure the branch is correct. The default base directory is bytebase; we'll keep it.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260003043/C9mqhbfp4.png align="left")


#### [Step 3 Name and Organize Schema Files](https://www.bytebase.com/docs/use-bytebase/vcs-integration/name-and-organize-schema-files)

We know that two types of schema files are needed following the instructions.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260125445/5Nt0GbNlh.png align="left")
- Our first script should be a baseline migration script and follow this format.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260157738/k88YTcAHG.png align="left")


#### [Step 4 Create the First Baseline Migration](https://www.bytebase.com/docs/use-bytebase/vcs-integration/create-the-first-baseline-migration)

- We do a mysqldump for our current two databases and rename them. For this article, we follow the recommended structure in our documentation.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260223804/Hu0aXoHLG.png align="left")

- This is ours.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260259780/v2OPM6FnH.png align="left")

- We commit and push.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260287272/HiE4I0sJm.png align="left")

- Then we come back to our project home page, ah! In Recent activities, there is something wrong. Yes, our file names don't match the template.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260315284/5sEzwHRCe.png align="left")

- Let's fix this by adding one more '_', commit, and push again.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260328976/T-XwH1QxR.png align="left")

- If we view the files in GitLab, we see Bytebase created a new LATEST SQL automatically.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260362034/TGCZ_Xhhx.png align="left")

- It's explained in the documentation.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260378955/BQSV-mn8X.png align="left")

- After we change the file names and push them to GitLab. Bytebase finally receives the trigger and creates issues automatically.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260405721/5k7eJpgQO.png align="left")

- Clicking issue/107 brings us to the issue detail page - Test environment.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260428872/myiImdLne.png align="left")

- Clicking issue/106 brings us to the Prod environment; the status is Waiting Approval. This is because we set the Prod environment to require manual approval.


![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260455600/zrjm1mkyL.png align="left")

- Because we're the project owner, we have the permission to approve.
![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260463717/eM3jKuHxy.png align="left")


![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260507916/FRBMfF1Qz.png align="left")

- If we go to the project Migration History tab, we can view all the migration history.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260535123/QgSP05Yob.png align="left")


#### Step 5  Create the First Normal Migration
- After setting the baseline, now it's the real schema change. Our first task is to add nickname column to employee. It's similar to Step 4, except the file names should use migrate instead of baseline. Let's first try on Test.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260621165/oSOzITo9W.png align="left")

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260628759/kDrPt12ds.png align="left")

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260635707/TTpbAnAaCr.png align="left")

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260646968/ScWgNYYVn.png align="left")

- Repeat the process on Prod and approve manually.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260669491/HaEajErHY.png align="left")

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260676198/oxBbD8vH9.png align="left")

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1652260685779/ZivNWtLre.png align="left")