> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bytebase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

<Card title="Tutorial: First Schema Change in 5 Minutes" icon="graduation-cap" href="/tutorials/first-schema-change" horizontal />

## Database CI/CD

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.

## The Database CI/CD Lifecycle

Every database change in Bytebase follows a structured lifecycle, regardless of which workflow you choose:

### 1. **Plan Change**

Define what needs to change—whether it's a schema migration (DDL) or data modification (DML). Changes can target:

* A single database
* Multiple selected databases
* A Database Group (databases sharing the same schema)

### 2. **Automatic SQL Review**

Built-in SQL advisor validates every change before execution using configurable [Review Policies](/sql-review/review-policy):

* **Syntax validation**: Catch SQL errors before deployment
* **Schema rules**: Naming conventions, data types, and structure standards
* **Performance checks**: Missing indexes, inefficient queries, table scans
* **Security policies**: Prevent unsafe operations and data exposure
* **Backward compatibility**: Ensure changes won't break existing applications
* **Best practices**: Enforce organizational and industry standards

You can configure SQL Review Policies at the environment or project level to enforce your team's specific standards and requirements.

### 3. **Approval Process**

Flexible approval mechanisms based on your workflow choice:

* **UI-Driven**: Built-in multi-level approval within Bytebase
* **GitOps**:
  * Leverage pull request reviews in GitHub/GitLab/Bitbucket
  * Integrate with external systems like ServiceNow, Jira, or custom approval workflows
* Condition-based routing: Define [custom approval rules](/change-database/approval) based on conditions like environment, risk level, SQL type, and more

### 4. **Multi-Environment Rollout Pipeline**

Changes progress through your environments in a controlled pipeline:

* **Stage-by-stage promotion**: Dev → Test → Staging → Production
* **Configurable deployment paths**: Define custom environment chains
* **Database Groups per stage**: Different database sets for each environment
* **Gated progression**: Manual or automatic promotion between stages
* **Environment-specific policies**: Different review rules per stage

Within each stage, deployments execute with precision:

* **Parallel execution**: Deploy across Database Groups simultaneously
* **Sequential ordering**: Respect dependencies between databases
* **Real-time monitoring**: Track progress and view execution logs
* **Automatic retry**: Handle transient failures gracefully

### 5. **Rollback Capabilities**

Instant recovery when things go wrong:

* **DML Instant Rollback**: One-click recovery for UPDATE/DELETE operations
* **Schema Rollback**: Generate reverse migration scripts for DDL changes
* Automatic backup before risky DML operations

## Batch Changes with Database Groups

Deploy changes at scale using Database Groups—logical collections of databases that share the same schema:

* **Multi-tenant SaaS**: Update all tenant databases simultaneously
* **Geographic distribution**: Roll out to regional databases in controlled waves
* **Environment management**: Group databases by dev/staging/prod for systematic promotion

Database Groups enable you to manage 10 or 10,000 databases with the same effort.

## Choose Your Workflow

Bytebase offers two workflows to integrate with your existing processes:

<CardGroup cols={2}>
  <Card title="UI-Driven Workflow" icon="mouse-pointer">
    Visual, self-contained workflow managed entirely through Bytebase console
  </Card>

  <Card title="GitOps Workflow" icon="git-branch">
    Code-first approach integrated with your Git provider (GitHub, GitLab, Bitbucket) and CI/CD
    pipeline
  </Card>
</CardGroup>

## Which Workflow Should You Choose?

### Choose UI-Driven Workflow If:

* **You prefer visual interfaces** — Point-and-click change management with immediate feedback

* **You need centralized control** — All database changes managed in one dedicated platform

* **Multiple teams involved** — DBAs, security, and compliance teams need visibility and approval rights

* **No existing CI/CD for databases** — Get started quickly without setting up additional infrastructure

* **Ad-hoc changes are common** — Hotfixes and emergency changes need quick turnaround

**Best for:** Teams establishing database DevOps practices, organizations with dedicated DBAs, enterprises requiring multi-level approvals

[Learn more about UI-Driven Workflow →](/change-database/plan)

### Choose GitOps Workflow If:

* **Database schema = Application code** — Migration scripts live alongside your application

* **Existing CI/CD pipelines** — Database changes follow your established deployment process

* **Developer-centric culture** — Engineers own the full stack including database

* **Git is your source of truth** — All changes tracked through version control

* **Automation first** — Minimize manual intervention in deployments

**Best for:** DevOps teams, microservices architectures, organizations practicing Infrastructure-as-Code

[Learn more about GitOps Workflow →](/gitops/overview)

## Can I Use Both?

**Yes!** Many teams use both workflows:

* GitOps for routine application deployments
* UI-Driven for complex migrations, hotfixes, or sensitive production changes
* Different workflows for different teams or projects

Both workflows share the same underlying CI/CD lifecycle, ensuring consistency regardless of how changes are initiated.