VSSソースコントロールにソリューションを追加する
簡単な方法
- DOSプロンプトを開き、「c:\Projects\BuildingSolution」に移動
- 「c:\devtools\nant\bin\nant.exe -buildfile:fourthbuild.guild.xml」を実行
ビルドプロセスの真価が発揮されるのは、チームで開発を進めるときです。各人の労力を、予測可能な形で自動収集すると、開発者は膨大な手作業をせずに済むようになります。そのためには、ソースコード管理（SCC：Source Code Control）が必要です。本稿では、ソース管理のためにVSSを使います。利用可能なVSSサーバーがない場合でも、NAntとCruiseControl.NETは、CVSやSubversionなどの有名なフリーパッケージをはじめ、多様なSCCプロバイダをサポートしています。
VS .NETのソリューションを右クリックし、［Add Solution To Source Control］を選びます（図1）。ルートを選び、プロジェクトテキストボックスには何も入力せずにおきます（図2）。こうすれば、$/buildingsolutionというプロジェクトがVSS内に作成されます。VSSマネージャアプリケーションを開き（図3）、そのプロジェクトまで移動します。BuildingSolutionプロジェクトの内側には、.slnファイルがあります（図4）。これで、ソース管理にすべてを含めることができました。
次のステップは、ビルドファイルに最新のソース管理を取得させることです。NAntと組み合わせれば、NAntContribもあることになります。NAntContribはNAnt用アドインのコレクションで、本稿ではNAntContribに付属の<VSSを使います。ビルドファイルが最新のソース管理を取得するよう変更するには、単にvssgetを呼び出すだけのrunGetLatestターゲットを1つ追加する必要があります。
<target name="runGetLatest"> <vssget user="user" password="" localpath="C:\Projects\BuildingSolution" recursive="true" replace="true" writable="false" removedeleted="false" dbpath="\\Hustler\VSS\srcsafe.ini" path="$/BuildingSolution" />
vssgetタスクは、実にシンプルです。パスワードが空白になっている点に気付いたでしょうか。これは、この環境にはパスワードが必要ないためです。本稿では、NAntは必ず「このユーザーはVSSデータベースへのアクセス権を持っている」という前提を持った、対話的なユーザーコンテキストから呼び出されています。このためには、ビルドマシンに常にログインしている必要があります。それを回避するには、CCNetの中でサービスとして実行される部分を調べ、ビルドファイルに適切な変更を加えてパーミッションを処理するようにします。
バージョン管理の追加
簡単な方法
- DOSプロンプトを開き、「c:\Projects\BuildingSolution」に移動
- 「c:\devtools\nant\bin\nant.exe -buildfile:fifthbuild.guild.xml」を実行
このサンプルビルド環境では、非常にシンプルなバージョン管理メカニズムを使います。本稿の目標は、個々の順次ビルドを、それぞれ対応するビルドフォルダに格納することです。ビルドシステムを使ったバージョン管理については、たとえば「ソース管理におけるラベリング」や、「アセンブリにバージョンを付ける方法」、「GAC」、「割り当て可能なさまざまなバージョン」など、本稿とは完全に別のトピックとなる可能性があるため、説明を割愛します。このツールセットでは、非常に洗練されたバージョン管理システムをサポートできるため、想像力しだいでどのようにも活用できます。
バージョン管理をシンプルに保つために、NAntContribでは<versionタスクを使います。まず、「c:\projects\buildingsolution」ディレクトリに「build.number」という名前のテキストファイルを作成し、そのファイルに「1.0.0.1」と追加します。それから、以下の内容をビルドファイルに追加してください。
<target name="doVersion"> <version buildtype="noincrement" prefix="sys." revisiontype="increment"/> </target>
こうすると、「build.number」ファイルはバージョンが1ずつ増え、それと共に、NAntのプロパティ「sys.version」にバージョンの値が供給されるようになります。これにより、出力ディレクトリで${sys.version}を使うよう変更できるようになったので、個々のビルドが一意のホームディレクトリを持つことが保証されます。最新バージョンは常に最新のフォルダに格納され、それ以外のバージョンはどれも、関連するそれぞれのテスト結果と一緒に、専用のフォルダにアーカイブされます。ソース管理にラベルを追加して、この正確なビルドにマークを付け、ビルドとソースが密接に結び付けることも簡単にできます。この機能は、NAntContribパッケージにあります。
CruiseControl.NETを使い、変更を管理、追跡する
簡単な方法
- 「c:\devtools\ccnet\service\ccnet.config」を編集し、コメントを付ける箇所を変更
- 「StartCCNet.bat」をダブルクリック
これで、何らかのユニットテストの結果をもとに自らの寿命を追跡する、反復が可能なビルドプロセスが出来上がったことになります。本稿の次のセクションでは、これらのテストや、ビルドの残り部分を追跡し、レポートするのがどれほど簡単かを説明します。CruiseControl.NETを起動してください。
CCNetは、CI（Continuous Integration：連続的な統合）に使われます。CIとは、コードを絶え間なく統合するための一連の概念です。つまり、ソース管理は常に監視され、ファイルがチェックインすると、それがきっかけとなってビルドが実行されます。これにより、開発者は自分の行った変更の結果をチェックインから数分で知ることができるほか、そのコードに戻るのも非常に簡単です。
また、CCNetはビルドのレポートと追跡、ユニットテストもサポートしており、さまざまな手段を介してFxCopを利用することができます。
CCNetは、VSSとビルドを監視し、ビルドの結果をレポートおよび追跡するために使用します。このためには、CCNetの一部を設定する必要があります。まず、ビルドを監視し、ビルドを初期化するサーバーインスタンスを設定する必要があります。Webレポートを有効にしたい場合は、IISで仮想ディレクトリも設定する必要があります。また、ビルドをHTMLの電子メールで追跡したり、ビルドの通知をSysTray通知アプリケーションから受け取ることもできます。
CCNetを展開したら、いくつかのファイルをソリューションに合わせて更新する必要があります。「c:\devtools\ccnet\server」フォルダの中に、「ccnet-example.config」ファイルがあります。これが起動ファイルです。CCNetが動作するには、このファイルを「ccnet.config」として保存する必要があります。本稿では、ファイルに次のような変更を加えています。
- CCNetの公式サイトの例を使って、sccをvssに変更。
- マージ（merge）タスクを
<merge><files><file></files></merge>に変更。 - 筆者のファイル構造に一致するよう
<file>要素を変更。 - ビルド実行ファイルを筆者のnantパスに変更。
- ビルドのベースディレクトリ、ビルドファイル、対象とするターゲットをそれぞれ変更。
- 筆者の構造に一致するよう
<xmllogger><logFile>要素を変更。
変更を加えた後は、（変更が完了する前にも何度も実行したと思いますが）「StartCcnet.Bat」をダブルクリックしてCCNetを起動します。CCNetは初回起動時に変更点を探し、最初の自動ビルドを実行します。すべて問題なく実行できたら、こちらに電子メールが届き、Webサイトが更新されます。今、「Webサイト？」と思った人もいるかもしれません。まだWebサイトはセットアップしていません。
「ccnet.config」ファイルは、結果を「../web/log」にコピーするようサーバーに指示します。このディレクトリにWebサイトのデータが格納され、ここがWebサイトの参照先となります。というわけで、次は「c:\devtools\ccnet\web」をポイントする仮想ディレクトリを設定する必要があります。このためには、「c:\devtools\ccnet」まで移動し、Webディレクトリを右クリックします。[Web sharing］タブを選び、「ccnet」という名前でフォルダを共有します。
この設定が完了したら、ブラウザを起動してhttp://localhost/ccnetにアクセスしてみてください。最初のビルドの結果が表示されているはずです。これで、CCNetがFxCopやユニットテストの結果を収集していることがわかります。また、この情報は、「ccnet.config」ファイルで指定したアドレスに電子メールで送信されます。これにより、「ビルドプロセスが中断したら通知される」という、アクティブなビルドプロセスが実現されます。個々の開発者は自分の持ち場で作業し、自分が書いたシステムの部分を対象にユニットテストを書いておけば、実行すべきテストがチェックイン時にすべて実行されます。このことを、統合テストを処理するユニットテストと組み合わせれば、ほんの些細な変更がトリガーとなって、テストがなだれのように失敗する可能性があります。これらのテストは、コードがチェックインしてから数分以内に失敗する可能性があるため、開発者にとっては、問題の発見と修正がより簡単になります。
CCNetのWebサイトでは、FxCopの結果を表示することもできます。プロジェクトページの右上側には、FxCop画面へのリンクがあります。また、CCNetでは、無数のCCNetサーバーアプリケーションを集中管理するためのポイントとなる、「ダッシュボードサイト」が用意さ れています。CCNetには豊富なオプションが用意されているので、詳細は添付のドキュメンテーションを参照してください。
おわりに
本稿では、独自のビルド環境を構築する際に利用できる一連のツールについて概要を述べました。ここで取り上げたサンプルはごく基本的なものですが、ビルドに関する重要ないくつかの側面を概説しています。おわかりのとおり、ビルドプロセスは、単に［F5］キーを押すだけの作業ではありません。「ユニットテストに関するレポートの自動化」や、「コードのレビュー支援」、そして「ビルドの信頼性の向上」は、ビルドプロセスを入念に設計した場合に得られる利点の一部に過ぎません。そして、本稿で説明したツールを使えば、信頼性と実現力は大幅に向上します。
