TFS：ビルドプロセスを緩和するためにフレームワークビルドをキャッシュする方法

Question

私は最近、ビルドプロセスをより管理しやすくするために、リリースエンジニアリングチームに任命されました。私たちの製品の歴史では、バージョン管理リポジトリにすべてのビルドを組み込むだけで、それほど時間を費やすことはできませんでした。これには、ソース（エンタープライズライブラリなどを含む）、独自の社内フレームワークコード、最終的には製品自体が含まれているサードパーティ製品が含まれます。しかし、数年間の安定した製品の成長の後、これは非常に面倒なプロセスになっています。

私たちは、（毎日変わる）製品だけが毎日構築されるような一種の階層型ビルドシステムを確立したいと思いますが、フレームワークコード（変更頻度はそれほど変わらない）と第三者コード（ほとんど決して）は変更されたときにのみ構築されます。新しいバージョンではない新しいバージョンのフレームワークライブラリなどのデバッグコードを容易にするために、&ソースサーバーが設定されていますが、これを容易にする方法はまだわかっています。記録のために、ソース管理にTFVCを使用します。

私の質問は次のとおりです。どのような種類のプラクティスがこの種のものに使用されていますか？このビルドの各「層」（つまり、第三者のためのチームプロジェクト、フレームワーク、製品のためのチームプロジェクト）ごとに別々のチームプロジェクトを設定し、それらを互いに分け合わせますか？依存関係が解決されることを確実にするために、1つの層のビルド製品を次の製品にチェックインしますか？そうでない場合は、バイナリはどこにありますか？これらの要件は、私たちがGACを使用することを要求しますか？

最後に、この種のことについてのガイダンスがあれば、読んでみたいと思っています。しかし、私が工学を構築/解放するのが新しいので、私はまだどこを見るべきか分からない。

ありがとうございます！

Answer 1

最後に質問に答えるには、ビルドの設定と管理についてexcellent book from Microsoftがあります。

あなたの最初の質問に関しては、私たちは依存関係を別々に扱います。私たちのフレームワークをコンパイルするビルドがあります。私たち自身のプロジェクトをコンパイルする別のビルドがあります。

しかし、2回目のビルドのプロセスの一部として、自分のプロジェクトをコンパイルする前に、ビルドマシンでフレームワークビルドからセットアップをインストールします。

このようにして、我々のプロジェクトとは別にフレームワークをリリースすることができます。私たちのプロジェクトは、（ビルド構成を変更することによって）いつ新しいバージョンを使用するかを決定できます。

プロジェクトとフレームワークには、独自のTFSプロジェクトがあります。