概観
SQL 変更スクリプトのレビューはかつて DBA の仕事であり、しかもタイミングが遅すぎました。開発者は変更がリリースされる直前に DBA にマイグレーションを渡し、レビューや修正要求の時間はほとんど残りませんでした。問題はレビューではなく本番で表面化していたのです。
解決策は SQL レビューをシフトレフトすること — 他のすべての変更がすでにレビューされている、プルリクエストの中に移すことです。Bytebase はまさにそれを行います。各プルリクエストで自動 SQL レビューを実行し、危険なマイグレーションをデプロイ段階ではなく PR 段階で検出します。
SQL レビューがプルリクエストにシフトレフトし、Develop と Release の間に入る
SQL レビューの位置づけ
Bytebase はデータベース変更を 3 段階の GitOps パイプラインとしてモデル化します。
Develop → Review (プルリクエスト) → Release (Bytebase)
開発者はフィーチャーブランチでマイグレーションファイルを書き、プルリクエストを開きます。SQL レビューはそのプルリクエスト上の CI ステップとして実行されます — これが Review ステージです。レビューが通り PR がマージされると、Bytebase はリリースを作成し、Release ステージで環境をまたいで変更をロールアウトします。SQL レビューは、変更を書くこととそれを出荷することの間のゲートです。
仕組み
1 つの GitHub Action — bytebase/sql-review-action — が、マイグレーションファイルに触れるプルリクエストで実行されます。これは Bytebase サーバーに接続し、サーバーはレビューに必要な 2 つのものを保持します。
- SQL レビューポリシー — 命名、アンチパターン、インデックス、危険なステートメントをカバーする 200 以上の設定可能なルール。
- データベース接続 — レビューをスキーマ対応にします。Bytebase はライブのスキーマを読み取れるため、テキストのみのリンティングでは捉えられない問題 — インデックスの欠落、後方互換性のない変更、実際のテーブルに照らして初めて意味を持つ問題 — を検出します。
# .github/workflows/sql-review.yml
name: SQL Review
on:
pull_request:
paths:
- 'migrations/**'
jobs:
sql-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: SQL Review
uses: bytebase/sql-review-action@v1
with:
bytebase-url: ${{ secrets.BYTEBASE_URL }}
bytebase-token: ${{ secrets.BYTEBASE_SERVICE_ACCOUNT_TOKEN }}
file-pattern: 'migrations/**/*.sql'セットアップ
-
SQL レビューポリシーを設定する。 Bytebase で基準を定義し、各ルールの重大度を設定します — マージをブロックする
ERROR、フラグを立てるWARNING、またはオフ。SQL レビューポリシーのドキュメントを参照してください。 -
Bytebase をリポジトリに接続する。 GitOps インストールガイドに従って、Bytebase を VCS に接続します。
-
サービスアカウントを作成する。 個人用トークンではなく、
GitOps Service Agentロールを持つ専用アカウントを使い、そのシークレットをリポジトリの Actions シークレットに保存します。 -
ワークフローを追加する。 上記の
sql-review.ymlワークフローを.github/workflows/に置き、file-patternをマイグレーションディレクトリに向けます。
詳細な手順は SQL Review CI のドキュメントと GitHub Actions チュートリアルにあります。
何がレビューされるか
すべてのプルリクエストで、Action は次を検証します。
- SQL 構文 — 不正な、または方言互換性のないステートメント。
- ポリシールール — SQL レビューポリシーの 200 以上の設定可能なルール。
- 命名規則 — テーブル・カラム・インデックスの命名の準拠。
- リスク評価 —
DROP TABLEやWHEREのないUPDATEといった危険な操作。 - スキーマ互換性 — ライブのスキーマに照らした後方互換性のない変更。
プルリクエストでのレビューフィードバック
レビューボットは結果をプルリクエスト上に直接、サマリーとして、また変更ファイル上にインラインで投稿します。
- ✅ 合格 — マイグレーションがすべてのポリシー要件を満たしています。
- ⚠️ 警告 — ベストプラクティス違反。デフォルトでは非ブロッキング。
- ❌ エラー — ポリシー違反。デフォルトではマージをブロック。
- 📊 リスク評価 — 変更の影響度の評価。
- 📝 説明 — ルールが失敗した理由と、修正の提案。
開発者は指摘された問題を修正して再度プッシュし、Action はレビューが通るまで再実行されます。通って初めて変更はマージできます。
GitHub を超えて
同じ bytebase-action は、CI が動く場所ならどこでも実行されます。仕組みは同じ — Bytebase サーバーに接続し、マイグレーションファイルをチェックし、リクエストにコメントする — GitLab CI、Azure DevOps、Bitbucket Pipelines にわたって、どのチームも同じレビュー基準を得られます。プラットフォームごとのすぐ使える設定は SQL Review CI のドキュメントを参照してください。
レビューからデプロイへ
プルリクエストで悪い SQL を捉えることは価値の半分です。もう半分は、同じパイプラインがその変更をデプロイすることです。レビューが通り PR がマージされると、Bytebase はリリースを作成し、必要な場所に承認ゲートを設けながら環境をまたいでロールアウトします — 2 つ目のツールは不要で、開発者と DBA が同じレビュー基準を適用します。SQL レビューは、完全なデータベース GitOps ワークフローの 1 つのステージです。