.NETポートフォリオの自動ビルドプラットフォーム-最良の選択？[閉まっている]

.NETアプリケーションのかなり大きなポートフォリオの維持に携わっています。また、ポートフォリオには、他のプラットフォーム（ネイティブC ++、ECLIPSフォームなど）の上に構築されたレガシーアプリケーションがあります。

NAntの上に、これらのすべてのアプリケーションのビルドを管理する複雑なビルドフレームワークがあります。ビルドフレームワークはNAntを使用してさまざまなことを行います。

• Subversionからコードを引き出し、Subversionでタグを作成する
• MSBuild for .NETまたは他のプラットフォームの他のコンパイラを使用してコードをビルドします
• AssemblyInfoファイル内を調べてバージョン番号を増分する
• ビルド/リリースに含めるべきではない特定のファイルを削除する
• コードをリリースフォルダにリリース
• バックアップ用にZipコードを作成
• Windowsサービスを展開します。それらを開始および停止する
• 等。

それらのほとんどはNAntだけで実行できますが、NAntが環境に固有のいくつかのことを実行するための拡張タスクをいくつか作成しました。また、上記のプロセスのほとんどは汎用化されており、さまざまなアプリケーションビルドスクリプトの多くで再利用されているため、ロジックを繰り返さないでください。したがって、これは単純なNAntコードではなく、単純なビルドスクリプトでもありません。ビルドを実行するために一緒に来るNAntファイルは数十あります。

最近、私はいくつかの理由でNAntに不満を感じています。（1）構文がひどい-XMLの上にあるプログラミング言語を維持するのは本当に恐ろしいです。（2）プロジェクトは蔓延してしまったようです。最近は大量の更新が行われておらず、実際には誰も舵を取っていないようです。.NET 4で動作するようにしようとすると、このアクティビティがないためにいくつかの問題が発生します。

それで、その背景のすべてを片付けて、ここに私の質問があります。上記のリストに基づいて達成したいことがいくつかあり、私は主に.NETショップにいるが、.NET以外のプロジェクトもビルドする必要があることを考えると、NAntに代わる代替案がありますか？に切り替えますか？

私のレーダー上のものが含まPowerShellの（の有無にかかわらずpsake）、MSBuildのを自分自身、そしてによって熊手。これらにはすべて長所と短所があります。たとえば、MSBuildは十分強力ですか？私はそれを何年も前に使用したことを覚えており、NAntほど強力ではなかったようです。本当にrakeを使用してビルドを行うためにチームにRubyを学習させたいですか？psakeは本当に自分のポートフォリオを固定するのに十分なほど成熟したプロジェクトですか？Powershellは「金属に近すぎる」ので、自分でビルドライブラリを作成して、それをそのまま使用するためにpsakeと同じようにする必要がありますか？

他に検討すべきツールはありますか？非常に複雑な.NETポートフォリオの保守に携わっていた場合、どのビルドツールを検討しますか？あなたのチームは現在何を使用していますか？

TeamCityを既に使用している場合は、必要なほとんどの機能で既存の機能を使用できるはずです。Visual Studio .slnファイルのビルドをネイティブでサポートし、すべてのプロジェクトに追加の処理を行う必要がある場合は、ビルドマシンで.NET Frameworkの.targetsファイルを変更できるため、個々のcsprojファイルを変更する必要はありません。

Subversionからアーティファクトを自動的にチェックアウトし、デプロイ可能なアーティファクトと見なされるファイルを制御できます。新しいバージョン（6.0）では、複数のビルドステップも使用できるため、アーティファクトを共有にxcopyで展開する機会があります。

また、ビルドの一部として（コマンドラインランナーを介して）実行できる独自のアプリ/タスクを記述して、必要な操作（Windowsプロセスの開始/停止など）を行うこともできます。

ビルド、デプロイ、インストールという3つの異なるアクティビティとして取り組みます。ビルドサーバーにはTFSを使用し、Powershellをいくつか呼び出します。次に、Powershellを使用して、かなり複雑で、ローカルとクラウドの両方の複数のサーバーにまたがる展開とインストールのすべての部分を実行します。MSBuildやその他のツールを介してPowershellを学ぶことに非常に満足しています。また、過去にVisual Buildを使用した経験もあります。

hudsonとMSBuildをペアで見てください。MSBuildの強力な機能とhudsonのプラグインが付属しています。

たとえば、MSBuildに移行するまでhudsonを使用してNAntスクリプトを実行し、MSBuildスクリプトを実行することもできます。

具体的にあなたのポイントに対処します：

• Subversionとタグ付け
• MSBuild
• AssemblyInfo覗くた尋ね SO上で、しかし、解決策は、あなたの好みに合わせてではないかもしれません
• MSBuildはファイルを簡単に削除できます
• 「コードをリリースフォルダにリリースする」-ビルドシステムにそのステップをスキップさせ、いくつかの方法を使用して自動的にリリースさせることができます。または、FTPを使用することもできます。
• MSBuild は圧縮できます
• Windowsサービスは、再び MSBuildのは、ここにあなたの友達です。

Automated Build Studioを使用しています。私はそれを取り除きたいです。

100％MSビルドまたはTeam Foundationビルドに切り替えない唯一の理由は、今日完全に機能するスクリプトを再構築するためにかかるコストです。スクリプトはあまり変わりません...

ただし、次の製品の場合、これは主に以下の理由から、迷わずにTeam Foundationビルドになります（さらに多くの理由があります）。

• 導入は簡単です（最新バージョン：2010）
• Visual StudioおよびTeam Foundation Serverと完全に統合されています
• MS Buildのような標準になりつつあります
• Bizsparkでは無料です（スタートアップ向け）

.NETも使用しているので、TFBを使用することをお勧めします。

Bizsparkを申請できない場合、またはライセンスを購入する余裕がない場合は、CruiseControl.NET + MS Buildといくつかのサポートスクリプトを入手できます。私が働いていた大規模な公益事業会社では、CruiseControl.NETを使用してすべてのプロジェクトをビルド、テスト、展開、およびレポートしていました。これには、Webサービスの自動デプロイメントが含まれていました。

FinalBuilderは、素晴らしいGUIとビルダーサーバーアプリケーションを無料で投入することで、要求されたすべての項目を実行できます。

私は現在、MSBuild（> 3000行のスクリプト）を使用して、実行中の作業（つまり、ビルドからパッケージング、デプロイメントまで）を行っています。CIはCruiseControl.Netを使用しており、うまくいけば、将来TeamBuildに移行できます。MSBuildは扱いにくい（XMLでのプログラミング）が、特にバッチ処理と依存関係の追跡は非常に強力です。新しい.Netバージョンで積極的に維持および改善されており、Visual StudioおよびTFSのビルドシステムの基礎となっています。また、ビジュアルスタジオプロジェクトファイルは実際にはMSBuildプロジェクトであり、さまざまな拡張ポイントに接続できます。MSBuildの拡張パックには多くの追加タスクがあり、プログラムで独自のタスクを作成するのは簡単です。MSBuildを真剣に検討することをお勧めします。最近、Powershellについても学習しており、証明書やIISなどのインストールと構成など、展開フェーズでの特定のタスクを簡単に行えるようになっています。

構文を理解してインテリセンスを提供するVisualStudioでMSBuildプロジェクトを編集します。MSBuildに役立つ他の優れたユーティリティをいくつか示します。
MSBuild Launch
Pad- シェル拡張用MSBuild SideKicks-スクリプトをグラフィカルに編集、実行、デバッグします。

おそらく、ビルドスクリプトの量が多すぎて、ビルドサーバーが足りない場合があります-チームシティを使用すると、意味のある任意の言語またはスタックで各弾丸を実行するシンプルなスクリプトを簡単に作成し、TeamCityビルドタスクを使用して必要に応じて物事をチェーン化します。

TeamCityを強くお勧めします。構成とセットアップは簡単です。MSBuildは、vs2008 / 2010のすべてのプロジェクト/ソリューションファイルが技術的にはMSBuildファイルであるため、NAntよりも望ましいですが、TeamCityをMSBuildまたはNAntで構成できます。

もちろん、TeamCityには費用がかかります。私が個人的に選択したのは、psakeも良い候補であるにもかかわらず、Rubyツールとの摩擦が他のツールと比較して単純であるためです。

ハドソンを検討しましたか？Javaアプリサーバーを実行する必要があるため、面倒なことはありませんが、現在のNAntスクリプトを使用して、他のツールを使用してその上に構築できると思います。