Using Bytebase for Database DevOps: A Step‑by‑Step Experience

The author explores database DevOps best practices by trying Bytebase, a web‑based database change management tool, and documents the entire workflow.

1. Quick Deployment – Bytebase and two sample MySQL databases are launched using a Docker‑Compose file. The following compose file is used:

version: "3.7"

services:
  bytebase:
    image: bytebase/bytebase:1.12.0
    init: true
    container_name: bytebase
    restart: always
    ports:
      - 5678:5678
    # Uncomment the following lines to persist data
    # volumes:
    #   - ~/.bytebase/data:/var/opt/bytebase
    command: ["--data", "/var/opt/bytebase", "--port", "5678"]

  employee-prod:
    image: bytebase/sample-database:mysql-employee-small
    ports:
      - 3306:3306

  employee-test:
    image: bytebase/sample-database:mysql-employee-small
    ports:
      - 3307:3306

Running docker-compose up -d starts the Bytebase service (http://localhost:5678) and two test databases (employee‑prod and employee‑test).

2. Create Environments – In the Bytebase UI, the default environments Test and Prod are shown. Additional environments such as STG or UAT can be added; the Prod environment requires manual approval for changes.

3. Add Instances – The two MySQL instances are added to Bytebase under the appropriate environment (Test or Prod) by providing connection credentials and testing the connection.

4. Database Change

• Link Database to Project – A new project is created and the sample databases are associated with it.

• Transfer Databases – Test and Prod databases are moved into the project.

• Schema Change – An SQL statement adding a nickname column to the employee table is written, previewed, and submitted as a normal change ticket.

The ticket is reviewed, approved (for Prod), and executed automatically, performing syntax checks, connection validation, and SQL review.

5. Verify Change – Using the SQL editor in Bytebase, a query confirms that the nickname column has been added in both Test and Prod databases.

6. Resolve Ticket – After successful verification, the ticket status is set to “Resolved” in the work‑order list.