Git and CI/CD

Choose the right Git branching strategy and CI/CD patterns for your team’s workflow.

Git Branching Strategies

GitHub Flow (Simple)

main ─────────────○─────────────○─────→
        ╲        ╱             ╱
         feature-branch    hotfix-branch

Workflow:

Create feature branch from main
Develop migration
Open PR, SQL review runs
Merge to main
CI creates release and deploys

Best for: Continuous deployment, small teams

GitLab Flow (Environment Branches)

main ─────────○─────────○─────────────→
               ╲         ╲
                staging   production

Workflow:

Merge to main → deploys to dev
Merge main to staging → deploys to staging
Merge staging to production → deploys to prod

Best for: Progressive environment promotion

Git Flow (Release Branches)

main ──────────────────○────────○────→ (production)
         ╲            ╱        ╱
          develop ─○─○─────○───         (dev)
                   ╲        ╱
                    feature-branch

Workflow:

Develop in feature branches
Merge to develop → deploys to dev/staging
Create release branch → final testing
Merge to main → deploys to production

Best for: Scheduled releases, large teams

CI/CD Integration Patterns

Pattern 1: Automated Review + Manual Deploy

# .github/workflows/sql-review.yml
on: pull_request

jobs:
  sql-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SQL Review
        run: |
          # Call Bytebase API to check release
          curl -X POST "$BB_URL/v1/projects/my-project/releases:check"

# .github/workflows/deploy.yml
on:
  workflow_dispatch:  # Manual trigger

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Create Release
        run: |
          # Create release via API

Best for: Production environments requiring manual control

Pattern 2: Fully Automated Pipeline

# .github/workflows/database-cicd.yml
on:
  push:
    branches: [main]
    paths: ['migrations/**']

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Create Release
        id: release
        run: |
          RELEASE=$(curl -X POST "$BB_URL/v1/projects/my-project/releases" ...)
          echo "release=$RELEASE" >> $GITHUB_OUTPUT

      - name: Create Plan
        id: plan
        run: |
          PLAN=$(curl -X POST "$BB_URL/v1/projects/my-project/plans" \
            -d '{"release": "${{ steps.release.outputs.release }}"}')
          echo "plan=$PLAN" >> $GITHUB_OUTPUT

      - name: Create Rollout
        run: |
          curl -X POST "$BB_URL/v1/projects/my-project/rollouts" \
            -d '{"plan": "${{ steps.plan.outputs.plan }}"}'

Best for: Dev/staging environments, high-frequency deployments

GitOps Tutorials

Complete CI/CD setup examples for GitHub, GitLab, Azure DevOps, and Bitbucket

Testing Strategies

Test in Non-Production First

Always follow environment progression:

Local Dev → CI Testing → Dev Environment → Staging → Production

Never skip environments for production changes.

Use Sampling for Large Fleets

For database groups with 100+ databases:

{
  "project": {
    "ci_sampling_size": 20
  }
}

During SQL review, validates on 20 random databases for faster feedback.

Maintain Test Data

Create sample datasets that mirror production:

-- test-data/seed.sql
-- Realistic test data for development
INSERT INTO users (username, email) VALUES
    ('alice', 'alice@example.com'),
    ('bob', 'bob@example.com');

INSERT INTO orders (user_id, total) VALUES
    (1, 99.99),
    (2, 149.99);

Test migrations against this data locally before committing.

Schema Compatibility Testing

Before deploying schema changes:

Deploy new schema to staging
Test old application version against new schema
Verify backward compatibility
Deploy application update
Remove deprecated columns/tables later

This enables zero-downtime deployments.

Local Testing Workflow

Before committing:

# 1. Apply migration locally
psql $LOCAL_DB -f migrations/new_migration.sql

# 2. Test with sample data
psql $LOCAL_DB -f test-data/seed.sql

# 3. Run application tests
npm test

# 4. Verify rollback (if applicable)
psql $LOCAL_DB -f migrations/rollback.sql

CI Testing Checklist

Automated tests should verify:

✅ SQL syntax is valid
✅ Migration applies successfully
✅ No SQL review rule violations
✅ Schema changes don’t break existing queries
✅ Performance impact is acceptable
✅ Rollback script works (if provided)

Database CI/CD

UI-Driven Workflow

GitOps Workflow

Appendix

Git Branching Strategies

GitHub Flow (Simple)

GitLab Flow (Environment Branches)

Git Flow (Release Branches)

CI/CD Integration Patterns

Pattern 1: Automated Review + Manual Deploy

Pattern 2: Fully Automated Pipeline

GitOps Tutorials

Testing Strategies

Test in Non-Production First

Use Sampling for Large Fleets

Maintain Test Data

Schema Compatibility Testing

Local Testing Workflow

CI Testing Checklist

Next Steps

SQL Review and Security

GitOps Tutorials

Database CI/CD

UI-Driven Workflow

GitOps Workflow

Appendix

​Git Branching Strategies

​GitHub Flow (Simple)

​GitLab Flow (Environment Branches)

​Git Flow (Release Branches)

​CI/CD Integration Patterns

​Pattern 1: Automated Review + Manual Deploy

​Pattern 2: Fully Automated Pipeline

GitOps Tutorials

​Testing Strategies

​Test in Non-Production First

​Use Sampling for Large Fleets

​Maintain Test Data

​Schema Compatibility Testing

​Local Testing Workflow

​CI Testing Checklist

​Next Steps

SQL Review and Security

GitOps Tutorials

Git Branching Strategies

GitHub Flow (Simple)

GitLab Flow (Environment Branches)

Git Flow (Release Branches)

CI/CD Integration Patterns

Pattern 1: Automated Review + Manual Deploy

Pattern 2: Fully Automated Pipeline

Testing Strategies

Test in Non-Production First

Use Sampling for Large Fleets

Maintain Test Data

Schema Compatibility Testing

Local Testing Workflow

CI Testing Checklist

Next Steps