TeamCityのビルド構成の理解

Question

私たちの開発チームは、CIが私たちの痛みを和らげる段階にあります。過去2日間だから私は、CIソリューションを見てきた、それは基本的に2つのオプションに降りてきた：私はいくつかの深刻な読書をした

ジェンキンス

1. チームシティー
2. 、および2を比較します私はTeamCityに傾倒しています。 これは比較質問ではありません

   私たちのチームには複数のソリューションがあり、それぞれのソリューションは複数のプロジェクトで構成されています。私たちの現在のビルド・プロセスは、バニラです....

   右

テイクリリースを構築し、DEV/QA/PRODにコピーします

をリリースするように設定

1. 。

   私を少し混乱させる唯一の事は、TeamCityのビルド構成です。無料版では、20の構成を構築できます。私はいずれかをインストールしていないので、私はどのようにビルド構成が動作していないか分かりません。

   複数のプロジェクトで1つのビルド構成を共有できますか、それとも各プロジェクトのビルド構成が必要ですか？

   これは最終的には40種類におよぶソリューションがあり、ソリューションごとに少なくとも3つのプロジェクトがあるため、最終的には契約を破ることになります。

   ビルド構成がプロジェクトに直接リンクされている場合は、少なくとも120のビルド構成が必要です。これは経営陣にとっては簡単な売却ではありません。

   TeamCityのビルド構成の仕組みについてもう少し詳しく知ることができますか？ MSBuildのか、Visual Studioのなどであるそのうちの一つ

Answer 1

ビルド構成で使用すると、手順を構築定義するので、通常あなたは、ソリューションごとにビルド構成を持つことになり、

私たちは、ビルドのために偽の使用していますが、「を使用してビルドとテストFake 'はビルド構成であり、TeamCityのメインページには次のようなステータスが表示されます：

Answer 2

ビルド構成はプロジェクトと1-1の関係がありません。 Tests、Nightly、Releaseの3つのビルド構成しかありません。

ビルド構成には複数のビルドステップを含めることができます。
これらのビルドステップのそれぞれは、msbuild、スクリプト、単体テスト、Octopusデプロイメントなどを実行するアクションを実行できます。
ソリューション内に複数のビルドステップを設定することができます。ソリューションやビルドプロジェクトで異なる目標を設定しています。

マゾスティックな理由が本当に必要だった場合は、1つのビルド構成で40のソリューションすべてを構築できます。
しかし、その容易さや難しさは、バージョン管理の仕方によって異なります。 TeamCityには、VCS Roots（バージョンコントロールシステム）という概念があります。
複数のソリューションを1つのBuild構成でビルドする場合は、別々のreposにある場合はmultiple VCS roots for the Configurationを設定するか、reposをプルするスクリプトを設定する必要があります。
一緒にビルドする必要がある可能性がある関連ソリューションが同じリポジトリにある場合は、1つのVCSルートから離れてしまう可能性があります。