【86】コードだけではなくデータをコントロールせよ
バージョン管理システムと継続的インテグレーションは、アプリケーションのビルド、デプロイプロセスを管理するためのツールとして非常に優れています。しかし、ビルド、デプロイでは、ソースコードとともに、スキーマやデータ変更も大きな位置を占めているので、これらにも同じような管理システムが欲しいところです。ビルド、デプロイプロセスにデータ更新のために手順を細々と指定するリストが含まれているようなら、注意が必要です。このリストは成功するかどうかひやひやしながら実行するもので、次のような内容になっています。
- 実行しなければならないスクリプトを順に並べたリストを作成する。
- データベース担当にスクリプトをメールする。
- データベース担当がスクリプトをクローンジョブが実行する位置にコピーする。
- すべてのスクリプトの実行が成功していることを祈りながら、スクリプトの実行ログをチェックする。再実行したら何が起きるかわからないので祈るのです。
- 整合性確認スクリプトを実行し、データのスポットチェックを行う。
- アプリケーションのリグレッションテストを行い、エラーを起こすところをチェックする。
- 失われているデータを挿入し、エラーを訂正するスクリプトを書く。
- 繰り返し。
少し大げさなところが含まれているかもしれませんが、それほどかけ離れたものにはなっていないはずです。多くのプロジェクトは、データベースのマイグレーションを成功させるために、こんな感じの曲芸的な作業フローを必要とするのです。どういうわけか、マイグレーション計画のデータに関する部分は、アーキテクチャー設計の段階では見落とされてしまいます。そのため、あと知恵としてこの部分のために危なっかしい手作業がバタバタと組みたてられるのです。
この複雑に織り合わさった作業には、ほころびが生じそうな場所がいくつも含まれています。さらに悪いことに、スキーマやデータ変更が原因となっているバグは、ナイトリービルドレポートに含まれる単体テストではキャッチできない場合があります。マイグレーションが済んだ直後あたりに醜い頭をがばっと持ち上げることが多いのです。データベース関連で障害が起きたとき、手作業で復旧するのは非常に大変ですし、修復結果の整合性確認は厳しくなりがちです。これだけ問題がはっきりしている作業をすると、データベースを把握できている以前の状態に復元できる、完全に自動化されたビルドプロセスが是非必要だと思うようになるでしょう。データベースをドロップして、アプリケーションの特定のビルドと完全に互換性のある状態に復元できなければ、コード変更を素早く取り消せない時におきるのと同じような問題にさらされることになります。
ビルドの時間的空間的一体性がデータベースの変更によって揺らぐことがあってはなりません。アプリケーションは、データベースともども、1 つの単位、ユニットとしてビルドできるものでなければならないのです。早い段階で自動ビルド、テストプロセスのシームレスな一部として、データ・スキーマ管理を組み込み、アンドゥ機能を用意しましょう。この作業には大きな見返りがあります。うまくすれば、深夜の大トラブルの後の苦しくてストレスのたまる何時間もの障害復旧作業を省略できます。そうでなくても、データアクセスレイヤーのリファクタリングに自信をもって臨めるようになります。