You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/docs/change-database/change-workflow.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ There are 2 typical workflows employed by the team to deal with database schema
14
14
15
15
<HintBlocktype="info">
16
16
17
-
Release is only used in [Custom GitOps workflow](/docs/vcs-integration/custom/overview/). Like a Docker image, a `release` is immutable after it is created.
17
+
Release is only used in [Custom GitOps workflow](/docs/gitops/overview/). Like a Docker image, a `release` is immutable after it is created.
@@ -20,7 +20,11 @@ While this guide uses GitHub Actions, the same principles can be applied to othe
20
20
21
21
<HintBlocktype="info">
22
22
23
-
This tutorial code repository is at [https://github.com/bytebase/bytebase-release-cicd-workflows-example](https://github.com/bytebase/bytebase-release-cicd-workflows-example)
23
+
This tutorial code repository is at [https://github.com/bytebase/release-cicd-workflows-example
@@ -39,27 +43,29 @@ This tutorial code repository is at [https://github.com/bytebase/bytebase-releas
39
43
40
44
If you have **Enterprise Plan**, you can create a **Custom Role** for the service account which require fewer permissions, and assign this role instead of DBA:
41
45
42
-
- plans.create
43
-
- plans.get
44
-
- plans.preview
45
-
- releases.check
46
-
- releases.create
47
-
- releases.get
48
-
- rollouts.create
49
-
- rollouts.get
50
-
- rollouts.list
51
-
- sheets.create
52
-
- sheets.get
53
-
- taskRuns.create
54
-
- planCheckRuns.list
55
-
- planCheckRuns.run
46
+
- plans.create
47
+
- plans.get
48
+
- plans.preview
49
+
- releases.check
50
+
- releases.create
51
+
- releases.get
52
+
- rollouts.create
53
+
- rollouts.get
54
+
- rollouts.list
55
+
- sheets.create
56
+
- sheets.get
57
+
- taskRuns.create
58
+
- planCheckRuns.list
59
+
- planCheckRuns.run
56
60
57
61
## Step 3 - Fork the Example Repository and Configure Variables
58
62
59
-
1. Go to the [bytebase-release-cicd-workflows-example](https://github.com/bytebase/bytebase-release-cicd-workflows-example) repository and fork it. There are two workflows in this repository:
63
+
1. Go to the [bytebase-release-cicd-workflows-example](https://github.com/bytebase/release-cicd-workflows-example
64
+
65
+
) repository and fork it. There are two workflows in this repository:
60
66
61
-
-`.github/workflows/bytebase-check-release.yml`: Check the release SQL syntax when there's a pull request.
62
-
-`.github/workflows/bytebase-release-cicd.yml`: Create a release in Bytebase when there's a merge to the `main` branch.
67
+
-`.github/workflows/bytebase-check-release.yml`: Check the release SQL syntax when there's a pull request.
68
+
-`.github/workflows/bytebase-release-cicd.yml`: Create a release in Bytebase when there's a merge to the `main` branch.
63
69
64
70
1. Go into `.github/workflows/bytebase-release-cicd.yml` and `.github/workflows/bytebase-check-release.yml`. In the `env` section, replace the variable values with your own and commit the changes.
65
71
@@ -75,8 +81,9 @@ If you have **Enterprise Plan**, you can create a **Custom Role** for the servic
75
81
## Step 4 - Create the Release and Roll out
76
82
77
83
To create migration files to trigger release creation, the files have to match the following pattern:
78
-
- A migration file should start with digits, which is also its version. e.g. `20250101001_create_table_ddl.sql`.
79
-
- A migration file may end with 'ddl' or 'dml' to indicate its change type. If it doesn't end with any of the two, its change type is DDL by default.
84
+
85
+
- A migration file should start with digits, which is also its version. e.g. `20250101001_create_table_ddl.sql`.
86
+
- A migration file may end with 'ddl' or 'dml' to indicate its change type. If it doesn't end with any of the two, its change type is DDL by default.
80
87
81
88
1. Within your forked repository, create the following migration files under `migrations` directory:
82
89
@@ -99,118 +106,117 @@ To create migration files to trigger release creation, the files have to match t
99
106
100
107
1. Commit to a new branch and create a pull request, the `bytebase-check-release` workflow will be triggered.
1. When the SQL review is passed, you can merge the pull request. The `bytebase-release-cicd` workflow will be triggered to create a **release** in Bytebase and then roll out automatically. Go to **Actions** tab, you can see the workflow run and pass.
1. Check out your repo and log in to Bytebase to gain the access token.
139
146
140
-
```yaml
141
-
- name: Checkout
142
-
uses: actions/checkout@v4
143
-
- name: Login to Bytebase
144
-
id: login
145
-
uses: bytebase/login-action@main
146
-
with:
147
-
bytebase-url: ${{ env.BYTEBASE_URL }}
148
-
service-key: ${{ env.BYTEBASE_SERVICE_ACCOUNT }}
149
-
service-secret: ${{ secrets.BYTEBASE_PASSWORD }}
150
-
151
-
```
147
+
```yaml
148
+
- name: Checkout
149
+
uses: actions/checkout@v4
150
+
- name: Login to Bytebase
151
+
id: login
152
+
uses: bytebase/login-action@main
153
+
with:
154
+
bytebase-url: ${{ env.BYTEBASE_URL }}
155
+
service-key: ${{ env.BYTEBASE_SERVICE_ACCOUNT }}
156
+
service-secret: ${{ secrets.BYTEBASE_PASSWORD }}
157
+
```
152
158
153
159
1. The **create_release** step scans the files matching the pattern and collects them into a bundle. Note that these files should also obey the naming scheme mentioned above.
154
160
155
-
The bundle is first sent to check. If the check passes, a release is then created on Bytebase.
156
-
157
-
```yaml
158
-
- name: Create release
159
-
id: create_release
160
-
uses: bytebase/create-release-action@v1
161
-
with:
162
-
url: ${{ env.BYTEBASE_URL }}
163
-
token: ${{ steps.login.outputs.token }}
164
-
project: ${{ env.BYTEBASE_PROJECT }}
165
-
file-pattern: ${{ env.FILE_PATTERN }}
166
-
check-release: 'FAIL_ON_ERROR'
167
-
targets: ${{ env.BYTEBASE_TARGETS }}
168
-
validate-only: 'false'
169
-
```
161
+
The bundle is first sent to check. If the check passes, a release is then created on Bytebase.
# 'FAIL_ON_ERROR' will fail the action if plan checks report errors.
184
-
# Use 'SKIP' to skip the check.
185
-
# Use 'FAIL_ON_WARNING' to fail if plan checks report warning.
186
-
check-plan: 'FAIL_ON_ERROR'
187
-
validate-only: 'false'
188
-
189
-
- name: Rollout
190
-
id: rollout
191
-
uses: bytebase/rollout-action@v1
192
-
with:
193
-
url: ${{ env.BYTEBASE_URL }}
194
-
token: ${{ steps.login.outputs.token }}
195
-
plan: ${{ steps.create_plan.outputs.plan }}
196
-
# set target-stage to exit after the stage completes
197
-
# target-stage: 'Test Stage'
198
-
```
199
-
200
-
These are the steps:
201
-
202
-
- create the plan from the release
203
-
-check the plan
204
-
- create the rollout
205
-
- wait for the rollout to complete
206
-
207
-
In the **create_plan** step, you can setcheck-plan to FAIL_ON_ERROR to fail the action if plan checks report errors. Use SKIP to skip plan checks. Use FAIL_ON_WARNING to fail the action if plan checks report warning.
208
-
209
-
The rollout pipeline stages are created on demand in the **wait_rollout** step. You can use target-stage to early exit the step. When the target stage completes, it exits. If target-stage is not provided or not found, wait_rollout will wait until all stages complete. The target-stage is a stage title in the deployment config in the project setting.
# 'FAIL_ON_ERROR' will fail the action if plan checks report errors.
190
+
# Use 'SKIP' to skip the check.
191
+
# Use 'FAIL_ON_WARNING' to fail if plan checks report warning.
192
+
check-plan: 'FAIL_ON_ERROR'
193
+
validate-only: 'false'
194
+
195
+
- name: Rollout
196
+
id: rollout
197
+
uses: bytebase/rollout-action@v1
198
+
with:
199
+
url: ${{ env.BYTEBASE_URL }}
200
+
token: ${{ steps.login.outputs.token }}
201
+
plan: ${{ steps.create_plan.outputs.plan }}
202
+
# set target-stage to exit after the stage completes
203
+
# target-stage: 'Test Stage'
204
+
```
205
+
206
+
These are the steps:
207
+
208
+
- create the plan from the release
209
+
- check the plan
210
+
- create the rollout
211
+
- wait for the rollout to complete
212
+
213
+
In the **create_plan** step, you can set check-plan to FAIL_ON_ERROR to fail the action if plan checks report errors. Use SKIP to skip plan checks. Use FAIL_ON_WARNING to fail the action if plan checks report warning.
214
+
215
+
The rollout pipeline stages are created on demand in the **wait_rollout** step. You can use target-stage to early exit the step. When the target stage completes, it exits. If target-stage is not provided or not found, wait_rollout will wait until all stages complete. The target-stage is a stage title in the deployment config in the project setting.
210
216
211
217
1. You can also apply releases to databases on Bytebase UI. If you wish, you can set up an action to just create the release and manually roll out later.
Copy file name to clipboardExpand all lines: content/docs/vcs-integration/overview.md
+13-6Lines changed: 13 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,13 +4,20 @@ title: GitOps
4
4
5
5
Bytebase offers a database-as-code workflow, enabling you to manage database changes directly through your version control system (VCS).
6
6
7
-
Bytebase provides two GitOps workflows:
7
+
Bytebase GitOps workflow is built upon the [Bytebase API](/docs/api/overview). It provides the ultimate flexibility to customize the GitOps workflow to integrate with your CI/CD pipeline.
8
8
9
-
-[Simple GitOps](/docs/vcs-integration/simple/overview): Opinionated and restricted for the simple use case.
10
-
-[Custom GitOps](/docs/vcs-integration/custom/overview): Fully customizable via the Bytebase API.
- Tutorial: [Database Release CI/CD with GitHub Action](/docs/tutorials/github-release-cicd-workflow/)
13
14
14
-
If you manage database changes for multiple teams or have any branching strategy beyond the most basic, you will be likely need the [Custom GitOps](/docs/vcs-integration/custom/overview) workflow.
15
+
## Other VCSs
15
16
16
-
</HintBlock>
17
+
For other VCSs, we provide API integrations examples to help you get started.
18
+
19
+
- For other VCSs, we provide API integrations examples to help you get started.
20
+
21
+
## Legacy GitOps
22
+
23
+
Besides the API-driven GitOps, Bytebase also provides a [legacy GitOps workflow](/docs/vcs-integration/simple/overview/) based on the VCS webhooks. This approach is only kept for backward compatibility and we will sunset it in the future release.
0 commit comments