エンジニアリングチームが大きくなり、日々のデータベース変更操作が増えていくと、変更プロセスを集中的に調整・統制する仕組みが必要になります。手っ取り早い方法は、社内にすでにある ITSM (IT サービス管理) や単純なチケットシステムに乗ることです。中でも Jira はおそらく最もよく選ばれる選択肢でしょう。
典型的な Jira のセットアップ
-
カスタム Jira ワークフローを定義する。 データベース変更プロセス専用のステータスセットを定義します。例:
Created、Reviewing、Pending Rollout、Completed。 -
カスタム Jira イシュータイプと、
SQL、Database、Rollout Timeなどのカスタムフィールドを定義する。 -
レビュアー (通常は DBA またはプロジェクトオーナー) とリクエスター (通常は開発者) のロールをそれぞれ作成する。
データベース変更ワークフロー
同様のワークフローは、クエリアクセスの申請やデータエクスポートなど、他のデータベースタスクにも適用できます。
-
開発者がデータベース変更を申請する Jira イシューを作成する。
SQL、Database情報を埋める。イシューのステータスはCreated。 -
設定されたワークフローに従って DBA がイシューにアサインされる。DBA は SQL をレビューし、イシューにコメントを残す。ステータスは
Reviewing。 -
何度かのやりとりの後、DBA はイシューを承認し、ステータスを
Pending Rolloutに変更する。 -
DBA は Jira チケットから SQL をコピーし、お気に入りの SQL クライアントに貼り付けて実行する。
-
DBA はステータスを
Completedに更新する。
改善の余地
Jira を使うことで、チームはデータベース変更をレビューし調整する集中的な場所を持てるようになりました。とはいえ、改善の余地はまだ十分にあります。
レビューとロールアウトのプロセスが分断されている
-
DBA は SQL を別の場所に手作業で貼り付けて実行する必要があります。間違った SQL を貼り付けたり、間違ったデータベースに対して実行してしまったり (いわゆる「本番に向けてしまった」事故) する可能性があります。
-
変更履歴が不明瞭です。なぜ、いつ、どのようにデータベース変更が行われたのかを追跡するのが難しくなります。
データベース領域向けのカスタマイズが不足している
データベース変更はかなり複雑になり得ます。
-
異なる環境間で変更を伝播させる
-
同じスキーマを持つ複数データベースに一括変更する (マルチテナント・マルチリージョン構成では典型的)
-
自動 SQL リントチェックを強制する
-
ロールバックを効率化する
汎用のチケッティングシステムにデータベース特化のタスクをこなさせるのは骨が折れます。
なぜ Bytebase か
多くのお客様が、以上のような課題を理由に Jira から Bytebase へ移ってきます。Jira と同様に Bytebase にも Project、Issue という概念があります。加えて Bytebase は Database Instance、Database、Environment といったデータベース領域固有の概念をファーストクラスで定義しています。Bytebase はデータベース変更の計画・レビュー・デプロイを統合した体験を提供します。
Issue detail interface