データベース変更にコードレビューだけでは不十分な理由

ある開発者がプルリクエストを開きました。変更内容はシンプルです。ユーザー設定を追跡するための新しいカラムを追加するだけ。同僚がコードをレビューし、承認し、変更がマージされました。20分後、本番データベースでロックが蓄積し始めます。ミリ秒で完了していたクエリが、数秒かかるようになりました。デプロイはロールバックされましたが、被害はすでに発生していました。

このシナリオは、データベースの変更をアプリケーションコードの変更と同じように扱うチームで発生します。コードレビューはロジックエラーやスタイルの問題をキャッチしますが、1000万行のテーブルに対してマイグレーションを実行したときに何が起こるかをキャッチすることはほとんどありません。安全なマイグレーションと危険なマイグレーションの違いは、差分だけでは必ずしも見えません。

データベースパイプラインが特別である理由

アプリケーションパイプラインは、コードがコンパイルされ、テストがパスし、アーティファクトがデプロイ可能であることを検証します。データベースパイプラインには異なる役割があります。スキーマ変更が既存のデータを破損しないか、テーブルを長時間ロックしないか、デプロイ後にクエリパフォーマンスを低下させないかを検証します。

1つのマイグレーションで、データ損失が発生したり、長時間のロックが発生したり、マイグレーションが完了するまでアプリケーションが使用できなくなったりする可能性があります。これらのリスクは理論上のものではありません。本番データベースを管理するすべてのチームには、マイグレーションが失敗した話があります。

データベース変更のためのパイプラインは、これらの問題が本番環境に到達する前にキャッチするために存在します。コードレビューを置き換えるものではありません。コードレビューだけでは提供できない検証レイヤーを追加します。

コミット後に何が起こるか

開発者がマイグレーションファイルをフィーチャーブランチにコミットすると、データベースパイプラインが自動的にチェックを開始します。これらのチェックは、人間のレビュー担当者が変更を確認する前に行われます。

最初のチェックは構文検証です。パイプラインはマイグレーションファイルを読み取り、すべてのSQLステートメントがエラーなく解析できることを確認します。これは些細なことのように聞こえますが、よくある時間の無駄を防ぎます。レビュー担当者が最初の行で失敗するマイグレーションを10分間見ているという状況です。

2番目のチェックは危険なパターンを検出します。テーブルの削除、カラムの削除、カラム型の変更は、データを破壊する可能性のある操作です。パイプラインはこれらの変更を高リスクとしてフラグ付けします。自動的にブロックすることはありませんが、何が危機に瀕しているかを全員が確実に認識できるようにします。

3番目のチェックはドライランです。パイプラインは、本番環境を可能な限りミラーリングしたテスト環境に対してマイグレーションを実行します。ドライランでは、マイグレーションにかかる時間、テーブルロックが発生するかどうか、インデックスの再構築が必要かどうかを測定します。また、マイグレーション後もテストデータが一貫していることを検証します。

これらの結果はすべて、プルリクエストに添付される単一のレポートに収集されます。レビュー担当者は、構文ステータス、リスクの高い操作のリスト、ドライラン時間、および潜在的な問題に関する警告を確認できます。マイグレーションを手動で実行したり、何が起こるかを推測したりする必要はありません。

次のフローチャートは、コミットからマージまでのパイプラインステージをまとめたものです。

flowchart TD A[Developer commits migration file] --> B[Pipeline triggers] B --> C[Syntax validation] C --> D[Schema diff against production] D --> E[Performance impact analysis] E --> F[Risk assessment] F --> G{Low risk?} G -- Yes --> H[Auto-approve] H --> I[Notify reviewer] I --> J[Merge if approved] G -- No --> K[Flag for human review] K --> L[Reviewer approves or rejects] L --> J F --> M[Generate pipeline report] M --> N[Attach report to pull request]

リスクベースの承認

すべてのマイグレーションに同じレベルの精査が必要なわけではありません。デフォルト値を持つNULL可能なカラムを追加することは低リスクです。アプリケーションコードからまだ参照されている可能性のあるテーブルを削除することは高リスクです。パイプラインはこの違いを反映する必要があります。

リスクベースの承認とは、マイグレーションのリスクレベルに応じて、パイプラインが異なる承認者を必要とすることを意味します。低リスクのマイグレーションは、1人のシニア開発者からの承認で十分かもしれません。カラムを削除したり、大規模なテーブルでバックフィルを実行したりする高リスクのマイグレーションには、本番環境への影響を理解しているDBAまたはリードエンジニアからの承認が必要です。

パイプライン設定は、何が高リスクと見なされるかを定義します。一般的なパターンは次のとおりです。

  • DROP TABLE または DROP COLUMN ステートメント
  • データ型を変更する ALTER COLUMN
  • ドライランで1分以上かかるマイグレーション
  • 大規模なテーブルで排他ロックを必要とする操作

パイプラインが高リスクパターンを検出すると、指定された承認者が明示的に承認するまでマージをブロックします。これは官僚主義の問題ではありません。本番データベースを理解している人が、変更が適用される前にそれをレビューする機会を得られるようにするためです。

プルリクエストに残るレポート

パイプラインレポートはレビュー担当者のためだけのものではありません。何がチェックされ、何が見つかったかの記録です。数週間後に誰かがプルリクエストを見たときに、マイグレーションが検証されたかどうか、どのようなリスクが特定されたか、誰が承認したかを確認できます。

これはデバッグに重要です。デプロイ後にマイグレーションが問題を引き起こした場合、チームはパイプラインレポートを振り返って、ドライランで無視された警告サインがなかったかを確認できます。また、監査にも重要です。規制対象環境では、データベースの変更がポリシーに従ってレビューおよび承認されたという証拠が必要です。

パイプラインが行わないこと

パイプラインは、マイグレーションが試行しても安全であることを検証します。本番環境でマイグレーションが成功することを保証するものではありません。本番環境では、データの分布、負荷パターン、タイミングの制約が異なります。ステージングで30秒のドライランが、テーブルが大きいかサーバーがビジーであるために、本番環境では5分かかる可能性があります。

また、パイプラインはマイグレーションのタイミングを処理しません。ピークトラフィック時にマイグレーションを実行することは、どれだけテストされていてもリスクがあります。マイグレーションをいつ適用するか、ロックをどのように処理するか、問題が発生した場合にどうするかという決定は、別のプロセスに属します。

データベースパイプライン設定のための実践的なチェックリスト

チームのためにデータベースパイプラインを構築する場合、最初に正しく設定すべき事項は次のとおりです。

  • すべてのコミットでの構文検証。 壊れたSQLがレビュー担当者に届く前にキャッチします。
  • 危険なパターンの検出。 DROP、ALTER COLUMN、およびその他の高リスク操作を自動的にフラグ付けします。
  • 代表的な環境でのドライラン。 期間、ロック、データの一貫性を測定します。
  • リスクベースの承認ルール。 何が高リスクで、誰が承認できるかを定義します。
  • プルリクエストに添付されるレポート。 検証結果をレビュー担当者と将来の読者が確認できるようにします。

これらの5つの項目から始めてください。最も一般的な障害点をカバーし、チームにデータベース変更をレビューするための一貫した方法を提供します。

まとめ

データベースパイプラインは、マイグレーションを実行するためのツールではありません。すべてのデータベース変更が本番環境に触れる前に適切なレベルの精査を受けることを確実にするためのメカニズムです。構文チェックはタイプミスをキャッチします。ドライランはパフォーマンスの問題をキャッチします。リスクベースの承認は、適切な人物が適切な変更をレビューすることを確実にします。

これらの要素が連携して機能すると、チームはパイプラインが問題を早期にキャッチすることを信頼できるため、より迅速に行動できます。そして、マイグレーションが実際に失敗した場合には、その理由を理解するためのデータがあります。