5

別のブランチのバグを修正しながら、新しい機能の開発を可能にするために、単純なブランチ戦略を設定する必要があるプロジェクトがあります。

私が抱えている問題はデータベースにあります。

データベーススキーマはデータベースプロジェクトとしてTFSの一部ですが、十分なテストデータを取得するために、ある時点でライブデータベースのバックアップを取り、それを開発中のテストに使用しました。

現在、データベース（合計ツリー）は、開発者ごとに1セットのデータベースを備えたワークグループサーバーに配置されており、データベースの各セットは、他の開発者がスキーマを変更するときに作成するSQLスクリプトで時々更新されます。

私の質問：各ブランチが自己完結型であり、あるブランチから別のブランチに簡単に切り替えることができるように、これをどのように再編成できますか。SQL Expressの使用とデータベースのブランチ内への配置についてはすでに検討しましたが、これはうまくいきませんでした。また、すべてのデータを使用してスクリプトを作成し、データベースからデータベースを再構築することも検討しましたが、これには時間がかかりすぎ、一部の開発者は十分な頻度でそれを行うのを忘れがちでした。

何か案は？

4

2 に答える 2

3

VisualStudioはデータベースプロジェクトをサポートしています。それを使用すると、うまくいけば、分岐は比較的簡単になります。

データベースのバックアップを復元してから、GDRを使用してデータベーススキーマを同期/アップグレードできます。データ変更のスクリプトを作成する必要があります。

これには、かなりの初期設定作業が含まれます。

于 2012-06-12T09:40:32.087 に答える
0

Visual Studioデータベースプロジェクトは、データを保持しながらデータベースのアップグレードをサポートするための最適なツールではありません。

新規インストールとアップグレードの関係を再考することが役立つ場合があります。多くの企業にとって、アップグレードは後付けであり、アップグレードスクリプトは、新しいインストールスクリプトのデルタに基づいて作成されます。これにより、メンテナンスが重複し、一貫性が失われ、「現在の」スキーマの詳細がアップグレードパスに大きく依存することになります。

したがって、私はお勧めします

  • アップグレードスクリプトのみを維持する（宣言型のソースコードが優先され、アップグレードのたびに完全な更新が可能な場合を除く）
  • ダウングレードをサポートする必要があるかどうかを決定する
  • インフラストラクチャレベルで、各アップグレードスクリプトが最大で1回適用されることを確認します
  • 基本的に、アップグレードスクリプトを編集することはありません。アプリケーションシーケンスの最後に、新しいスクリプトを追加することに固執してください。

これはかなり侵襲的な変更であり、考え方を変える必要があるため、最初に長期的なアップグレードのニーズを慎重に評価してください。変更を行う必要があることを示すのは、複数のリリースおよび開発ブランチでの多数の並行開発または保守が予想されることです。

于 2012-06-12T09:51:55.140 に答える