If you haven't set up Bytebase for your team, please refer to my previous article: How to start using Bytebase for team database collaboration

2 Roles - Project Owner & Developer

Now we have a project prepared in Bytebase, and we have

• Adela as Project Owner (usually the DBA to review SQLs)
• Ray and Lucy as Project Developer

Those are two roles for a project in Bytebase. https://www.bytebase.com/docs/concepts/roles-and-permissions#project-roles

Developer Creates the SQL issue

OK, Adela already set up the project; now it's Ray's turn to change the database schema. We switch the account to Ray.

As Ray is a developer for Project Employee, she can view the project.

We skip the following setting for now. This article is for UI workflow only; I'll show you GitOps workflow in another one.

Ray has made a new feature -- to give every employee a choice to have a nickname.

All the code is ready; now, it's time to change the schema. Click project name Employee to go to the specific project page. Click Alter Schema.

This dialog popups up; she should choose the second one to make the pipeline work.

Ray is not familiar with SQL queries; she searches around the internet and finds this.

w3schools.com/sql/sql_alter.asp

She fills in the title, SQL, applies the SQL to Prod, and assigns this issue to Adela for Prod review (As we configure in the previous article, only Prod requires manual review).

The basic check is running automatically.

The SQL runs successfully against the Test environment, which doesn't require manual approval, and then waits for approval for the Prod environment.

DBA Reviews the SQL issue

Now let's switch back to Adela to review.

After Adela clicks Resolve Issue, the issue is Done.

If Adela goes back to the home page, she can see the closed issue.

Or go into the project page, the overview tab.

The migration history.