継続的な統合により、巨大なVisual Studioソリューションが不要になりますか？

私は他の人と一緒に仕事をするソリューションを持っていますが、ソリューションには約50-60件のプロジェクトがあります。私の意見では、開発中のビルド時間が遅くなり、一般的にIDE開発中に必要以上に。継続的な統合により、巨大なVisual Studioソリューションが不要になりますか？

このソリューションがより小さなソリューションに分割されない唯一の理由は、あらゆる種類のリファクタリングやその他のコード変更が、他のソリューションで破損を引き起こす可能性があり、コードがリポジトリにプッシュされてから彼が仕事をしようとするときに他の開発者によって発見された。

私は継続的な統合に関する多くの経験がないので、（ビルドの自動化に伴う他の素晴らしいメリットを除いて）他の開発者がソリューションの必要性を避けている標準的な方法ですかたくさんのプロジェクトがありますか？誰かが継続的な統合と.NET/Windows開発者のための自動化を行う上で良いプライマルをお勧めしますか？

出典

2012-03-05 Nathan Ridley

はい、50-60件のプロジェクトの解決策が最も多すぎます。おそらく、これらのプロジェクトのすべては、ソリューションが構築する特定の製品に関連しておらず、その多くはフレームワークと見なすことができますか？

フレームワーク（製品に依存しない）プロジェクトを独自のフレームワークソリューションに移行し、フレームワークプロジェクト自体ではなく、製品ソリューションのコンパイル済みアセンブリへの参照を追加することをお勧めします。

（最近リリースされた）TeamCity 7を継続的な統合に使用すると、提供する機能の1つにNuGetパッケージがあります。つまり、会社のフレームワークをNuGetパッケージにパッケージ化して、各製品ソリューションへの展開を非常に簡単にすることができます。継続的インテグレーション/配信に

いくつかの素晴らしいリソースは次のとおりです。リンクのため

出典

2012-03-05 10:12:27 devdigital

、感謝します。 –

継続的な統合により、巨大なVisual Studioソリューションが不要になりますか？

答えて

関連する問題