ああ、面倒だ。 Visual Studio 2003 および Cruise Control.NET。シンプルかつエレガント。ソリューションを構築するための基本的な NAnt スクリプトがあれば準備完了です。 NUnit を実行すると、CC とボブの叔父が理解できる形式で出力されます。これを数値化してみましょう。当社のクルーズ サーバーには、Subversion クライアント (コマンド ライン) と .NET 1.1 SDK が含まれています。 Visual Studio はインストールされていません。当然のことですが、これはサーバーであり、クルーズにはシステムを構築するためのものが必要なだけです。
Visual Studio 2005 を入力します。最近、2005 プロジェクト用に CI をセットアップしましたが、これは多くの点でまったく醜いです。まず、MSBuild を使用してシステムを構築しようとしました。
msbuild /t:rebuild solutionname.sln
(またはデバッグやリリースなどの任意のターゲット)
と入力するだけなので問題ありませんでした
。先ほども言いましたが、これだけであれば問題ありませんが、すぐに非常に醜くなります。
まず、VSTS 単体テスト プロジェクトがあります。チームは全員 Visual Studio Team Suite を備えています。高価な提案ですが、私よりも賢い人がずっと前に提案したものです。でも問題ありません。私たちは実際にはテスト マネージャーをあまり使用していません。自動化された Web テストはありません。そのため、単体テストを作成するだけです (そして、Jamie Cansdales の優れた TestDriven.NET を使用してテストを実行します)。ただし、MSBuild が VS 単体テスト プロジェクトを含むソリューションを取得すると、追加のアセンブリ セット (GAC_MSIL およびその他の場所に埋め込まれたアセンブリ) が必要になります。 MSBuild を実行するための ccnet.config ファイル内のスニペットは非常に簡単です:
<msbuild>
<実行可能ファイル>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe</実行可能ファイル>
<workingDirectory>D:ccnetprojectsプロジェクト名</workingDirectory>
<プロジェクトファイル>ソリューション名.sln</プロジェクトファイル>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<targets>ビルド</targets>
<タイムアウト>600</タイムアウト>
<ロガー>C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
強引な方法 (MSBuild を実行し、必要なアセンブリを把握し、探しに行き、泡立て、すすぎ、繰り返し) により、(単体テスト プロジェクトを含む) 2005 ソリューションをコンパイルすることができました。ただし、実際にテストを実行するのは別の話です。数百の単体テストを実行するよう誘導しようと、MSTest.exe を 1 ～ 2 時間実行し続けたとき、ここでもまた総当たりの力が最高に君臨しました。単体テストを取得するための cc.config エントリは次のようになります:
<exec>
<実行可能ファイル>C:Program FilesMicrosoft Visual Studio 8Common7IDEMSTest.exe</実行可能ファイル>
<baseDirectory>d:ccnetprojectsプロジェクト名</baseDirectory>
<buildArgs>/testcontainer:SourceTestsUnitTestsbinAutomatedBuildUnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>
このサーバーには Visual Studio がインストールされていないと述べたことを思い出してください。 VS2005 ソリューションの場合は、.NET SDK 2.0 をインストールしただけで十分でした。 MSTest.exe は含まれていませんが、別のシステムからファイル (ハード ドライブ全体に散在するクレイジーな追加 DLL のセット) を入手し、EXE があった場所に貼り付けたので、満足できるでしょう。
単体テスト プロジェクトに対して MSTest を実行する場合は、サイコロは必要ありません。テストの実行を開始しましたが、その後、おかしな COM エラー (CLSID が登録されていません) が発生しましたが、私にはそれで十分でした。 Visual Studio 2005 の愚かな COM レジストリ設定をすべて追跡するつもりはありません。そして、これは一体何だったのでしょうか? COM?コンパイラ 3 つほど前にそれを削除したと思いますか?
そのため、私は完全なチームスイートをサーバーにインストールすることにこだわりました。わかった、噛みますよ。つまり、すべてが必要なわけではないので、大丈夫です (100 万件のレジストリ エントリがいっぱいになるのを見ながら、私は自分に言い聞かせています)。数時間後、私は再びコマンド プロンプトを見つめて MSTest.exe コマンドを入力しました。そしてダイアログボックスがポップアップ表示されます。はい、何かが間違っていることを知らせるモーダル ダイアログ ボックスです (詳細は覚えていませんが、あまり有益ではありませんでした)。
Visual Studio は正常にインストールされており、コンパイル、実行、および目的のソリューションをビルドすることはできましたが、MSTest.exe を使用してコマンド ラインからテストすることはできませんでした。どれだけ頑張っても、どれだけ掃除しても、どれだけの処女を犠牲にしても、それは解決しません。そして別の問題があります。 2003 と NUnit テストにより、素晴らしい統計が得られました。タイミング、有益なメッセージ、すべてが良いものです。 MSTest では何も得られません (x 回のテストが実行され、おそらく失敗したこと以外は何も得られませんでしたが、失敗の詳細が得られるかどうかを確認するまでには至りませんでした)。それに加えて、MSBuild ロガーが食い込み、あまり役に立たない約 10,000 行のゴブリー グックを生成します。はい、時間をかけて新しい xslt を書いてきれいにすることもできますし、MSBuild タスク ロガーを埋める「すべて問題ありませんでした」という行を削除することもできますが、私の料金ではそれは付加価値がないと思います。
これは、CC.NET/MSBuild/MSTest の組み合わせがいかに役に立たないかを示す、ビルドから受け取ったサンプルメールです:
BUILD SUCCESSFUL
プロジェクト: PROJECTNAME
作成日: 2006 年 12 月 8 日 8:08:30 AM
再生時間: 00:00:55
統合リクエスト: intervalTrigger がビルドをトリガーしました (ForceBuild)
エラー (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): エラー MSB4041: プロジェクトの既定の XML 名前空間は MSBuild XML 名前空間である必要があります。プロジェクトが MSBuild 2003 形式で作成されている場合は、xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " を <Project> に追加してください。要素。プロジェクトが古い 1.0 または 1.2 形式で作成されている場合は、MSBuild 2003 形式に変換してください。
警告 (1)
SourceReportsServerReportsServerReports.rptproj (,): warning MSB4122: プロジェクト "SourceReportsServerReportsServerReports.rptproj" のプロジェクト依存関係のスキャンに失敗しました。プロジェクトの既定の XML 名前空間は、MSBuild XML 名前空間である必要があります。プロジェクトが MSBuild 2003 形式で作成されている場合は、xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " を <Project> に追加してください。要素。プロジェクトが古い 1.0 または 1.2 形式で作成されている場合は、MSBuild 2003 形式に変換してください。 D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
テスト実行: 0、失敗: 0、未実行: 0、時間: 0 秒
テストは実行されません
このプロジェクトにはテストがありません
前回のビルド以降の変更 (0)
醜いです。本当に醜い。 MSBuild は大量のクレイジーな出力を生成します。新しい MSBuild ファイルを作成することは簡単なことではありません。NAnt をよく知っている私のような人間ですら、MSBuild がどのように動作するのかについてはまだ頭を悩ませています。 MSBuild ではレポート プロジェクトをビルドできないため、Visual Studio 内で特別な構成を作成してレポート プロジェクトを省略する必要がありました (そのため、上記のターゲット AutomatedBuild は開発者が使用している構成と同じではなく、私がやりたくないことです。 CI サーバーのポイント、全員にとって一貫したビルド）。
上記の出力から、Cruise は、ビルドは問題ありませんでしたが、MSBuild ロガー (レポート プロジェクト) から出力されたエラー メッセージがあると述べました。これは 2005 年のプロジェクトなので、この情報には意味がありません (記録されているバグだと思いますが、いつ修正されるかは誰にもわかりません)。そして、実際には、MSTest の出力を電子メールに統合することはできません。なぜなら、何もないからです。このプロジェクトには 100 個ほどのテストがありますが、ロガーは何も生成しません。
さらに、MSBuild で処理できないプロジェクトの種類もあり、別の MSBuild タスクを呼び出して特定のプロジェクトを除外できる MSBuild ファイルを (MSBuild Sidekick のような優れたものを使用する場合でも) 作成するにはロケット サイエンティストが必要です。これは確かに、除外リストを作成するだけだった 2003 年ほど簡単ではありません (グリッド コントロールに追加のライセンスがなく、試用版を確認したときにもモーダル ダイアログが表示されたため、クライアント アプリを除外しました)コンパイラ）。
さて、これはほとんど暴言ですが、ここにはいくつかの知恵があります。継続的インテグレーションはそれほど難しいものである必要はありません。 CruiseControl.NET は優れたツールであり、新しいツールやそれらのツールからの出力の統合に非常に柔軟です。しかし、それらのツールが 100 万ものレジストリ設定とさらに多くの DLL (非常に特殊な場所に配置されている) を必要とし、それらを GAC に放り込んですぐに終わらせることはできません) を必要とし、ただの人間では不可能な大量の XML をダンプする場合、おそらく DonXml なら翻訳できるでしょうが、それは間違っています。そして、私たちにできる組み込みのチーム ビルドについては、a) コード チェックインからトリガーするようにビルドをスケジュールできないこと、b) 完全なチーム スイート クライアントをサーバーにインストールする必要があることと同じくらい役に立ちません。 。最悪の場合、私が最初に CC.NET サーバーのセットアップを開始したときは 4 時間かかりました。今では 1 時間で完了できます (最初のプロジェクトのビルドのテストも含まれます)。コンパイルするものを取得するだけですでに丸一日を費やしてしまいました。現在コンパイル中ですが、出力はクソで、テストは実行されていません。これは私にとって十分ではありません。 MSBuild と (おそらく) MSTest を CruiseControl.NET で実行できます。不可能ではありません。完全なクライアントをインストールし、プロジェクトが「適切」であれば、それは機能しますが、出力はそれほど熱くなく、コンパイルが発生するとサーバーの CPU スラムが発生するのがわかります。
私のアドバイスとしては、MSBuild、MSTest、CruiseControl を組み合わせようとするのは避け、NAnt と NUnit に固執してください (2005 ソリューションを構築する場合は、必要に応じて MSBuild を使用してください)。
言うまでもなく、私は現在 1 つの選択肢を検討しています。サーバー上の VS2005 のインストールをダンプし、すべての単体テストを NUnit に戻し、すべての処理に NAnt を使用します (そして、VS2005 プロジェクトの実行タスクとして MSBuild を呼び出すだけです)。まだ 2003 プロジェクトを実行する必要があるので、VS2003 および VS2005 プロジェクトをビルドし、NUnit、MSBuild、NAnt、Simian、FxCop などを実行し終わる頃には、CI サーバーはフランケンシュタインの怪物のようになっているでしょう。ミックス。たとえそれを考慮しても、NAnt を使用すると出力はよりシンプルになり (CC.NET とうまく統合されます)、テスト出力は便利で有益になります。また、明確な可能性があるサーバーに 15,000 ドルのソフトウェアをインストールする必要はありません。レジストリ キーが見つからないときにモーダル ダイアログをポップアップするためです。
うーん。ああ。