CI/CD パイプライン方式は、データベース変更をアプリケーションコードと同じパイプライン上に乗せます。マイグレーションスクリプトは Git に置く。CI でリンティングとレビューを走らせる。デプロイはステージを通って進める。
本記事ではこのアプローチをエンドツーエンドで追います — パイプラインが何をゲートするのか、何を外に残すのか、適合するツールは何か。
パイプライン主導のアプローチは、データベース自動化の 6 段階におけるレベル 3 に位置します。
パイプラインが行うこと
あらゆる変更が同じ道を通ります。検証する。プロモートする。承認する。記録する。
検証
SQL レビューがプルリクエスト上で走ります。構文エラー、欠けたインデックス、安全でない操作、命名ルール違反 — すべてマージ前に捕捉します。ルールセットは環境横断で適用され、厳しさが環境ごとに変わります。本番ではフルセットを、dev ではサブセットを実行します。
プロモート
マイグレーションが dev に適用されます。次に staging。そして本番。各ステージで、同じスクリプトが段階的により本番に近いデータに対して走ります。失敗するとチェーンが止まります。
承認
ステージ間に承認ゲートが置かれます。ルーチン変更は dev と staging に自動でプロモートされます。本番向けの DDL は人を待ちます。承認者は SQL、検証結果、ロールアウト計画を 1 つのレコードで確認します。
記録
適用されたあらゆるマイグレーションが、バージョン、環境、実行者、タイムスタンプとともにログに残ります。環境間のスキーマは自動的に比較されます。ドリフト — パイプラインの外で行われた変更 — はアラートを引き起こします。
パイプラインを通る 1 つの変更
ある開発者が、1200 万行の users テーブルに NULL 許可カラムを追加します。
プルリクエスト。 マイグレーションがコミットされます。
-- V042__add_user_email_verified_column.sql
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT NULL;
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_users_email_verified
ON users(email_verified) WHERE email_verified = FALSE;SQL レビューが 2 点を指摘します。インデックス作成は本番規模で約 10 分かかる。部分インデックスの WHERE 句はインデックスを小さく保つ反面、カーディナリティを歪める。
dev。 マイグレーションは 1 万行のデータベースに 2 秒で適用されます。インテグレーションテストは通過。
staging。 本番に近いボリューム。マイグレーションは 8 分かかります。インデックス構築中、レプリケーション遅延が 45 秒まで跳ねます。QA がアプリケーションが新しい NULL 許可カラムを正しく扱えることを検証。
本番。 DBA は staging が綺麗に完了したのを見て承認します。デプロイは低トラフィック帯で実行。マイグレーションは 11 分かかります。データベース側の確認が取れた後にアプリケーションがデプロイされます。
パイプラインはすべてのステップを記録します。各環境がそれぞれの監査証跡を持ちます。マイグレーションスクリプトは 4 環境すべてで同じ 1 本です。
インデックス戦略はエンジンによって異なります。PostgreSQL は CREATE INDEX CONCURRENTLY を使います。MySQL は ALGORITHM=INPLACE を使い、エンジンがテーブルをコピーしてしまうケースでは gh-ost や pt-online-schema-change にフォールバックします。戦略を選ぶのは開発者。その選択がレビューを通ることを強制するのがパイプラインです。
どこで止まるのか
パイプラインがゲートするのは 1 つのクラスの作業です — 計画的でバージョン管理されたスキーマ変更。その他のクラスはいくつか外側に残ります。
- アドホック操作。 緊急のホットフィックス、単発のデータパッチ、インシデント中の
ANALYZE— どれもプルリクエストとして始まりません。 - クレデンシャル管理。 データベースのクレデンシャルは PAM、あるいは開発者のラップトップに置かれます。パイプラインはサービス ID として動作し、開発者として動くわけではありません。
- 読み取りパスの活動。 クエリ、エクスポート、アドホックな調査はマイグレーションログには現れません。
- マージの先のポリシー。 命名ルールやロック粒度のチェックは PR レビュー時に走ります。マージされた後、実行時に再チェックするものはありません。
パイプラインは計画的な変更をゲートします。データベースに触れるすべてをゲートするわけではありません。
データベース変更を守るでは、同じギャップをセキュリティスタック (踏み台、ITSM、PAM) の側から扱っています。
適合するツール
パイプラインのコア機構をカバーするオープンソースツールは 3 つあります。
- Liquibase、Flyway — CLI ファーストのマイグレーションランナー。チェンジログからマイグレーションを適用し、適用済みを追跡し、任意の CI と統合できます。Java ベース。
- Bytebase — Web GUI と GitOps。SQL レビュー、承認、ステージプロモーションを組み込み済み。単一の Go バイナリ。
| 機能 | Liquibase | Flyway | Bytebase |
|---|---|---|---|
| チェンジログからマイグレーション適用 | ✓ | ✓ | ✓ |
| SQL レビュー組み込み | Pro プラン | Teams プラン | 無料、200 以上のルール |
| ステージプロモーション + 承認 | 手動 | 手動 | 組み込み |
| スキーマドリフト検知 | — | Enterprise | 組み込み |
| Web UI | — | — | ✓ |
CLI ファーストのチームは Liquibase か Flyway を使い、パイプラインを自分でオーケストレーションします。パイプラインが組み上がった状態で欲しいチームは Bytebase を使います。
どこに着地するか
CI/CD パイプラインはデータベース自動化の 6 段階におけるレベル 3 に位置します。計画的スキーマ変更について、開発者から DBA への手作業の引き継ぎを取り除きます。
すべてのチームにフルパイプラインが必要というわけではありません。読み取り専用の分析データベース、使い捨ての開発環境、小規模チーム (10 データベース未満、開発者 5 人未満) は、バージョン管理 + CLI ランナーで運用できます。チームとデータベース数が増えてきたところでパイプラインを追加します。
ギャップを埋めるのはレベル 4 のプラットフォームです — アドホック操作、クレデンシャル、読み取りパスの活動、マージ後のポリシー。パイプライン主導アプローチはチームが構築できる最強の L3 です。L4 ではありません。