.NETポートフォリオの自動ビルドプラットフォーム-最良の選択？
.NETアプリケーションのかなり大きなポートフォリオの維持に携わっています。また、ポートフォリオには、他のプラットフォーム（ネイティブC++、ECLIPSフォームなど）の上に構築されたレガシーアプリケーションがあります。
NAntの上に複雑なビルドフレームワークがあり、これらすべてのアプリケーションのビルドを管理しています。ビルドフレームワークはNAntを使用して、さまざまなことを行います。
- Subversionからコードを引き出し、Subversionでタグを作成する
- MSBuild for .NETまたは他のプラットフォームの他のコンパイラを使用してコードをビルドします
- バージョン番号をインクリメントするためにAssemblyInfoファイル内を確認する
- ビルド/リリースに含めるべきではない特定のファイルを削除する
- コードをリリースフォルダにリリース
- バックアップ用にZipコードを作成
- Windowsサービスを展開します。それらを開始および停止する
- 等。
それらのほとんどはNAntだけで行うことができますが、NAntが環境に固有のいくつかのことを行うための拡張タスクをいくつか作成しました。また、上記のプロセスのほとんどは汎用化されており、多くの異なるアプリケーションビルドスクリプトで再利用されているため、ロジックを繰り返さないでください。したがって、これは単純なNAntコードではなく、単純なビルドスクリプトでもありません。ビルドを実行するために一緒に来るNAntファイルは数十あります。
最近、私はいくつかの理由でNAntに不満を感じています。（1）構文がひどい-XML上のプログラミング言語を維持するのは本当に恐ろしいです。（2）Vineでプロジェクトが停止したようです。最近は大量の更新が行われておらず、実際には誰も指揮を執っていないようです。 .NET 4で動作させようとすると、このアクティビティがないためにいくつかの問題が発生します。
それで、その背景のすべてを片付けて、ここに私の質問があります。上記のリストに基づいて達成したいことがいくつかあり、私は主に.NETショップにいるが、.NET以外のプロジェクトも構築する必要があることを考えると、NAntの代わりに検討する必要がありますに切り替える？
私のレーダーには、 Powershell （ psake の有無にかかわらず）、 MSBuild 自体、および rake が含まれています。これらにはすべて長所と短所があります。たとえば、MSBuildは十分強力ですか？私はそれを何年も前に使用したことを覚えており、NAntほど強力ではなかったようです。私のチームに本当にRuby rakeを使用してビルドを行うためだけに学習させたいですか？psakeはプロジェクトを完成させるのに十分成熟しているか？自分でビルドライブラリを自分で使用するには、psakeのようなものを作成する必要がありますか？
他に検討すべきツールはありますか？非常に複雑な.NETポートフォリオの保守に携わっていた場合、どのビルドツールを検討しますか？あなたのチームは現在何を使用していますか？
TeamCityを既に使用している場合は、必要なほとんどの機能で既存の機能を使用できるはずです。 Visual Studioの.slnファイルのビルドをネイティブでサポートしており、すべてのプロジェクトに対して追加の処理が必要な場合は、ビルドマシンで.NET Frameworkの.targetsファイルを変更できるため、個々のcsprojファイルを変更する必要はありません。
これは、Subversionから自動的にチェックアウトし、Zipアーティファクトです。デプロイ可能なアーティファクトと見なされるファイルを制御できます。新しいバージョン（6.0）では、複数のビルドステップも使用できるため、アーティファクトを共有にxcopyで展開する機会があります。
また、ビルドの一部として実行できる（コマンドラインランナーを介して）独自のアプリやタスクを記述して、必要な操作（Windowsプロセスの開始/停止など）を行うこともできます。
ビルド、デプロイ、インストールという3つの異なるアクティビティとして取り組みます。ビルドサーバーにはTFSを使用し、Powershellをいくつか呼び出します。次に、Powershellを使用して、かなり複雑で、ローカルとクラウドの両方の複数のサーバーにまたがる展開とインストールのすべての部分を実行します。 MSBuildやその他のツールを介してPowershellを学ぶのにとても満足しています。また、過去にVisual Buildを使用した経験もあります。
私は Automated Build Studio を使用しています。取り除きたい。
100％MS Buildまたは Team Foundation Build に切り替えない唯一の理由は今日完全に機能するスクリプトを再構築するためにかかるコスト。スクリプトはあまり変わりません...
ただし、次の製品の場合、これは Team Foundation Build になります。主な理由は次のとおりです（他にも理由があります）。
- 導入は簡単です（最新バージョン：2010）
- Visual StudioおよびTeam Foundation Serverと完全に統合されています
- MS Buildのような標準になりつつあります
- Bizsparkでは無料です（スタートアップ向け）
.NETも使用しているので、TFBを使用することをお勧めします。
Bizsparkを申請できない場合、またはライセンスを購入する余裕がない場合は、 CruiseControl.NET +MS Buildといくつかのサポートスクリプト。私が働いていた大規模な公益事業会社では、 CruiseControl.NET を使用してすべてのプロジェクトをビルド、テスト、デプロイ、およびレポートしていました。これには、Webサービスの自動デプロイメントが含まれていました。
hudson とMSBuildをペアで見てください。 MSBuildの強力な機能とhudsonの plugins がパワーをもたらします。
たとえば、MSBuildに移行するまでhudsonを使用してNAntスクリプトを実行し、その後MSBuildスクリプトを実行することもできます。
具体的にあなたのポイントに取り組む：
- Subversion および Tagging
- MSBuild
- AssemblyInfoのピークはSOで asked でしたが、ソリューションはあなたの好みに合わない可能性があります
- MSBuildはファイルを簡単に削除できます
- 「コードをリリースフォルダーにリリースする」-ビルドシステムにそのステップをスキップさせ、いくつかの方法を使用して自動的にデプロイさせることができます。または、必要に応じて [〜＃〜] ftp [〜＃〜] を使用できます。
- MSBuild 圧縮可能
- Windowsサービス 再度 MSBuildは、ここであなたの友達です。
FinalBuilder は、Nice GUIとビルダーサーバーアプリケーションを無料で投入して、要求されたすべての項目を実行できます。
私は現在、MSBuild（> 3000行のスクリプト）を使用して、あなたがしていること（つまり、ビルドからパッケージング、デプロイメントまで）を行っています。 CIはCruiseControl.Netを使用しており、将来的にはTeamBuildに移行できることを願っています。 MSBuildは扱いにくい（XMLでのプログラミング）が、特にバッチ処理と依存関係の追跡は非常に強力です。新しい.Netバージョンで積極的に維持および改善されており、Visual StudioおよびTFSのビルドシステムの基礎となっています。また、ビジュアルスタジオプロジェクトファイルは実際にはMSBuildプロジェクトであり、さまざまな拡張ポイントに接続できます。 MSBuild拡張パック には多くの追加タスクがあり、プログラムで独自のタスクを作成するのは簡単です。 MSBuildを真剣に検討することをお勧めします。最近、Powershellについても学習しており、証明書のインストールや構成など、展開フェーズでの特定のタスクを簡単に見つけられるようにしていますIISなど）。
VisualBuildでMSBuildプロジェクトを編集して、構文を理解し、インテリセンスを提供します。MSBuildに役立つその他の優れたユーティリティをいくつか紹介します。
MSBuild Launch Pad -シェル拡張の場合
MSBuild SideKicks -スクリプトをグラフィカルに編集、実行、デバッグします。
おそらく、ビルドスクリプトの量が多すぎて、ビルドサーバーが足りない場合があります-チームシティを使用すると、意味のある任意の言語またはスタックで各弾丸を実行するシンプルなスクリプトを簡単に作成し、TeamCityビルドタスクを使用して必要に応じて、物事をチェーン化します。
TeamCityを強くお勧めします。構成とセットアップは簡単です。 MSBuildは、vs2008/2010のすべてのプロジェクト/ソリューションファイルが技術的にはMSBuildファイルであるため、NAntよりも望ましいですが、TeamCityをMSBuildまたはNAntで構成できます。
もちろん、TeamCityには費用がかかります。私は個人的にはpsakeも良い候補ですが、他のツールと比較してRubyツールとの摩擦があるためです。
Hudson を検討しましたか？ Javaアプリサーバーを実行する必要があるため、面倒かもしれませんが、 現在のNAntスクリプトを使用できるようにする可能性があります の上に構築する他のツールを使用すること。