コードブランチ間で共有されるデータベーススキーマを処理する効率的な方法は何ですか？

複数のブランチを持つプロジェクトで作業します。各ブランチは最終的にメインブランチにマージされ、新しい機能を開発するために本質的に分離されます。

MS SQL Serverであるデータベースには共有スキーマがありますが、各ブランチは進行に応じてスキーマに変更を加えます。

私の主な質問は、メインブランチから派生ブランチまでのスキーマの共有に対処する良い方法です。メインブランチに加えられた変更は、派生の新しい変更を踏むことなく、派生ブランチに簡単にマージされます。ブランチ？

バージョン管理とデータベースで詳しく説明した次の方法論を使用しました：

• メタデータでバージョン番号を維持します（データベースの拡張プロパティを使用します）
• スキーマの変更は、現在のバージョンから次のバージョンに更新するスクリプトとしてコーディングされます
• アプリケーションには、バージョン0（初期展開）から現在のバージョンにアップグレードするためのすべてのスクリプトが付属しています
• すべての変更はスクリプトを介して行われます。辞書やルックアップテーブルエントリなどの「システム」データの変更を含みます。
• デプロイされると、アプリケーションはディスク上のスキーマバージョンを確認し、すべてのアップグレード手順を実行してスキーマを現在の必要なバージョンにします

「これは、単にオブジェクト定義スクリプトをソース管理下に置くこととどう違うのか」という意見をよく耳にします。アプリの新しいバージョンをデプロイするときに、新しいデータベースを作成するだけではないため、違いは非常に大きくなります。ほとんどの場合、アプリは既存のデータを含む既存のデータベースをアップグレードする必要があります。これは重大な違いです。アップグレード手順では、アップグレード中に既存のデータの整合性と一貫性を確保する必要があります。一部の操作はコードでは簡単です（テーブルオブジェクト定義スクリプトに既定値のnull不可列を追加します）が、実際の展開では実際に非常に苦痛です（テーブルには15億行あり、列の追加は実行されません） 「シンプル」な方法で行われた場合のログスペース）。

これは分岐でどのように機能しますか：

• ブランチが作成されると、現在のスキーマバージョン、たとえばバージョン1.6がスナップされます
• チームがブランチで作業を開始すると、新しいバージョン1.7が追加され、1.6から1.7へのアップグレードステップのコーディングが開始されます。
• ブランチで変更が行われると、アップグレード手順が変更されます。v 1.6から1.7にアップグレードするスクリプトを常に実行しますが、それらのスクリプトが正確に行うことは、ブランチでの通常のコードの反復とチェックインの影響を受けます
• ブランチは開発を終了し、逆統合の準備をします（ベースラインにマージされます）
  • ベースラインからブランチへの新しい前方統合を行います。統合によってスキーマバージョンに変更が加えられない場合、すべてが正常である場合、ブランチは現状のまま逆統合できます。バージョン1.7が新しいベースラインバージョンになります。
  • 興味深いのは、その間に別のブランチがベースに逆統合され、ベーススキーマバージョンがたとえば1.7に変更されたときです。この場合、ブランチはデプロイメントターゲットスキーマバージョンを1.8に上げ、以前は1.6から1.7であったアップグレード手順を確認して、新しい環境で1.7から1.8にアップグレードする方法を確認する必要があります。論理スキーマの競合を解決する必要があり、スクリプトに変更が必要な場合があります。テストを行う必要があります。完了すると、ブランチはベースに逆統合できます。製品のデプロイ済みターゲットバージョンは1.8になりました。
  • スキーマバージョン1.6で分岐した別のブランチが逆統合する場合、スキーマバージョンを1.9に上げ、1.8から1.9へのアップグレードスクリプトをテストする必要があります。その後、ベースに統合できます。

ツール、マジックスキーマdiffスクリプト、ウィザード、および右ボタンクリック生成スクリプトが含まれていないことに注意してください。これは、ソース（スクリプト）に基づいた100％開発者主導のプロセスです。多くの人がこのプロセス全体を精巧にしていますが、うまくいきます。実際、SQL Serverユーザーとして、SQL Serverの日常の使用でこのプロセスの結果を既に活用しています。SQLServer自体は非常によく似たデータベースアップグレードプロセスを使用しており、おそらくご想像のとおり、製品開発プロセスは広範囲に使用されています分岐の問題とあなたが言及した問題は、解決しなければならない非常に現実的な問題です。

ところで、分岐/統合が実際にどのように行われるかは、ソース管理製品によって異なります。私は、PERFORCE 統合操作モードでよく知られている用語を使用しています。

私の答えはレムスほど長くはないかもしれませんが、これは本当に良い解決策であることがわかりました。まだプロダクションでセットアップしていないので、YMMV *。

リキベース

基本的には、XMLファイル内の新しい要素としてデータベースのスキーマを変更するXMLファイルです。例えば：

<createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>

それは完全に肉付けされた構文を持っているので、あなたはあなたのデータベースに対してほとんど何でもすることができます。

また、バージョン管理するデータベースをLiquibaseインストールで指定します。次に、付属のJava実行可能ファイル（jarファイル）で.xmlを「実行」します。これにより、XMLで指定された変更がデータベースに本質的に再作成されます。

実際のキッカーは、このXMLファイルをコードと同じバージョン付きフォルダーに保存することです。私の場合、それはGitでした。プロジェクトフォルダー（/.gitと同じレベル）にこのXMLファイルがあり、ブランチを切り替えるたびにXMLファイルがそのブランチバージョンに変更され、.jarファイルを実行すると、データベースにそのブランチが反映されます。

*注意：JavaをSQL Serverに接続するのに問題があったため、実装を完了していません。いくつかのjdbcドライバーなどが必要で、私は気分がよくありませんでした。したがって、走行距離は異なる場合があります。

Red Gateでは、SQL CompareとSQL Source Controlの両方を活用するデータベースバージョン管理ソリューションを近日中にリリースします。これは、移行スクリプトアップグレードアプローチを使用し、ソース管理リビジョンに対応するバージョン拡張プロパティをデータベースにスタンプします。

12月中旬にリリースしたいと考えています。現在利用可能なリリース候補があります。詳細については、次をご覧ください。

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/migration

今後数か月以内にこのソリューションを構築していきたいと考えていますので、ご意見をお聞かせください。

スクリプトを生成し、それらのスクリプトをソース管理下に置いてスキーマの変更を処理する場合、他のコードをマージする場合と同様に変更を処理できるはずです。自動マージを選択するか、より多くの手動介入を選択できます。

私は、データベーススキーマを変更する必要があるライブWebサイトといくつかの開発ブランチで作業している同様の状況にあります。

gitでうまく使用できるチェックアウト後とマージ後のフックを書くことで解決しました。私はすべての移行をSQL​​ファイルの形式で別のディレクトリに保存し、変更されたPHPコードと一緒にコミットします。実行するたびに

git checkout

または

git merge

gitは適切なアップマイグレーションとダウンマイグレーションを自動的に呼び出します。Githubでの私の実装をご覧ください。