オープンソースの.NETツールを使って洗練されたビルド環境を作る

はじめに

　「アプリケーションをビルドする」というのは、単に［F5］キーを押すことだけではなく、それよりもはるかに膨大な作業が伴います。品質管理パッケージが続々とリリースされて数を増やしつつあり、.NETプラットフォームの開発者たちは、非常に洗練されたビルドプロセスを生み出すためのオプションを選べるようになりました。本稿では、ビルド環境のサンプルを1つ挙げ、「信頼性があり、予測可能で、価値が付加されたビルド」を作り上げるために、どれほどたくさんのツールが一緒に動作しているのかを示します。

　ビルドシステムの目標は、大まかには次のようになります。

ソース管理（ソースコントロール）を監視して、変更点がないかどうかを調べる
最新のソースコードをソース管理から取得する
バージョン管理されたディレクトリの中でアプリケーションをビルドする
新しいアセンブリ上でユニットテストを実行する
新しいアセンブリでコーディング標準の妥当性を確認する
最新のコードをベースに、ドキュメンテーションを作成する
結果をWebや電子メール経由で発表する

　このように、ビルドプロセスでは、多くのタスクを自動処理します。

　まず、NAntから始めて、サンプルビルドを作成します。次に、そのNAntビルドファイルを展開して、「他に何ができるか」を示すサンプルとして、その他いくつかのタスクを実行します。手順は次のとおりです。

ビルド環境のセットアップ
Visual Stdudio .NETを使って「プログラム」ソリューションをビルドする
最初のNAntビルドファイルを作成し、ビルドする
Visual Studio .NETを使ってテストプロジェクトをビルドする
NUit testをビルドに追加する
FxCopを使ってビルド中にコーディング標準の妥当性を確認する
NDocを使ってビルド中にAPI Documentationを作成する
VSSソース管理にソリューションを追加する
ビルドファイルにSCCコントロールを追加する
バージョン管理を追加する
CruiseControl.NETを使って、ビルドプロセスを監視および管理する

何らかの変更があった場合に、ビルドをトリガーする
ビルドの最終結果を電子メールまたはWebレポートでビルドマスターに伝える

　本稿では、ここで取り上げた概念や使用ツールに関する詳細な説明はしません。本稿は、今出回っている各種のツールをどう組み合わせればよいかを示す、技術的なサンプルの1つとして役立ててもらうために執筆したものです。各種のツールを組み合わせることもまた、サンプルでしかありません。ここで使用したツールはどれも多様なオプションを備えており、なかにはまったく使わないものもあるかもしれません。これらの製品1つ1つのヘルプをじっくりと読み、創意工夫を凝らして自分のビルドプロセスに役立ててください。

概要

　ビルドプロセスの主な目的は、アプリケーションを作成することです。ビルドプロセスでは、アプリケーションの部品をすべて集め、展開可能なパッケージを作成する必要があります。このプロセスを独立させることにより、信頼性と予測性の両方が向上します。

　また、ビルドプロセスでさまざまな自動処理を行うためのツールが数多く登場しています。チーム開発環境におけるビルドプロセスでは、一般には無数の開発者からコードを集めます。そのため、ビルドの際に、ユニットテストやドキュメントの作成を一度に行うことができれば理想的です。これらの作業をビルドで自動化すれば、コードの品質が上がるうえに、開発者の作業を省くことができます。

　さらに、ビルドを追跡し、ビルドプロセスについてのレポートを作成する機能も実装できます。チェック処理をトリガーするようソース管理で設定しておけば、何か所定の変更を加えてから数分以内に、ユニットテストの結果を電子メールで受け取ることができます。これにより、開発者は変更にすばやく対処できると同時に、その変更のことを意識し続けることができます。

　レポートには、コーディング標準との比較チェックの結果も含まれます。これによって、コードのレビュー時には、標準への準拠を気にすることなく、コードそのものに集中することができます。

　以下は、本稿で使用するパッケージです。それぞれのパッケージと、それらの使い方について、手短に説明します。

NAnt

　実際のビルドプロセスを作成する上で利用するプラットフォームです。NAntは、Ant for Javaをモデルとして作られたオープンソースパッケージです。本稿では、NAntは実際のビルドを引き受けるだけでなく、ビルドプロセス中に実行されるタスクのトリガーも行います。

NAntContrib

　NAnt用のアドオンタスクのコレクションであり、NAnt同様にオープンソースパッケージです。NAntContribはvss、gac、ngenに関するタスクを追加し、それ以外にも便利なタスクを数多く追加します。本稿ではNAntContribを、VSSとの通信に使用します。

NUnit

　NUnitは、オープンソースの.NET用テスティングフレームワークで、JUnit for Javaをモデルとして作られたものです。NUnitを使えば、開発者はアプリケーションのテスト設備（テストフィクスチャ）を用意し、ユニットテストを書くことができます。NUnitにはGUIとコマンドラインツールの両方が含まれているほか、アセンブリをテストする際に追加できる、さまざまな属性が備わっています。本稿ではNUnitを、クラスライブラリを対象としたユニットテストに使用します。

NDoc

　NDocは、VisualStudio .NETのXMLドキュメンテーションファイルや、VBCommentorなどのパッケージからAPIドキュメンテーションを作成するオープンソースのパッケージです。NDocを使えば、ドキュメンテーションを作成する際にさまざまなオプションを選べるほか、GUIとコマンドラインのどちらにするかを選ぶこともできます。本稿ではNDocを、アプリケーションのHTMLとchmドキュメンテーションの作成に使用します。

CruiseControl.NET

　CruiseControl.NET（以下、「CCNet」）は、CI（Continuous Integration：連続的な統合）やビルドプロセスのレポートに使われるオープンソースのパッケージです。「CI（連続的な統合）」とは、新しいファイルを入手するたびに新しいビルドを作成するという慣習を指し、これによって絶え間ないビルドプロセスが生み出されます。「ユニットテストのような作業はビルドプロセスに含める」という前提ならば、連続的な統合／継続的な統合によって、開発チームはバグを非常にすばやく発見し、修正できます（もちろん、ユニットテスト内で十分にカバーされている範囲内ならばの話です）。本稿ではCCNetを、ビルドプロセス中にトリガーとレポートを実行するために使用します。

FxCop

　FxCopは、Microsoftがコーディング標準を施行するために配布しているパッケージです。FxCopを使用すると、コードを分析し、そのコードがコーディング標準を守っているかどうかを調べるプロセスが自動化されます。これにより、同僚によるレビューセッションでは、大文字小文字の区別や命名規則違反といった問題のチェックに時間を費やすことなく、コードそのものに集中することができます。本稿ではFxCopを、アプリケーション内のコーディング標準の分析に使用します。

Visual Source Safe

　Visual Source Safe（以下「VSS」）は、Microsoftが配布しているソース管理パッケージです。一般に、VSSはVisual Studio .NETを使うときのソース管理（ソースコントロール）に使われています。VSSは非常に入手しやすく、広く使われているため、本稿でもVSSを使いますが、NAntファイル内の要素をいくつか変更すれば、本稿で紹介する概念は他の大部分のソース管理システムにも当てはまります。

ビルド環境のセットアップ

　簡単な方法

サンプルの「BuildSolution.zip」を「c:projects」に展開
サンプルの「devtools.zip」を「c:devtools」に展開

　これで、準備は万端です。まず必要なのは、これらのツールをインストールすることです。これらのツールは、（必須ではありませんが）たとえば「c:DevTools」のような場所にまとめておくことをお勧めします。

　本稿では、さまざまなパッケージをまとめたdevtools.zipを用意していますが、ここでこれらのツールをインストールし、適切に設定する必要があります。このzipファイルを「c:devtools」に展開すると、サンプルを見ることができます。手順は次のとおりです。

パッケージのインストールと展開

NAntをダウンロードし、「c:devtools」に展開します。
NantContribをダウンロードし、「c:devtools」に展開します。
nunitをダウンロードし、「c:devtools」にインストールします。
NDocをダウンロードし、「c:devtools」にインストールします。
FxCopをダウンロードし、「c:devtools」にインストールします。
CCNetをダウンロードし、「c:devtools」に展開します。

NAntContribをNantに追加する

「c:devtools antcontribin」にあるファイルをすべて「c:devtools antin」にコピーします。

ソリューションのビルド

　ビルド環境のセットアップが終わった後は、ビルドする対象が何か必要です。ここではまず、WinFormsというアプリケーションと、クラスライブラリを1つ作成しましょう。ここで、今回はC#を使うことにしました。この言語には、XMLのコメント機能が組み込まれているからです。VB .NETを使っている場合でも、便利なパッケージがいくつかあります。VBCommenterとVB.DOCをよく調べてみてください。

　一貫した命名システムを使い、すべてのソリューションが「c:projects」ディレクトリにあり、個々のプロジェクトがソリューションディレクトリ内の、それぞれのサブディレクトリにあるという状態を保ってください。こうすれば、ファイル構造は次のようになります。

C
+-- projects
    +-- ソリューション
        +-- プロジェクト1
        +-- プロジェクト2

ソリューションの作成

VS .NETを開き、BuildingSolutionという名前で新しいソリューションを「c:projects」に作成します。

プロジェクトの作成

BuildingUIという名前で、新しいC#のWindowsFormsプロジェクトをソリューションに追加します。
BuildingBLという名前で、新しいC#のクラスプロジェクトをソリューションに追加します。

コードの追加

　今回は、単純なコードをいくつか組み込んだサンプルプロジェクトを用意しました。そのコードの重要な部分は、本稿の後半で取り上げます。

　ここでは、人（Person）を表す次のようなクラスを追加しました。

　このクラスを利用する、シンプルなWinFormsアプリケーションを作成します。XMLのコメントを追加しておくのも忘れないでください。この「XMLのコメント」が後で重要になってきます。いずれにせよ、コメントはXMLで残すよう習慣付けておくほうがよいでしょう。

最初のビルドファイルを作成し、ビルドする

　簡単な方法

DOSプロンプトを開き、「c:ProjectsBuildingSolution」に移動
「c:devtools antin ant.exe -buildfile:firstbuild.guild.xml」を実行

　次のステップは、最初のビルドファイルの作成です。まず、NAntヘルプサイトから起動スクリプトを入手し、設定の一部をデフォルトから変更します。「BuildingSolution1.build」ファイルに目を通し、ビルドファイル全体を確認してください。

　NAntファイルの編集にVS .NETを利用している人は、NAnt固有のインテリセンス（intellisense）をIDEに追加しておくと便利です。そのためには、「c:devtools antschema」から.xsdファイルをコピーし、それを「c:Program FilesMicrosoft Visual Studio .NET 2003Common7Packagesschemasxml」に貼り付けます。

　次は、ソリューションディレクトリ内でビルドファイルを作成し、ソリューション名を付けて「.build」という拡張子を追加します。このファイルをVS .NETで開きます。このビルドファイルのプロパティウィンドウでNAntスキーマを選ぶことができます。これで、インテリセンスが有効になります。

　次は、ファイルに次のような変更を加えます。

Solution.Filename用に新しいプロパティを作成し、それをソリューションのファイル名とします。
ビルドタスクを、cscタスクではなく、ソリューションタスクを使うように変更します。ソリューションタスクではソリューションファイルが分析され、正しい順序でプロジェクトがビルドされ、適切な参照がセットアップされます。

「FirstBuild.Build」の内容

<?xml version="1.0"?>
<project name="BuildingSolution" default="build" basedir="."
       xmlns="http://nant.sf.net/schemas/nant-0.85.win32.net-1.0.xsd">
    <description>
        This is a sample build file to be used for the
 BuildingSolution sample
    </description>
    
    <!-- ********** -->
    <!-- Properties -->
    
    <!-- Solution.Filename represents the filename of
         the solution to build -->
    <property name="Solution.Filename"
        value="C:projectsBuildingSolutionBuildingSolution.sln"/>
    <property name="Solution.Configuration" value="DEBUG"/>
    <property name="Build.OutputFolder"
        value="c:uildsuildingsolution"/>
    <!-- End Properties -->
    <!-- ******* -->
    <!-- Targets -->
    <!-- Clean target will delete the current version -->
    <target name="clean" description="remove all generated files">
        <delete>
            <fileset basedir="${Build.OutputFolder}Latest">
                <includes name="*.*"/>
            </fileset>
        </delete>
    </target>

    <!-- build will trigger main build -->
    <target name="build" description="compiles the source code">
        <call target="clean"/>
        <solution solutionfile="${Solution.Filename}"
                  outputdir="${Build.OutputFolder}latest"
                  configuration="${Solution.Configuration}"/>
    </target>
    <!-- End Targets -->

</project>

　では、DOSプロンプトに戻り、ビルドファイルのあるディレクトリに移動してください。「c:devtools antin ant.exe -buildfile:firstbuild.build.xml」と入力すると、最初のビルドが始まります。できあがったビルドプロダクトは、「c: buildsuildsingsolutionLatest」ディレクトリにあります。

Visual Studio .NETを使ってテストプロジェクトをビルドする

　これでビルドプロダクトが1つできましたが、このビルドプロダクトを使ってできることは、想像以上にたくさんあります。それぞれのビルドを使ってできる中で最も重要なのは、ユニットテストを実行できることです。NAntを使えば、NUnitテストの実行を非常に簡単に統合することができます。ただし、まずテスト用の設備（テストフィクスチャ）をいくつか用意する必要があります。

ソリューション内で新しいクラスライブラリを作成し、「BuildingTest」と名前を付けます。
「c:devtools unitin unit.framework.dll」へのファイル参照を追加します。
BuildingBLへのプロジェクト参照を追加します。

　ユニットテストを書くと、ソフトウェア開発者はアプリケーションのさまざまな部分をテストする予防的な手段を実現できます。ユニットテストの結果を調べれば、システムのある部分に加えた変更が、システムのどこかほかの部分に影響を及ぼしていないかどうかを、迅速かつ簡単に判断することができます。正確なテストを行い、コードの品質を高く保てば、ユニットテストの効果が大幅にアップします。ユニットテストを統合する際の方針を計画する場合は、このことを念頭に置いておいてください。

　では、そろそろ何かコードを書きましょう。まず、クラスに[TestFixture]属性を追加します。次に、パブリックメソッドをいくつか追加し、[Test]属性を使ってそれぞれのメソッドにマークを付け、クラスのさまざまな面をテストします。これらのシンプルなメソッド1つ1つがクラスのいくつかの面をテストし、それらがすべて成功したら、テストは合格です。本稿で用意したサンプルコードには、サンプルテストも含まれています。

　クラスの外見は、次のようになります。

　これで、何かの処理を実行するクラスと、その処理の内容をテストするクラスが作成されたことになります。次は、テストの実行です。NUnitにはテストを実行するためのGUIが用意されています（GUIは、「c:devtools unitin unit-gui.exe」です）。このツールを使えば、開発者は独自の個別テストを実行することができます（通常は、何らかのコードをより大きなプロジェクトにチェックインする前の時点で行います）。

　しかし、ビルドプロセスではこれらのテストをビルド時に実行できます。ビルド時というのは、プロジェクトのすべての部品が統合されているかどうかをテストするには最適なタイミングです。NAntには、NUnitをより簡単にビルドに追加するためのNunit2タスクが用意されています。

<!-- runUnitTests will run the nunit task on the test dlls -->
<target name="runUnitTests"
        description="Runs unit tests on specified dlls">
    <nunit2 failonerror="false" verbose="true">
        <formatter outputdir="${Build.OutputFolder}Latest"
                   usefile="true" type="Xml" extension=".xml"/>
        <test>
            <assemblies basedir="${Build.OutputFolder}Latest">
                <includes name="*Test.dll"/>
            </assemblies>
        </test>
    </nunit2>
</target>

　$変数はそれぞれ、上記のプロパティとして定義されています。<Nunit2はNUnitタスクを開始し、<formatterはNAntに対し、NUnitの出力をどう処理すべきかを指示します。この場合は、XMLフォーマットを指定しています。最後に、<testと<assembliesの各タスクは、テスト対象ファイルの処理を指定します。ここには、「*Test.dll」に一致するDLLファイルがすべて含まれます。

　これで、このビルドファイルを実行すると、ビルド済みプロジェクトができあがるだけでなく、ユニットテストの結果を伝える新しいXMLファイルも作成されます。この時点で、そのXMLファイルを利用し、おそらくはXSLTを使ってレポートを出したり、XMLを何らかのログにインポートできるようになっていますが、当面はその部分に触れずにおきます。このファイルを使ってできることについては、後でまた詳しく説明します。

FxCopを使ってビルド中にコーディング標準の妥当性を確認する

　簡単な方法

DOSプロンプトを開き、「c:ProjectsBuildingSolution」に移動
「c:devtools antin ant.exe -buildfile:secondbuild.build.xml」を実行

　コードのレビューは、開発するプロジェクトの規模を問わず、非常に重要な作業です。コーディングの標準に準拠していることは重要ですが、コードをレビューする時間を使って標準への準拠をチェックし、準拠を強制するというのは厄介です。MicrosoftのFxCopを使えば、コーディングの標準に準拠するための時間を大幅に節約することができます。これにより、開発者はコードのレビューに専念でき、CamelとPascalにおける大文字小文字の区別などを論じる必要はなくなります。

　最初のステップは、FxCopを開き、FxCopファイルを1つ作成することです。

FxCopを開きます。
［Project］、［Add Targets］の順にクリックします（または［Ctrl］＋［Shift］＋［A］キーを押します）。
ダイアログボックスで「c:uildingsolutionLatestuildingbl.dll」に移動します。
［file］、［save］、［save as c:projectsuildingsolutionuildingsolution.fxcop］の順にクリックします。

　こうすると、デフォルトのFxCop標準と突き合わせて妥当性を確認するためのFxCopファイルが1つ作成されます。FxCopは非常に柔軟で、開発者独自のコーディング標準に合わせてルールをカスタマイズすることもできます。

　これで、FxCopがビルドに追加できるようになりました。この時点では、NAntにはFxCop用の具体的なタスクがありませんが、<execタスクを使えば、FxCopをたやすくビルドに追加することができます。

<!-- runFxCop will run the fxcop file of the same name as
     the nant project -->
<target name="runFxCop">
    <exec program="c:devtoolsxcopxcopcmd.exe" 
        commandline="/p:${nant.project.basedir}${nant.project.name}
.fxcop /o:${Build.OutputFolder}Latestxcop-results.xml"
        failonerror="false"/>
</target>

　<execタスクを使えば、任意のコマンドラインアプリケーションを実行し、出力を集めることができます。この例では、FxCopのコマンドラインバージョンである「fxcopcmd.exe」を実行しています。テスト対象のDLLと、出力先となるXMLを用意してください。繰り返しますが、このファイルは後ほど重要になってきます。

APIドキュメンテーションの作成

　簡単な方法

DOSプロンプトを開き、「c:ProjectsBuildingSolution」に移動
「c:devtools antin ant.exe -buildfile:thirdbuild.guild.xml」を実行

　ビルドプロセスによって、APIドキュメンテーションを作成するための魅力的な場所ができあがります。この機能は、NAntとNDocの両方に、直接組み込まれています。ドキュメンテーションをビルドごとに作成するのは、プロジェクトによっては適切ではない場合があります。ドキュメンテーションをいつ作成するかについても、各種のルール（たとえば「リリースビルドのみ」など）をたやすく適用することができます。

　C#のプロジェクトでは、コンパイラがビルド時にXMLドキュメンテーションを抽出することができます。このためには、BuildingBLプロジェクトの設定プロパティをチェックしてください。すると［XML Documentation Filename］というプロパティが見つかります。本稿に付属のプロジェクトでは、このプロパティを「BuildingBL.xml」に設定します。

　一方、VB .NETの開発者は、同じドキュメンテーションを作成するために、もう少し多くの手順を実行する必要があります。VB.DOCやVBCommentorのようなパッケージを使えば、同じAPIドキュメンテーションの生成を適用することができます。

　本稿で使用しているXMLファイルは、VS .NETでコンパイル時に生成されたものです。その設定をプロジェクトファイル内で指定すれば、NAntでもXMLファイルを使ったソリューションをビルドすることができます。しかし、ビルドごとにXMLドキュメンテーションを使うと、通常よりもビルドが低速になります。そこで、いくつかのオプションを調べてみましょう。1つは、ソリューションタスクの代わりにcscタスクを使うというもので、このオプションを使えば、doc引数を渡すことができます。もう1つは、xmlpeekとxmlpokeを使ってprojファイルを変更し、XMLドキュメンテーションのファイル名を指定するというものです。xmlpeekの探索（poke）タスクを使えば、XPath式を供給したり、XMLファイルから値を読み出すことができます。xmlpokeはその反対の処理を行い、ビルド時にXMLドキュメントを追加することができます。

　プロジェクトを「F5ビルド」してもXMLファイルが生成されるため、ビルド時のドキュメンテーション作成は簡単です。実際、NDocタスクは丸ごとNAntドキュメンテーションからコピーされたものです（ちなみに、このドキュメンテーションは非常に良質です）。

<!-- runCreateDocumentation will create msdn type documentation
     for the building solution -->
<target name="runCreateDocumentation"
        description="Will create documentation for Buidling Solution">
    <ndoc>
        <assemblies basedir="${Build.OutputFolder}Latest">
            <includes name="BuildingBL.dll" />
        </assemblies>
        <summaries basedir="${Build.OutputFolder}Latest">
            <includes name="BuildBL.xml" />
        </summaries>
        <documenters>
            <documenter name="MSDN">
                <property name="OutputDirectory"
                          value="${Build.OutputFolder}Latestdoc" />
                <property name="HtmlHelpName"
                          value="BuildingSolution"/>
                <property name="HtmlHelpCompilerFilename"
                          value="hhc.exe" />
                <property name="IncludeFavorites" value="False" />
                <property name="Title" value="BuildingSolution"/>
                <property name="SplitTOCs" value="False" />
                <property name="DefaulTOC" value="" />
                <property name="ShowVisualBasic" value="True" />
                <property name="ShowMissingSummaries" value="True" />
                <property name="ShowMissingRemarks" value="True" />
                <property name="ShowMissingParams" value="True" />
                <property name="ShowMissingReturns" value="True" />
                <property name="ShowMissingValues" value="True" />
                <property name="DocumentInternals" value="False" />
                <property name="DocumentProtected" value="True" />
                <property name="DocumentPrivates" value="False" />
                <property name="DocumentEmptyNamespaces"
                          value="False" />
                <property name="IncludeAssemblyVersion"
                          value="False" />
                <property name="CopyrightText"
                          value="iceglue for .net" />
                <property name="CopyrightHref"
                          value="http://www.iceglue.com" />
            </documenter>
        </documenters> 
    </ndoc>
</target>

　<ndoc>タスクでは、まず「どのDLLファイルとXMLファイルを使用するか」を指定する必要があります。まとまった複数のドキュメンテーションを作成する必要がある場合は、その旨をループ内で指定することができます。そうすると、長大なプロパティリストができあがります。これらのプロパティについては、NDocのリファレンスで詳しく説明されています。このリストによって、MSDNスタイルのchmファイルが、ビルドフォルダ内の/docディレクトリに作成されます。

VSSソースコントロールにソリューションを追加する

　簡単な方法

DOSプロンプトを開き、「c:ProjectsBuildingSolution」に移動
「c:devtools antin ant.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）。これで、ソース管理にすべてを含めることができました。

図1

図2

図3

図4

　次のステップは、ビルドファイルに最新のソース管理を取得させることです。NAntと組み合わせれば、NAntContribもあることになります。NAntContribはNAnt用アドインのコレクションで、本稿ではNAntContribに付属の<VSSを使います。ビルドファイルが最新のソース管理を取得するよう変更するには、単にvssgetを呼び出すだけのrunGetLatestターゲットを1つ追加する必要があります。

<target name="runGetLatest">
    <vssget
        user="user"
        password=""
        localpath="C:ProjectsBuildingSolution"
        recursive="true"
        replace="true"
        writable="false"
        removedeleted="false"
        dbpath="HustlerVSSsrcsafe.ini"
        path="$/BuildingSolution"
    />

　vssgetタスクは、実にシンプルです。パスワードが空白になっている点に気付いたでしょうか。これは、この環境にはパスワードが必要ないためです。本稿では、NAntは必ず「このユーザーはVSSデータベースへのアクセス権を持っている」という前提を持った、対話的なユーザーコンテキストから呼び出されています。このためには、ビルドマシンに常にログインしている必要があります。それを回避するには、CCNetの中でサービスとして実行される部分を調べ、ビルドファイルに適切な変更を加えてパーミッションを処理するようにします。

バージョン管理の追加

　簡単な方法

DOSプロンプトを開き、「c:ProjectsBuildingSolution」に移動
「c:devtools antin ant.exe -buildfile:fifthbuild.guild.xml」を実行

　このサンプルビルド環境では、非常にシンプルなバージョン管理メカニズムを使います。本稿の目標は、個々の順次ビルドを、それぞれ対応するビルドフォルダに格納することです。ビルドシステムを使ったバージョン管理については、たとえば「ソース管理におけるラベリング」や、「アセンブリにバージョンを付ける方法」、「GAC」、「割り当て可能なさまざまなバージョン」など、本稿とは完全に別のトピックとなる可能性があるため、説明を割愛します。このツールセットでは、非常に洗練されたバージョン管理システムをサポートできるため、想像力しだいでどのようにも活用できます。

　バージョン管理をシンプルに保つために、NAntContribでは<versionタスクを使います。まず、「c:projectsuildingsolution」ディレクトリに「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:devtoolsccnetserviceccnet.config」を編集し、コメントを付ける箇所を変更
「StartCCNet.bat」をダブルクリック

　これで、何らかのユニットテストの結果をもとに自らの寿命を追跡する、反復が可能なビルドプロセスが出来上がったことになります。本稿の次のセクションでは、これらのテストや、ビルドの残り部分を追跡し、レポートするのがどれほど簡単かを説明します。CruiseControl.NETを起動してください。

　CCNetは、CI（Continuous Integration：連続的な統合）に使われます。CIとは、コードを絶え間なく統合するための一連の概念です。つまり、ソース管理は常に監視され、ファイルがチェックインすると、それがきっかけとなってビルドが実行されます。これにより、開発者は自分の行った変更の結果をチェックインから数分で知ることができるほか、そのコードに戻るのも非常に簡単です。

　また、CCNetはビルドのレポートと追跡、ユニットテストもサポートしており、さまざまな手段を介してFxCopを利用することができます。

　CCNetは、VSSとビルドを監視し、ビルドの結果をレポートおよび追跡するために使用します。このためには、CCNetの一部を設定する必要があります。まず、ビルドを監視し、ビルドを初期化するサーバーインスタンスを設定する必要があります。Webレポートを有効にしたい場合は、IISで仮想ディレクトリも設定する必要があります。また、ビルドをHTMLの電子メールで追跡したり、ビルドの通知をSysTray通知アプリケーションから受け取ることもできます。

　CCNetを展開したら、いくつかのファイルをソリューションに合わせて更新する必要があります。「c:devtoolsccnetserver」フォルダの中に、「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:devtoolsccnetweb」をポイントする仮想ディレクトリを設定する必要があります。このためには、「c:devtoolsccnet」まで移動し、Webディレクトリを右クリックします。[Web sharing］タブを選び、「ccnet」という名前でフォルダを共有します。

　この設定が完了したら、ブラウザを起動してhttp://localhost/ccnetにアクセスしてみてください。最初のビルドの結果が表示されているはずです。これで、CCNetがFxCopやユニットテストの結果を収集していることがわかります。また、この情報は、「ccnet.config」ファイルで指定したアドレスに電子メールで送信されます。これにより、「ビルドプロセスが中断したら通知される」という、アクティブなビルドプロセスが実現されます。個々の開発者は自分の持ち場で作業し、自分が書いたシステムの部分を対象にユニットテストを書いておけば、実行すべきテストがチェックイン時にすべて実行されます。このことを、統合テストを処理するユニットテストと組み合わせれば、ほんの些細な変更がトリガーとなって、テストがなだれのように失敗する可能性があります。これらのテストは、コードがチェックインしてから数分以内に失敗する可能性があるため、開発者にとっては、問題の発見と修正がより簡単になります。

　CCNetのWebサイトでは、FxCopの結果を表示することもできます。プロジェクトページの右上側には、FxCop画面へのリンクがあります。また、CCNetでは、無数のCCNetサーバーアプリケーションを集中管理するためのポイントとなる、「ダッシュボードサイト」が用意されています。CCNetには豊富なオプションが用意されているので、詳細は添付のドキュメンテーションを参照してください。

注

　本稿の執筆後に、CCNetの新バージョンがリリースされました。新バージョンのCCNetでは、ソースをソース管理から取得するタスク、それにビルドテストやユニットテストといった、実際にアプリケーションをビルドするための新機能がいくつか導入されています。実際のビルドで使用するにはNAntのほうがはるかに柔軟ですが、NAntで提供される一部の高度な機能を利用しないならば、CCNetをビルドプロセスに利用したり、CIやレポートエンジンを活用するという方法も考えられます。

おわりに

　本稿では、独自のビルド環境を構築する際に利用できる一連のツールについて概要を述べました。ここで取り上げたサンプルはごく基本的なものですが、ビルドに関する重要ないくつかの側面を概説しています。おわかりのとおり、ビルドプロセスは、単に［F5］キーを押すだけの作業ではありません。「ユニットテストに関するレポートの自動化」や、「コードのレビュー支援」、そして「ビルドの信頼性の向上」は、ビルドプロセスを入念に設計した場合に得られる利点の一部に過ぎません。そして、本稿で説明したツールを使えば、信頼性と実現力は大幅に向上します。

著者紹介

Aaron Junod（Aaron Junod）

ソフトウェア開発とハードウェアアーキテクチャの分野で多様なバックグラウンドを持つベテランソフトウェア開発者で、ユーザーのプロジェクトから、100万ユーザーを超えるプロジェクトまで、幅広く携わっている。現在は、従業員の福利厚生に特化したトランザクション処理会社のソフトウェア設計者として、また開発者として活動中。Microsoft Certified Professionalでもあり、保険業界や人材派遣業界のソリューション設計に携わった経験がある。彼の詳細を知りたい場合、ならびに連絡を取りたい場合は、http://blog.iceglue.comまで。