|
2 | 2 | title: Overview |
3 | 3 | --- |
4 | 4 |
|
5 | | -import TaskRunOrder from '/snippets/tutorials/task-run-order.mdx'; |
6 | | - |
7 | 5 | <Card title="Tutorial: First Schema Change in 5 Minutes" icon="graduation-cap" href="/tutorials/first-schema-change" horizontal /> |
8 | 6 |
|
9 | | -For a typical change workflow, a developer first submits the SQL statement for DBA to review. After review is approved, the SQL statement will then be applied to the corresponding database. For a single change, this step would normally be repeated for each environment (e.g. integration, staging, prod). |
10 | | - |
11 | | -There are 2 typical workflows employed by the team to deal with database schema changes (DDL) and data changes (DML). [UI workflow](#ui-workflow) and [GitOps workflow (GitOps)](#gitops-workflow). |
12 | | - |
13 | | -## UI workflow |
14 | | - |
15 | | -Classic SQL Review workflow where the developer submits a SQL review ticket directly from Bytebase and waits for the assigned DBA or peer developer to review. Bytebase applies the SQL change after review approved. |
16 | | - |
17 | | - |
18 | | - |
19 | | -## GitOps Workflow |
20 | | - |
21 | | -Aka `Database-as-Code`. Database migration scripts are stored in a git repository. To make schema changes, a developer would create a migration script and submit for review in the corresponding VCS such as GitLab. After the script is approved and merged into the configured branch, Bytebase will automatically kicks off the task to apply the new schema change. |
22 | | - |
23 | | - |
24 | | - |
25 | | -## Core Concepts |
26 | | - |
27 | | -### Issue |
28 | | - |
29 | | -`Issue` adds the collaboration such as approval, comment, and notification to the database change process. An issue is often created via the UI workflow. On the other hand, an issue may not be created via the GitOps workflow since the GitOps workflow may only need the [rollout](/change-database/change-workflow/#rollout) without further human intervention. |
30 | | - |
31 | | -### Release |
32 | | - |
33 | | -A `release` is a deployable unit that encapsulates a set of SQL statements. |
34 | | - |
35 | | -### Rollout |
| 7 | +## Database CI/CD |
36 | 8 |
|
37 | | -To deploy the changes, Bytebase creates a multi-stage rollout pipeline from you project deployment config setting. The changes are pushed to databases stage by stage. |
| 9 | +Bytebase Database CI/CD provides a complete platform for managing database changes throughout the development lifecycle. By eliminating direct database access and enforcing structured processes, it ensures every change is safe, reviewed, and auditable. |
38 | 10 |
|
39 | | -### Revision |
| 11 | +## The Database CI/CD Lifecycle |
40 | 12 |
|
41 | | -`Revision` records the versioned changes applied to a database. You can get a database from version A to version B by replaying the revisions between A and B. When applying a [release](/change-database/change-workflow/#release) to a database, the changes with a version present in the revision are skipped so that the same changes are not applied twice. |
| 13 | +Every database change in Bytebase follows a structured lifecycle, regardless of which workflow you choose: |
42 | 14 |
|
43 | | -### Changelog |
| 15 | +### 1. **Plan Change** |
| 16 | +Define what needs to change—whether it's a schema migration (DDL) or data modification (DML). Changes can target: |
| 17 | +- A single database |
| 18 | +- Multiple selected databases |
| 19 | +- A Database Group (databases sharing the same schema) |
44 | 20 |
|
45 | | -`Changelog` records all changes applied to a database, whether they are versioned or not, successfully applied or not. This includes change database [issues](/change-database/change-workflow/#issue) created on Bytebase UI or [rollout](/change-database/change-workflow/#rollout) via Bytebase APIs, but NOT changes from Bytebase SQL Editor or other external database tools. Changelog offers you insights into the database schema evolution. |
| 21 | +### 2. **Automatic SQL Review** |
| 22 | +Built-in SQL advisor validates every change before execution: |
| 23 | +- **Syntax validation**: Catch SQL errors before deployment |
| 24 | +- **Schema rules**: Naming conventions, data types, and structure standards |
| 25 | +- **Performance checks**: Missing indexes, inefficient queries, table scans |
| 26 | +- **Security policies**: Prevent unsafe operations and data exposure |
| 27 | +- **Backward compatibility**: Ensure changes won't break existing applications |
| 28 | +- **Best practices**: Enforce organizational and industry standards |
46 | 29 |
|
47 | | -## Review Center |
| 30 | +### 3. **Approval Process** |
| 31 | +Flexible approval mechanisms based on your workflow choice: |
| 32 | +- **UI-Driven**: Built-in multi-level approval within Bytebase |
| 33 | +- **GitOps**: |
| 34 | + - Leverage pull request reviews in GitHub/GitLab/Bitbucket |
| 35 | + - Integrate with external systems like ServiceNow, Jira, or custom approval workflows |
| 36 | +- Risk-based routing: Automatic approval for low-risk dev changes, mandatory reviews for production |
48 | 37 |
|
49 | | -You can create a review-only ticket. Go to a particular project and click **Review Center**. |
| 38 | +### 4. **Multi-Environment Rollout Pipeline** |
| 39 | +Changes progress through your environments in a controlled pipeline: |
| 40 | +- **Stage-by-stage promotion**: Dev → Test → Staging → Production |
| 41 | +- **Configurable deployment paths**: Define custom environment chains |
| 42 | +- **Database Groups per stage**: Different database sets for each environment |
| 43 | +- **Gated progression**: Manual or automatic promotion between stages |
| 44 | +- **Environment-specific policies**: Different review rules per stage |
50 | 45 |
|
51 | | - |
| 46 | +Within each stage, deployments execute with precision: |
| 47 | +- **Parallel execution**: Deploy across Database Groups simultaneously |
| 48 | +- **Sequential ordering**: Respect dependencies between databases |
| 49 | +- **Real-time monitoring**: Track progress and view execution logs |
| 50 | +- **Automatic retry**: Handle transient failures gracefully |
52 | 51 |
|
53 | | -If there are review errors, then you won't be able to create the rollout. |
| 52 | +### 5. **Rollback Capabilities** |
| 53 | +Instant recovery when things go wrong: |
| 54 | +- **DML Instant Rollback**: One-click recovery for UPDATE/DELETE operations |
| 55 | +- **Schema Rollback**: Generate reverse migration scripts for DDL changes |
| 56 | +- Automatic backup before risky DML operations |
54 | 57 |
|
55 | | - |
| 58 | +### 6. **Schema Monitoring** |
| 59 | +Detect schema drift when changes occur outside the CI/CD pipeline, ensuring your databases remain in their expected state. |
56 | 60 |
|
57 | | - |
| 61 | +## Batch Changes with Database Groups |
58 | 62 |
|
59 | | -## Rollout Time |
| 63 | +Deploy changes at scale using Database Groups—logical collections of databases that share the same schema: |
60 | 64 |
|
61 | | -<PricingPlanBlock feature_name='SCHEDULE_CHANGE' /> |
| 65 | +- **Multi-tenant SaaS**: Update all tenant databases simultaneously |
| 66 | +- **Geographic distribution**: Roll out to regional databases in controlled waves |
| 67 | +- **Environment management**: Group databases by dev/staging/prod for systematic promotion |
62 | 68 |
|
63 | | -If you want to deploy changes during non-business hours, you can set a rollout time. |
| 69 | +Database Groups enable you to manage 10 or 10,000 databases with the same effort. |
64 | 70 |
|
65 | | - |
| 71 | +## Choose Your Workflow |
66 | 72 |
|
67 | | -## Rollout Process |
| 73 | +Bytebase offers two workflows to integrate with your existing processes: |
68 | 74 |
|
69 | | -### Execution Order |
| 75 | +<CardGroup cols={2}> |
| 76 | + <Card title="UI-Driven Workflow" icon="mouse-pointer"> |
| 77 | + Visual, self-contained workflow managed entirely through Bytebase console |
| 78 | + </Card> |
| 79 | + <Card title="GitOps Workflow" icon="git-branch"> |
| 80 | + Code-first approach integrated with your Git provider (GitHub, GitLab, Bitbucket) and CI/CD pipeline |
| 81 | + </Card> |
| 82 | +</CardGroup> |
70 | 83 |
|
71 | | -Database rollout is organized into stages. Each stage can contain multiple tasks. Each task contains |
72 | | -one or more SQL statements to be executed. |
| 84 | +## Which Workflow Should You Choose? |
73 | 85 |
|
74 | | - |
| 86 | +### Choose UI-Driven Workflow If: |
75 | 87 |
|
76 | | -Tasks run in the following order: |
| 88 | +✅ **You prefer visual interfaces** — Point-and-click change management with immediate feedback |
77 | 89 |
|
78 | | -<TaskRunOrder /> |
| 90 | +✅ **You need centralized control** — All database changes managed in one dedicated platform |
79 | 91 |
|
80 | | -### Task Detail |
| 92 | +✅ **Multiple teams involved** — DBAs, security, and compliance teams need visibility and approval rights |
81 | 93 |
|
82 | | -You can check the running/completed task details. |
| 94 | +✅ **No existing CI/CD for databases** — Get started quickly without setting up additional infrastructure |
83 | 95 |
|
84 | | - |
| 96 | +✅ **Ad-hoc changes are common** — Hotfixes and emergency changes need quick turnaround |
85 | 97 |
|
86 | | -The logs shows how Bytebase runs SQL statements. |
| 98 | +**Best for:** Teams establishing database DevOps practices, organizations with dedicated DBAs, enterprises requiring multi-level approvals |
87 | 99 |
|
88 | | - |
| 100 | +[Learn more about UI-Driven Workflow →](/change-database/ui-workflow) |
89 | 101 |
|
90 | | -<Tip> |
| 102 | +### Choose GitOps Workflow If: |
91 | 103 |
|
92 | | -If you initiate the change from `Edit Schema` (DDL), Bytebase will take the schema snapshot before and after the change. |
| 104 | +✅ **Database schema = Application code** — Migration scripts live alongside your application |
93 | 105 |
|
94 | | -</Tip> |
| 106 | +✅ **Existing CI/CD pipelines** — Database changes follow your established deployment process |
95 | 107 |
|
96 | | -The sessions view shows all active sessions (PostgreSQL only). |
| 108 | +✅ **Developer-centric culture** — Engineers own the full stack including database |
97 | 109 |
|
98 | | - |
| 110 | +✅ **Git is your source of truth** — All changes tracked through version control |
99 | 111 |
|
100 | | -## Migration Types |
| 112 | +✅ **Automation first** — Minimize manual intervention in deployments |
101 | 113 |
|
102 | | -Bytebase records the migration history with the migration type information. |
| 114 | +**Best for:** DevOps teams, microservices architectures, organizations practicing Infrastructure-as-Code |
103 | 115 |
|
104 | | -### Schema Migration |
| 116 | +[Learn more about GitOps Workflow →](/change-database/gitops-workflow) |
105 | 117 |
|
106 | | -Schema migration is the migration type for DDL statements. |
| 118 | +## Can I Use Both? |
107 | 119 |
|
108 | | -### Data Migration |
| 120 | +**Yes!** Many teams use both workflows: |
| 121 | +- GitOps for routine application deployments |
| 122 | +- UI-Driven for complex migrations, hotfixes, or sensitive production changes |
| 123 | +- Different workflows for different teams or projects |
109 | 124 |
|
110 | | -Data migration is the migration type for DML statements. |
| 125 | +Both workflows share the same underlying CI/CD lifecycle, ensuring consistency regardless of how changes are initiated. |
111 | 126 |
|
0 commit comments