web-dev-qa-db-ja.com

TFSでアセンブリ参照を維持するための戦略

私は3つのブランチセットアップを持っています：開発、QA、製品。一般的なサードパーティおよび内部アセンブリを保存する参照フォルダーがあります。 mgmntの変更は困難でした。 DevsがReferencesフォルダーに移動して新しいバージョンをチェックインするのを忘れることがあります。

プロジェクトの参照を試みましたが、その結果、binフォルダーが参照されました。これは、ビルド順序を正しく保ち、すべてのプロジェクトを常に同じソリューションファイルに含める限り、うまく機能します。これは常に良いアイデアや実現可能とは限らないため、参照フォルダーに移動しました。

継続的インテグレーションはこれらの問題のいくつかを軽減するのに役立ちますが、CIサーバーはまだありません。 Manuel開発者の介入をあまり必要としないReferencesフォルダを管理するための良いプロセスはありますか？

ビルド後にファイルをコピーすることを考えました。他の開発者が新しいバージョンにアクセスできるように、新しいバージョンをチェックインする問題は解決しません。

TFSがあります。これは社内の企業開発用です。私たちの製品のオープンソースを必要とするものはすべて不可能です。

[〜＃〜]更新[〜＃〜]
私は FinalBuilder を所有しています。私はそれを使用するのが初めてで、このプロセスに役立つかどうかはわかりません。

version-controlteam-foundation-server
4
P.Brian.Mackey

考慮すべき点がいくつかあると思います。

1-ソースツリーがかなり複雑な場合は、ソリューションファイルをビルドシステムから分離し、MSBuild TraversalプロジェクトなどのMicrosoftの推奨事項を使用して* proj MSBuildファイルを直接ビルドすることをお勧めします（詳細については、この記事を参照してくださいこのベストプラクティス

http://msdn.Microsoft.com/en-us/magazine/dd483291.aspx

ソリューションファイルをビルドシステムから切り離すことで、ビルドシステムを厳密に制御し続け、プロジェクト参照を有効に活用し、開発者が生産性オプションとしてソリューションを自由に使用できるようになります。開発者が新しいプロジェクトを追加する場合、ビルドプロセスの適切な場所にそれを含めるという意識的な決定があります。さらに、MSBuildの「BuildProjectReferences」プロパティを使用して、MSBuildがプロジェクト参照を自動ビルドするか、既存の出力を使用するかを指定できます。

2-Nuget ... http://nuget.org/

Nuget to Hostなどのパッケージ管理システムを使用してサードパーティの依存関係をデプロイすると、それらをソース管理から除外して、新しいバージョンを公開し、新しいNugetパッケージを自由に作成できます。最近のNugetの採用率は非常に高く、インターネットドキュメントは、独自のNugetサーバーをホストするか、パブリックサーバーを使用するか、または完全にスキップするかを決定するのに役立ちます。

以上のことをすべて述べた上で、これらのソリューションのいずれかが適切であるかどうかに関係なく、できるだけ早くCIビルドを実行することをお勧めします。これは、品質を強化し、チームがプロトコルに従う習慣を身に付けるために非常に重要です。実際、CIビルドの立ち上げ後に品質が向上する問題がある場合は、Gated-Checkinビルド（無料のTFSの一部）を使用して、チェックインの前にスタッフビルドが正しくビルドされるようにすることをお勧めします。

依存関係ツリーをソース管理にチェックインしておくことを選択した場合は、a）内部依存関係をサードパーティの依存関係から分離し、b）依存関係フォルダーをブランチ固有にして、ブランチに基づいて異なる依存関係セットに対してビルドできるようにすることをお勧めします簡単に。

3
Nick Nieslanik

私たちにとって最も効果的なのは、同じローカルフォルダー構造を持つ同一のワークスペースがすべて揃っていることを確認することです。その後、参照はプロジェクトファイル内の相対ファイルパスを使用できます。 I.E. dev Project1プロジェクトファイルでは、次のようになります。

<Reference Include="Project2">
    <HintPath>..\..\..\Project2_Dev\Project2\bin\Release\Project2.dll</HintPath>
</Reference>`

プロジェクトは同じソリューション内にありませんが、同じフォルダー構造を持っているため、これは誰にとっても機能します。これにより、アセンブリをTFSに保存して更新する必要がなくなります。 Project2の最新情報を入手してビルドするだけです。

これの短所は次のとおりです。

  • Project1をビルドするには、すべての参照プロジェクトをローカルに持っている必要があり、それらもビルドできる必要があります。複数のプロジェクトに依存関係のチェーンがある場合、これは面倒になることがあります。また、請負業者にProject1へのアクセス権を与えたが、他のすべてのプロジェクトでそれらを設定したくない場合にも、苦痛でした。この場合、それらの空のフォルダー構造を作成して、事前に構築されたdllのみをビンに配置するか、質問で説明したように共有のAssembliesフォルダーを一時的に使用しました。
  • マージすると、TFSはプロジェクトファイルを互いに一致させ、プロジェクトファイル内の相対パスを上書きしようとします。これは、VS 2013へのアップグレード以降、保持するバージョンを確認する必要がなくなったため、特に私にとって問題です。自動的に選択されます。そのため、チェックインする前に、csprojファイル内のこれらの行に対する変更を手動で元に戻す必要があります（これにより、解決策を見つけることを期待してこの質問が表示されました）。
0
xr280xr