なぜ ServiceNow か
多くのエンタープライズ組織は、IT サービス管理 (ITSM) の中核プラットフォームとして ServiceNow を採用しています。データベース変更には堅牢な承認ワークフローと包括的な監査が求められます。ServiceNow は、ビジネスに影響を与えうる重要なデータベース変更を含め、あらゆる種類の承認を管理する業界標準として確立されてきました。
従来の ServiceNow データベース変更ワークフロー
上の図は ServiceNow を使った従来のデータベース変更ワークフローを示しています。
-
リクエストの起票: 申請者が ServiceNow に変更リクエストを作成し、SQL スクリプトを TXT ファイルとして添付し、実装手順を記載します。この公式なリクエストが、提案されているデータベース変更のビジネス上の必要性と技術的詳細を取り込みます。
-
CAB のレビューと承認: 変更諮問委員会 (CAB) が、潜在的なリスク、ビジネスへの影響、スケジュールを評価します。CAB は承認の前に追加情報や修正を求めることがあります。
-
DBA と申請者のコミュニケーション: データベース管理者は、要件の確認や SQL スクリプトの調整のため、チャットやメールで申請者とやり取りします。技術的な正確性を担保するために、複数回のやり取りが発生するのが普通です。
-
SQL の実行: SQL スクリプトが確定した後、DBA がアプリケーションデータベースに対して手作業で実行します。承認された手順を厳密にたどる必要があり、細心の注意が要求されます。
-
リクエストのクローズ: DBA は ServiceNow に戻り、実装内容、実行時刻、発生した問題を記録して変更リクエストをクローズします。これで監査証跡が完結し、コンプライアンス用の記録となります。
-
実装後の検証: 図には明示されていませんが、申請者は通常、データベース変更が意図したビジネス成果に至ったかを確認し、調整が必要な場合は追加の変更リクエストにつながります。
この構造化されたアプローチはガバナンスとコンプライアンスを担保しますが、手作業の引き継ぎによって遅延を生み、技術側とビジネス側のステークホルダー間のミスコミュニケーションの余地も残します。
GitOps のやり方
GitOps モデルは、ソフトウェア開発のベストプラクティスを活用したデータベース変更管理の別解を提供します。
-
開発者起点の変更: 開発者が SQL 変更スクリプトと関連ドキュメントを含むプルリクエスト (PR) を作成します。データベース変更がアプリケーションコードと同じバージョン管理下に置かれ、履歴と文脈が残ります。
-
技術レビュー: テックリードやシニアメンバーが PR をレビューし、SQL の正しさ、パフォーマンスへの影響、データベース規約への適合を確認します。
-
PR の承認とマージ: 承認後、PR がマージされ、変更が正式にコードベースに取り込まれます。
-
自動デプロイ: マージが CI/CD パイプラインを自動でトリガーし、SQL 変更が対象データベースにデプロイされます。スキーマ検証、自動テスト、段階的デプロイなどのセーフガードを組み込めます。
このアプローチの最大の利点は完全な自動化で、手作業とヒューマンエラーを大幅に減らします。変更は手作業の介在なしに開発から本番へと進み、デリバリーが速くなり、環境間の一貫性が保たれます。さらに、すべての変更が著者と理由とともに Git 履歴に恒久的に記録されます。
ただし、GitOps アプローチには限界があります。
-
非技術ユーザーにも馴染みのあるビジネス向けインターフェイスを提供する ServiceNow と異なり、GitHub のようなバージョン管理システムは依然として開発者向けのプラットフォームです。経営層、コンプライアンス担当、運用マネージャーは GitHub アカウントを持っていないか、PR 内の SQL スクリプトを評価する技術知識がないことが多く、技術的な実装とビジネス上のガバナンスの間にギャップが生まれます。
-
監査証跡は技術的観点では包括的ですが、ServiceNow の専用の承認ワークフローと監査機能に依存する高度に規制された業界のコンプライアンス要件を満たさないことがあります。
GitHub のようなバージョン管理ベンダーは、開発者ワークフローとエンタープライズのガバナンス要件の間のこのギャップを認識しています。その回答として、GitHub は ServiceNow GitHub Actions とデプロイ保護ルールを通じて、両者の強みを組み合わせる連携機能を開発しました。
最適なデータベース変更ワークフロー
承認には ServiceNow、GitOps には GitHub を組み合わせれば、ServiceNow の堅牢なガバナンスと GitHub の開発者フレンドリーなワークフローの両方を活かせます。さらに、データベース専用 CI/CD を提供する Bytebase を組み合わせれば、この連携を強化できます。
統合されたワークフローは次のように動きます。
-
開発者が変更を起こす: 開発者がデータベース変更を含む PR を GitHub に作成します。
-
自動連携のトリガー:
a. GitHub Action またはカスタムアプリが ServiceNow の変更リクエストを作成し、ガバナンス要件を満たします。
b. 同時に Bytebase SQL レビューがトリガーされ、SQL スクリプトを解析して自動的な技術検証を提供します (サンプル PR)。
-
複数の承認ゲートを強制:
a. Bytebase SQL レビューの結果が出るまで PR のマージはブロック
b. テックリードやチームメンバーが GitHub 上で PR をレビュー・承認
c. マネージャーとステークホルダーによる CAB レビューを含む ServiceNow の承認フローを完了
-
PR マージ: すべての前提条件 (SQL レビュー、GitHub でのピア承認、ServiceNow を通じたビジネス承認) が満たされると PR がマージされます。
-
デプロイワークフローの作成: マージが Bytebase GitHub Actions をトリガーし、デプロイワークフローを作成します。
-
オプションのデプロイ保護ルール:
ベンダー固有のサポートです。GitHub はデプロイ保護ルールを提供します。Azure DevOps はパイプラインの承認とチェックを提供します。
a. テックリードによる手動ロールアウト承認といった追加のセーフガードを実装できる
b. クリティカルな環境ではデプロイ段階で再度 ServiceNow 承認を求めることができる
-
データベース変更のデプロイ: すべてのデプロイ保護ルールが満たされると、Bytebase がデータベース変更のデプロイを実行します。
この統合アプローチの利点は、各システムが得意分野を担うことです。データベース変更管理の専用ツールである Bytebase は、GitHub や ServiceNow が単体では提供できないデータベース固有のタスクで真価を発揮します。
- PR 上で SQL スクリプトを自動リンティング
- 一括変更、スキーマドリフト検知、ロールバックなど、データベースに特化した高度な変更機能
- データベース固有の変更履歴と監査証跡を維持し、スキーマとデータの全変更について専用の記録を作り、ServiceNow のより広い変更管理ドキュメンテーションを補完
この組み合わせにより、DBA とエンジニアはデータベースの進化に対する深い可視性を得つつ、ServiceNow を通じたガバナンス要件と GitHub を通じた開発者フレンドリーなワークフローを維持できます。
データベース変更自動化の先へ
データベース変更自動化のために ServiceNow と GitHub を補完するだけでなく、Bytebase はWeb ベースの SQL エディタも提供し、ジャストインタイムのデータベースアクセス制御と、クエリ時の動的データマスキングをその場で適用します。結果として、データベース変更とクエリのプロセスを 1 か所で標準化できます。