Thanks to visit codestin.com
Credit goes to github.com

Skip to content

bytebase/example-gitops-github-flow

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

55 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

About

This repository demonstrates how to use Bytebase and GitHub actions to do database release CI/CD with a code base following GitHub flow.

🔗 Tutorial: GitOps with GitHub Workflow

For GitHub flow, feature branches are merged into the main branch and the main branch is deployed to the, for example, "test" and "prod" environments in a deploy pipeline.

sql-review-action.yml checks the SQL migration files against the databases when pull requests are created.

release-action.yml builds the code and then for each environment migrate the databases and deploy the code. Using environments with protection rules, it can deploy to the test environment automatically and push to the prod environment after approval.

Use bytebase/bytebase-action

The README of bytebase/bytebase-action can be found at README.

How to configure sql-review-action.yml

Copy sql-review-action.yml to your repository.

Modify the environment variables to match your setup.

    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # set GITHUB_TOKEN because the 'Check release' step needs it to comment the pull request with check results.
      BYTEBASE_URL: https://demo.bytebase.com
      BYTEBASE_SERVICE_ACCOUNT: [email protected]
      BYTEBASE_SERVICE_ACCOUNT_SECRET: ${{secrets.BYTEBASE_SERVICE_ACCOUNT_SECRET}}
      BYTEBASE_PROJECT: "projects/project-sample"
      BYTEBASE_TARGETS: "instances/test-sample-instance/databases/hr_test" # the database targets to check against.
      FILE_PATTERN: "migrations-semver/*.sql" # the glob pattern matching the migration files.

Set your service account password in the repository secrets setting with the name BYTEBASE_SERVICE_ACCOUNT_SECRET.

Important

The migration filename SHOULD comply to the naming scheme described in bytebase-action --file-pattern flag section.

How to configure release-action.yml

Copy release-action.yml to your repository.

Modify the environment variables to match your setup. You need to edit both deploy-to-test and deploy-to-prod jobs.

    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      BYTEBASE_URL: https://demo.bytebase.com
      BYTEBASE_SERVICE_ACCOUNT: [email protected]
      BYTEBASE_SERVICE_ACCOUNT_SECRET: ${{secrets.BYTEBASE_SERVICE_ACCOUNT_SECRET}}
      BYTEBASE_PROJECT: "projects/project-sample"
      # The Bytebase rollout pipeline will deploy to 'test' and 'prod' environments.
      # 'deploy_to_test' job rollouts the 'test' stage and 'deploy_to_prod' job rollouts the 'prod' stage.
      BYTEBASE_TARGETS: "instances/test-sample-instance/databases/hr_test,instances/prod-sample-instance/databases/hr_prod"
      BYTEBASE_TARGET_STAGE: environments/test
      FILE_PATTERN: "migrations-semver/*.sql"

In the repository environments setting, create two environments: "test" and "prod". In the "prod" environment setting, configure "Deployment protection rules", check "Required reviewers" and add reviewers in order to rollout the "prod" environment after approval.

Set your service account password in the repository secrets setting with the name BYTEBASE_SERVICE_ACCOUNT_SECRET.

Important

The migration filename SHOULD comply to the naming scheme described in bytebase-action --file-pattern flag section.

How to configure chatops-migrate.yml

Copy chatops-migrate.yml to your repository.

This workflow enables ChatOps-style deployments through PR comments. Team members can trigger migrations by commenting /migrate <environment> on pull requests.

Configuration

  1. Define environments in the workflow: Edit the config.yaml generation step to define your environments and their database targets.

Note

The top-level keys (e.g., test, prod) are used as GitHub Actions job environments, so they must match the environment names configured in your repository settings.

      - name: Write command config
        run: |
          cat <<EOF > ${{ runner.temp }}/config.yaml
          test:
            stage: environments/test
            targets:
              - instances/test-sample-instance/databases/hr_test
          prod:
            stage: environments/prod
            targets:
              - instances/prod-sample-instance/databases/hr_prod
          EOF
  • stage: The environment of the databases (e.g., environments/test)
  • targets: List of databases (e.g., instances/test-sample-instance/databases/hr_test)
  1. Set environment variables: Configure these variables in the workflow:
env:
  BYTEBASE_URL: https://demo.bytebase.com
  BYTEBASE_SERVICE_ACCOUNT: [email protected]
  BYTEBASE_SERVICE_ACCOUNT_SECRET: ${{ secrets.BYTEBASE_SERVICE_ACCOUNT_SECRET }}
  BYTEBASE_PROJECT: "projects/hr"
  FILE_PATTERN: "migrations-semver/*.sql"
  1. Configure GitHub environments: Create environments matching your config (e.g., "test", "prod") in repository settings. Add deployment protection rules for production environments.

  2. Add service account secret: Set BYTEBASE_SERVICE_ACCOUNT_SECRET in repository secrets.

Usage

  • Comment /migrate <environment> on a PR to trigger deployment to that environment
  • Example: /migrate prod deploys to production (requires environment approval if configured)

About

Database CI/CD and schema migration with GitHub flow using Bytebase and GitHub actions

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 4

  •  
  •  
  •  
  •