.NETプロジェクトとソリューションの任意のビルドを集中管理する/制御する

Question

何年もの間、完全なプロジェクトビルドを実行するための一連のNAntスクリプトを作成して調整しました。メインスクリプトは単一のアプリケーションエンドポイント（たとえばWebアプリケーションプロジェクト）を取り、ソースコントロールから完全にビルドします。スクリプトにはビルドの出力場所、ソース管理アドレスなどに関する必要な情報があらかじめ設定されています。主なポイントは、情報をほとんど提供せず、プロジェクトを一から構築できることです。これは私の質問の「恣意的な」部分を満たすものです。

私は以前、いくつかのソフトウェア製品（主にWebアプリケーション）を生産している企業で働いていました。この環境は、製品ごとにインテグレータが存在する典型的な連続的な統合設定に非常に適しています。私は、完全なリリース候補ビルドとQA展開を処理するために、CIビルドとインテグレータの両方として機能するインテグレータを設定しました。これらのインテグレータはマスタビルドスクリプトを使用するため、インテグレータ自体はソース管理監視とマスタNAntスクリプトへの呼び出しにすぎません。

私は現在、多くのアプリケーションを作成する開発グループで働いています。しばしば、開発者は、もともと他の人が作成したアプリケーションをサポートするよう求められています。私が始めたときには、ビルド管理はありませんでした。私は、1つのビジネスユニットのプロダクトスイートの4人チームのリード開発者（半分程度の完全なシステム）として、グループ内で特にユニークな立場にいます。私は、CIビルドとRCビルドの両方を行うためのマスタービルドスクリプトでCruiseControl.Netを実装しました。これは、ビジネススイート製品内の固定された一連のプロジェクトを検索します。

私は何年も前からCCNetを使用していましたので、私はそれができることを十分に認識しています。私は、私の製品スイート内のすべてのプロジェクトに使用しているので、継続的な統合分野への貢献に大きな敬意を表します。私は私のチームに、公式RCビルドインテグレーターの使用を、開発以外の場所を対象とするもののマスタービルダーとして強調しました。これにより、CCNetの管理下にある固定された一連のプロジェクトを適切に制御することができます。

しかし、他のアプリケーションを構築する他の開発者がいます。これらのうちのいくつかは、プロジェクトのライフサイクル（何か他のものに変更しようとしているもの）までは、しばしばソース管理にさえいない1つの開発者プロジェクトです。これらのプロジェクトの多くは、展開された後に開発に多くの人生をもたらさないワンオフです。それにもかかわらず、彼らはまだサポートする必要があります。それらをサポートする上で不可欠なのは、これらのプロジェクトを一元的にビルド管理しなければ、QAに移行するリリース候補ビルドが最終的には個々の開発者マシンで実行されることです。これは、もちろん、開発者のマシンビルドの他の要因のうち、すべてがソース管理にあることをゼロに保証します。

私が解決しようとしてきた問題は、これらの任意のビルドを集中管理するためにどのようなシステムを使用できますか？これは間違いなくユニークな問題ではありません。しかし、私は集中的なビルド、オートメーションと継続的な統合を重視している読書の多くで、固定プロジェクト/製品とその開発を継続的にサポートすることに重点を置いています。新しいプロジェクトの開発を常時行っているビジネスでは、どのようなプロセスが使用されていますか？これらのタイプのプロセスを使用していませんか？

マスタービルドスクリプトはビルドサーバー上に存在しますが、使用するのは面倒です。また、私はビルドサーバーへのコンソールアクセスを制限することを好むでしょう。したがって、中央管理システム上の任意のビルドから簡単にアクセスできる管理システムが必要です。

私が探しているものは、MS Team Buildのカバーの下に置くことができます。残念なことに、私がそれについて読むことを始めるときはいつでも、私はMSのマーケティング資料に乗り始め、すぐに自分の道を失い、私がやりたいことがそれで行えるかどうかを実際に見出すことはありません。さらに、ライセンス費用は、Team Foundation ServerとTeam Systemに関する過去の一般的な議論の中で、大きな可能性を秘めていると指摘されています。

私は、この問題を解決した人から意見を提供してくれる人がいることを知りたいと思います。私はマスター "build-any-project"ビルドスクリプトをベースにした集中ビルドシステムでいくつかの作業を行ってきました。しかし、私が持っているのは、初期段階にあり、主に私が取り組んでいるプロジェクトの種類だけをサポートするように構築されています。この時点で、多くのアプリケーションタイプや、Visual Studioで可能な多数のプロジェクト/ソリューション構成を処理するために必要なサポートはありません。

Answer 1

私が中央ビルドシステムで目にする最大の問題は、世界でも最高の意志であっても、ツールは時間の経過とともにチーム間で分岐するということです。

特定のプロジェクトのビルドシステムを設計して、単一のモジュールなどをチェックアウトする必要があります。 MyProjectBuildEnvironmentを実行して、非常にツールに中立的な方法で単一のスクリプトを実行する。 Windowsシステムでbuild.bat

可能であれば、ビルド環境で使用されるすべてのツールは、マシンレベルのインストーラを要求するのではなく、モジュールMyProjectBuildEnvironmenをチェックするだけで実行可能にする必要があります。

これらの2つの制約は、チームが与えられた時間に好きなツールを使用する自由を妨げません。

中央ビルドシステムは、プロジェクトごとに1つのモジュールをチェックアウトし、単にbuild.batファイルを実行する単純なシステムにすることができます。あなたはそれをメタ構築システムと呼ぶことができます。

それぞれのプロジェクトのビルドモジュール名を記述する簡単なwikiは、誰もがそのモジュールをチェックアウトして、共通のbuild.batコマンドでそれを蹴飛ばすのに十分なはずです。

最終的に、ビルドを開始するためのスクリプトは、常にビルドを完了するためにツールが欠落しているか、マシン構成を調整する必要があるかどうかをユーザーに知らせる必要があります。