2

現在のTFS環境には、2つのコレクションがあります。それらを「新しい」と「古い」と呼びましょう。古いコレクションは構造化されておらず、分岐はなく、コードリポジトリとしてのみ使用されています。

新しいコレクションの形式は次のとおりです（可能な限りシンプルにしています）。

-NewCollection
    -Project Name
        -Dev (branch)
        -Main (branch)
        -Support (branch)

現在、このアプローチを採用しているプロジェクトは2、3のみであるため（これまでのところ非常にうまく機能しています）、残りのすべてのプロジェクトを古いコレクションから新しいコレクションに移動したいと考えています。

ここに問題があります。古いコレクションのプロジェクトの多くは、ビジネスロジックのさまざまな側面を保持するWCFサービス（そのうちの約15または20）です。私たちのプロジェクトにはこれらのサービスへの参照があり、これらのサービスのいくつかは相互に参照しています。

非常に多くのサービスがあり、将来的にはゲート付きチェックインなどを使用して自動ビルドとデプロイを実装したいことを考えると、何をするのが賢明でしょうか？

次のようにサービスを構成します。

-NewCollection
    -Service 1
        -Dev (branch)
        -Main (branch)
        -Support (branch)
    -Service 2
        -Dev (branch)
        -Main (branch)
        -Support (branch)
    -Service 3
        -etc.

またはこのように：

-NewCollection
    -Services
        -Dev (branch)
            -Service 1
            -Service 2
            -Service 3
            -etc.
        -Main (branch)
            -Service 1
            -Service 2
            -Service 3
            -etc.

私がこの質問をしている理由は、ビルドなどを構成するときにそれが何を伴うのかわからないためです-私はまだこれを行う方法を学んでおり、コレクションの構造を次のように計画したいと思います近い将来、自動ビルド/デプロイメントを構成するときに、私たちの生活を複雑にすることはありません。

4

2 に答える 2

2

個人的には、あなたが言及した最初の構造を使用します-各製品の下にブランチを保持します。時間が経つにつれて、これは単によりクリーンなアプローチになります。

ビルド定義を設定すると、GET操作の一部であるブランチ/ワークスペースを指定できます。ファイルシステムのレイアウトをソース管理のレイアウトと同じに保つと、他のプロジェクトと同じように、各サービスコンシューマーから適切なサービスインターフェイスを参照できます。次に例を示します。この場合、私は自分のソリューションからAwesomiumSDKを参照しています。

ここに画像の説明を入力してください

于 2013-03-01T11:38:28.097 に答える
1

ブランチ構造の質問に対する答えは、リリースをどのように計画するかによって異なります。

ほとんどの場合、一度に1つのサービスをリリースし、他のサービスの開発が互いに分離していることがわかった場合は、オプション1を選択してください。

複数のサービスを同時に変更して一緒にリリースする可能性が高い場合は、オプション2を選択します。

よくわからない場合、またはリリースが混在している可能性がある場合は、オプション2を選択してください。ブランチで変更する予定のないコードを使用しても、実際のオーバーヘッドはありません。

オプション1を選択し、一度に2つまたは3つのサービスを変更する場合、ブランチ間のすべてのマージを管理することは大きなオーバーヘッドになります。

ビルドに関する質問については、心配しないでください。どのようなブラッシング戦略を選択しても、ビルドは問題ありません。ただし、経験から言えば、単一のブランチでのビルドに必要なすべてのソリューション/依存関係があると、長期的には作業が楽になります。

于 2013-03-01T16:17:56.870 に答える