継続インテグレーションとデータベースのバージョン管理

作者 Mike Bria , 翻訳者 沼田 暁子 投稿日 2008年2月29日

セクション

設計/アーキテクチャ,

デベロップメント,

プロセス/プラクティス,

エンタープライズ・アーキテクチャ

トピック

Artifacts & Tools ,

Agile ,

Architecture ,

モデリング ,

アジャイル技術

タグ

Refactoring ,

MySQL ,

Relational Databases ,

XP ,

Releases ,

Continuous Integration ,

ORM

原則として、データベースに対する作業は必ずバージョン管理しなければならない、と強く主張した記事を投稿した後で、Scott Allen氏はデータベースのバージョン管理を最大限に利用する手法について詳しく述べている。彼は、ベースラインを作成し、スキーマのリビジョン管理に変更スクリプトを使い、データベースの（ビューやストアドプロシージャ、ファンクション、トリガ等の）プログラムされたオブジェクトを管理し、そしてブランチやマージ処理を利用する、包括的で実用的な手法を紹介している。 

Allen氏は自身の経験から学んだことを、関係データベースを使用した開発のための３つのルール(source)として記載した記事を投稿した後で、一連の投稿を始めた。そのルールとは、:

1. 開発作業には、共有データベース・サーバは決して使用してはいけない。

ソフトウェア開発におけるたくさんの便利なもののように、共有データベースはプロジェクトの落とし穴なのです。開発者達は、お互いの変更を上書きしてしまいます。私がサーバで行った変更が、あなたの開発機上のコードを動かなくしてしまうのです。リモートで開発するのは時間がかかりますし、困難なことです。ぜひとも共有データベースを使うのは避けて下さい。結局、時間の無駄になりますし、バグを生み出すことになるのですから。

2. 必ず、たった１つの信頼できるスキーマのソースを持つようにする。

誰もが正式なスキーマが何処にあるのかを知らなければなりません。そして、誰もが問題なく新規のデータベースのセットアップが出来なければなりません。コンピュータまで歩いていき、最新版をソースコントロールから入手し、ビルドし、簡単なツールを動かしてデータベースのセットアップができなければならないのです。（多くの場合、データベースが無い場合にはビルドの手順でセットアップも行うことができ、そうすると手順が１つ少なくなります。）

3. 必ずデータベースのバージョン管理を行うこと。

共通の目的は、開発からテスト、そして最終的には製品へと、管理された矛盾のない方法で変更内容を伝えることです。２つめの目的は、どの時点のデータベースでも再作成できるようにすることです。この２つ目の目的は、顧客にソフトウェアを販売している場合は、特に重要です。もし誰かが20070612.1版でビルドされたアプリケーションにバグを見つけた場合、ビルドしたときの状態のアプリケーションを－データベースも含めて－完全に再作成できなくてはなりません。

Allen氏はデータベースのバージョン管理の目的を、矛盾無く、管理され、テスト可能なように、そして再現可能な手法で、変更できることだと書いている。多くのコーチ達は、この目的を果たすことがアジャイルチームが効果をあげるために最も重要であるということに、同意するだろう。

データベースのバージョン管理の重要性をはっきりさせたところでAllen氏は、続く４つの投稿で、この目的に到達するために彼が推奨する方法を説明している。

１つめの記事では、データベースのバージョン管理の出発点であるとAllen氏が強く主張している、ベースラインのスキーマの作成(source)について説明している。最終的には、アプリケーションのデータベースをゼロから作成するのに必要な全てのSQLコマンドを含む、１つあるいは複数のスクリプトがベースラインとなる。これには、全てのオブジェクト（テーブル、制約、関数、ビュー、インデックス等）を生成するSQLコマンドや、静的なデータの入ったルックアップ・テーブルの投入コマンド、アプリケーションで必要な起動用のデータの挿入コマンドも含まれるだろう。一度ソースが作成されて間違いないことが検証されたら、「ファイルをソースコントロールにコミット」し、「スキーマのベースラインができたと考える」ようにと、Allen氏は言っている。

このベースラインを作るためにAllen氏は、（手作業でスクリプトを書くのではなく）既存のデータベースからスクリプトを生成することが出来るツールの使用をアドバイスし、生成されるスクリプトファイルの構造についての彼の好みについて述べている。

私は、テーブルや制約、初期設定、プライマリ・インデックスの生成に必要な全てのSQL文を、たった１つのファイルに書いておくのが好きです。そして、ビューやストアドプロシージャ、ファンクションはどれでも、１ファイルに１つ記述します。

もし複数ファイルを使用する場合は、バッチファイルかシェルスクリプト、アプリケーション、または自動化するようなものを書き、データベースのインストールに必要な全てのスクリプトファイルを自動で探し出して実行できるようにしてください。人の手でこの処理を行うことは、悪い方向に向かうことになります。

Allen氏は、スキーマに対して今後行われる変更を記録するテーブルを、このベースラインに含めるという提案を強調している。そして、次の３つの投稿で、こうした変更がどのように行われるべきかについて引き続き述べている。

まず、Allen氏は彼がビューやストアドプロシージャ、ファンクション以外の、スキーマオブジェクトの変更管理に用いている仕組みについて、スクリプトの変更(source)という記事で説明している。この手法では、一つ一つの変更（や一連の関連する変更）を増分の更新として、新規に作成したスクリプトファイルに書くことを指定している。これはRubyのマイグレーション(source)に良く似ている。つまり、チームでデータベースの変更が必要だとわかったら、データベースを（必要なデータ移行も含めて）要求された作りに変更する新しいスクリプトファイルを作成してテストを実施し、ソースコントロールにコミットするのである。一度公開されると、このスクリプトは二度と変更されない。

ビューやストアドプロシージャ、ファンクションを更新する(source)ための次の手法は、その他のデータベース・オブジェクトの更新方法とは正反対の、オブジェクトごとに１つの「生成コマンド」ファイルを用意し、変更が必要になった場合は、このファイルを更新するというものである。この方法を選ぶ理由について、Allen氏は次のように述べている。

問題をなるべく早く見つけたいという単純な理由です。もし誰かがスキーマの変更をコミットし、その変更によってビューで使われている列が削除された場合、－うまくいけば、テストのためにビルドが消える前に－ミスがあるということにすぐに気づくでしょう。同様に、もし誰かがビューをチェックインした際にビューに必要なスキーマの変更を公開し忘れた場合、数分後に他の誰かが席に現れて、どうしてソフトウェアが動かないのかを尋ねるでしょう。

２つめの理由は、私がかつて経験したような、めったに無いエラーを避けるためです。いくつかのデータベースには、ビューの影でスキーマを変更する際に、実行計画が失敗する傾向があります。全てを削除して最初からやり直すことで、この見つけ出すのが本当に難しいを問題を避けるのです。

Allen氏は、これまでに述べた戦略を最大限活用するために、自動化ツールを使用することの重要性を特に強調している。

開発者や試験者、あるいはインストーラがソースコードから更新し、ローカルのデータベースを更新するツールを実行するときに、魔法が起きます。ツールは、３段階の工程に分けて実行します。:

1. 有効なスキーマ変更ファイルとデータベース上のスキーマ変更ログとを比較することによって、新しいスキーマの変更を適用します。
2. データベースに作成されている全てのストアドプロシージャ、ビュー、ファンクションを削除します。
3. ビューやストアドプロシージャ、ファンクションをデータベースに戻すのに必要な全てのスクリプトを実行します。

この戦略、特に自動化ツールを用いる利点については、Allen氏は次のような例を挙げている。

スキーマ変更スクリプトはソースコントロールに入っているので、任意の時点のデータベースを再作成することができます。顧客が3.1.5.6723版のビルドのバグを報告してきたとします。そのバージョン番号のタグかラベルのついたコードを取り出してベースラインを実行し、それからそのタグに含まれているスキーマの変更を全て実行します。もうこれで同じデータベースの用意ができ、バグを再現できる可能性は高くなりました。そしてまた、矛盾無く、正しい順序で、再現可能な方法で、開発からテスト、そして最終的には製品へと変更が伝えられます。

Allen氏は、彼が説明している手法でどのようにブランチの作成とマージ(source)を行っているかについて述べ、連載を完結している。ブランチの作成やマージは、どちらも過去の初期バージョンから動いているアプリケーションならどれでも、実際にありえそうなことである。Allen氏は彼が勧めるブランチ作成の戦略としてリリースブランチ(source)の作成を提案し、自分は新しいリリースごとにデータベースのベースラインを再作成していると説明している。彼はこれを説明する例を挙げ、スキーマの変更が必要な、古いブランチを作成したリリースで障害が発見された場合のシナリオを追加している。ブランチを作成されたリリースでは、変更するための新しいスクリプトは問題なく作成される。そうなると問題なのは、今開発の本線にある現行のリリースに対して、どのようにして変更を反映するかということである。

この修正を開発の本線に取り込むには、２つの選択肢があります。実際には数え切れない数の考慮すべき選択肢があり、それはどのようにして変更を適用するかによるのですが、ここでは２つの選択肢があります。:

1. スキーマ変更スクリプトをメインストリームの01.00.0046としてマージし、この変更を組み込むように2.0のベースラインのスクリプトを修正します。
2. 新しいスキーマ変更スクリプトを02.00.0003として作成し、ブランチの46版と同じ変更内容を記述します。

１番の選択肢を選んだ場合に気をつけなければいけないのは、（私と違うやり方をするようなツールを作成していない限り）v2.0に更新されたデータベースは、46版の変更スクリプトをブランチから取り出さないということです。あなたは、利用者に強制的にこのスクリプトを手動で実行させる必要があります。さもないと、既にあるv2.0のデータベースを破壊してまわることになります。（いずれにせよ現時点では開発機とテスト機にのみにあるべきですが。）これは優れた選択肢ではありませんが、もし2.0に深く漬かっていなければ実行可能なこともあります。

２番目の選択肢は少し使いやすいものです。v1.0のデータベースでは01.00.0046から修正を取り込みます。v2.0のデータベースでは 02.00.0003から修正を取り込みます。注意が必要なのは、02.00.0003の変更スクリプトでは、もし01.00.0046のスクリプトを実行した後の場合は、変更を再適用しないように作ることです。

言い換えれば、v2.0のベースラインスクリプトからインストールされたデータベースには02.00.0003のスクリプトを適用する必要がありますが、 1.0の時からある製品のデータベースには01.00.0046のスクリプトを使用するのです。そして、最終的にデータベースがv2.0に更新されたときには、すでに適用済みの変更を行うことによって02.00.0003によるエラーを発生させたくないのです。

この件の詳細や関連する話題については、Scott Ambler氏のアジャイルデータベース開発に関する考え(source)を参照して欲しい。

原文はこちらです：http://www.infoq.com/news/2008/02/versioning_databases_series

• 次へ >