データベースと並行機能開発展開ツールは

Question

私が同時機能ブランチで開発およびなど関数dbup、DbDeploy、ReadyRoll、

などのデータベース展開ツールのために働く特定の戦略/大会を探しています

は、我々は、複数の機能を実行します同時にプロジェクトを開発するためのブランチ。

各ブランチは、専用の開発、QAおよび展開タコを経由して展開されているUAT環境を持っています。

私は、各ブランチで適用された変更を処理するツールを使用して、Octopusによる自動データベース配置に取り組もうとしています。

データベースの変更は、すべてのブランチ（リリースブランチを含む）で発生します。

私がこれまで見てきたほとんどのツールは、VCSにチェックインされ、ツールによって展開されるスクリプトのシーケンスベースのアプローチを使用しています。ほとんどのツールは、ファイル名の昇順でスクリプトを適用し、1,2,3などのアプローチに従うように指定しています。

これは1つのブランチで正常に動作します。

フィーチャーAが1でフィーチャーBが1の場合は、両方ともメインブランチにマージされます。私は今、＃1のスクリプトを2つ持っています。それをさらに楽しくする - 私たちの生産への道は、もう1つの時間を併合することです。それは1を持つかもしれません。だから今では3つの＃1のスクリプトがあります。

バックワードマージの問題もあります。プロジェクトが完了したら、リリースブランチをメインにマージしてから再びフィーチャーブランチにマージし、次のプロジェクトのためにリセットします。このシナリオでは、ターゲットフィーチャーブランチデータベースに適用されていない2つの追加の＃1スクリプトがあります。

この最初の解決策は、ソースにチェックインされたsqlファイル名の先頭の接頭辞としてジュリアン日付を使用することです。私は、作業項目と共にファイルにブランチ名を適用することも考えていました。したがって、SQLファイルは{XXXXX_Y_ZZZZZZ.sql}の規則に従います。ここで、xxxxxはジュリアンの日付、yはブランチ、zzzzzzはTFSの作業項目です。

この問題の具体的な解決策を探しています。他の誰かがこれを解決しましたか？あなたは何をした？欠点は何ですか？どのツールを使用しましたか？

Answer 1

Readyrollのsemantic versioningを調べましたか？

私たちは今すぐReadyrollを実装していますが、我々はコミュニケーションが簡単で機能ブランチ間の変更を制限する小さなチームです。

我々があるレッドゲートのウェブサイト上で

（元に戻すことができます先のデータベースプロジェクトのベースラインを持っている必要）開発ブランチに統合し、早い段階で競合する変更を検出し、基本的には、必要に応じて、以前の移行スクリプトを書き換えますブランチでの作業についての詳細はありますが、正確にはシナリオをカバーしていません。switch branches with readyroll。

ツールを参照すると、基本的には、状態ベースのアプローチと移行ベースのアプローチのどちらかを選択することになりました。私はreadyrollのそれを取るのが好きです。それはミックスを提供します。

私は非常にあなたが最終的に好奇心！