Blog

11/4(金)に開催された、TFS勉強会に参加しました。
（登壇者のご紹介はこちらにて。）

登壇者のリストを見て「これは参加しないと」と思い、少し強引にスケジュールを調整したのですが、やはり内容の濃い勉強会でした。

○中村さんのセッション
　Trac+SVNからTFSへの移行についてでした。
　・アンケート：勉強会の参加者の2/3ぐらいがTFS利用者
　・チケット移行はExcelを使用
　　TracもExcel使えるんだぞと。
　・TFSは各管理情報の連携が簡単にできる
　・日本語の情報があまりないのが残念（英語ならたくさんある）
　・実際のセッションがスライドに組み込まれた想定時間通り
　・CI（継続的インテグレーション）できないと生きていけないらしい

○りばてぃさんのセッション
　ウォーターフォール(WF)開発でのTFS活用についてでした。
　・既存のプロセス／生成物を変更されると嫌がる方々がいらっしゃる
　　なので、TFSにプロセスを合わせるのではなく、プロセスにTFSを合わせる（使えるところだけ使う）
　・TFSの機能をちゃんと理解していないと、プロセスに合わせるのは難しい
　・TestManagerの受けがいいらしい
　・Excel使える

○柴山さんのセッション
　分散アジャイル開発でのTFS活用についてでした。
　・Innovation Sprint2011実行委員長だった@kawagutiさんの頭だし
　・ＴＯＣ厨／プロセス厨
　・詳細はBlog／SlideShare等々
　・「流れないウォーターフォール」
　・某ガンダムのタイトル流用
　・プロジェクトの改善内容について、惜しげもなく公開
　・「Continuous Delivery」
　・ツールとアナログは対立するものではなく、組み合わせて使うもの

お一人当たり３０分ぐらいだったので、「さらっ」とお話されていましたが、とんでもないことを実行されているのがよくわかりました。

あと、全体的に感じたことは
　・ツールを使うだけでは改善できない。何を改善したいかを見失わないこと。
　・TestManager万歳
　・プロジェクトにかかわる人の意識を共有することが重要
　・某ガンダムはやはり名作ｗ
といったところです。

このお三方、ALM Summitにも参加されるとのことで、お土産が12/10(土)の第２回TFSユーザーズ勉強会でお話ししていただけるとのこと。自腹切ってでも行きます！

あと、書籍「Team Foundation Server入門」頂きました。
じっくり読んでみたいけど、地元の勉強会にも出してみたいし、悩みます( ´･ω･`)

最後に、FindBugsの実行結果をリンク先として指定してみます。

「TFSでのJavaビルド環境作成：FindBugsの実行」 で、FindBugsの実行結果をビルド出力フォルダに出力するように指定していますので、同じパスを指定すれば問題ないと思ってましたが、なぜかフォルダ指定を変えないと正しく参照してくれません。
（おそらく、ビルドプロセス実行中に変数内容が適宜変更されていると思われます）

またまたビルドワークフローを開き、WriteExternalLinkのリンク先として「BuildDetail.DropLocation + "\findbugs-result.html"」を指定します。

AntのBuild.xmlで指定したのは「${DropLocation}/${BuildNumber}」でしたので、「${BuildNumber}」が不要になっています。

修正を保存／チェックインして、再度ビルドを実行します。

FindBugsの実行結果がエディタで開かれました^ ^;

Eclipseではこうなります。

おまけですが、html形式で出力するとVS IDEではうまく参照できない（エディタが起動され、状態によってはソースが表示される）ので、Eclipseの兼用となるとtxt形式しか選択肢がないように思われます。

これでビルド結果画面でFindBugsの実行結果が参照できるようになりました。
いろんなものと連携させる際には使えるネタかと思います。

まずは、ビルドサーバに適当なファイルを作成します。
クライアントから参照できないと意味がないので、ビルドサーバの共有フォルダ直下（ここでは「E:\JavaBuildWork」→「\\build2008r2\JavaBuildWork」）に作成します。

VS IDEでビルドワークフローを開き、先ほど登録したアクティビティを追加します。

修正を保存／チェックインし、ビルドを実行してみます。
ビルド結果に「ファイルへのリンク」が表示され、リンクをクリックするとリンク先が表示されます。

Eclipseからでも同じように参照できます。

たぶん次が最後ですが、FindBugsの実行結果をリンク先にしてみたいと思います。

ビルドワークフローを編集する端末でビルドプロセステンプレートファイルを開きます。ツールボックスの「全般」タブで右クリックし、「アイテムの選択」を選択します。

アイテムの選択画面で、「System.Activitiesコンポーネント」タブにある「参照」ボタンを押します。

インストールしたアセンブリ(dll)を選択するのですが、「C:\Windows\Microsoft.NET\assembly\GAC_MSIL」に、「CustomActivities」フォルダがあり、その中にあるわけのわからない名前（バージョン番号＋公開キートークン）になっているフォルダ内のdllファイルを選択します。すると、ツールボックスに「WriteExternalLink」が表示されます。

次に、これを使って、適用なファイルへのリンクを出力するようにワークフローを変更します。

カスタムアクティビティのプロジェクトのプロパティを開き、「署名」タブを選択します。

「アセンブリの署名」をONにし、キーファイルの選択から「＜新規作成…＞」を選択します。

作成画面で「キーファイル」にファイル名を指定します。ここでは「キーファイルをパスワードで保護する」をOFFにしておきます。（他にも展開するのであれば、ちゃんとパスワード指定した方がよいかと思います）

この状態で、カスタムアクティビティのプロジェクトを一旦ビルドし、次にセットアッププロジェクトのビルドを行うとセットアッププログラムが正常に作成できます。

このセットアッププログラムを使って、ビルドワークフローを編集する端末とビルドサーバにアクティビティをインストールします。
なお、インストール後にビルドサービスの再起動を行わないとちゃんと認識してくれません。

次は、インストールしたアクティビティをVS IDEに登録します。

作成したアクティビティを使うためには、
　・VS／TFSが参照するフォルダにdllが格納されていること
　・グローバルアセンブリキャッシュ(GAC)に登録されていること
が条件になります。（詳細については「Customize Team Build 2010 – Part 7: How is the custom assembly found?」）

参考にさせて頂いた「C#.NETでいく？　TFS2010ビルド テンプレートのカスタマイズ（3）」とか「Ewald Hofman Customize Team Build 2010 – Part 7: How is the custom assembly found?」では、ビルドコントローラーに対してカスタムアセンブリを参照させる方法で解決していますが、複数のカスタムアセンブリを使いたくなった時にややこしくなるのが嫌だったので、ここではセットアップを作成して登録する方法をとります。

ソリューションに対して、セットアッププロジェクトを追加します。

自動的にエディタが起動されますので、「対象コンピュータのファイルシステム」を右クリックし、「特別なフォルダーの追加」－「グローバルアセンブリキャッシュフォルダ」を選択します。

GACに登録するファイルとして、プロジェクトでビルドされたファイルを指定します。

次は、セットアップ時の動作を少しだけ変更します。
通常、セットアップ実行時に「このユーザーのみ」と「すべてのユーザー」という選択肢が表示されますが、アクティビティはユーザ単位で使う／使わないというコントロールはしない（はず）ので、必ず「すべてのユーザー」でインストールするように変更します。
セットアッププロジェクトを右クリックし、「表示」－「ユーザーインターフェイス」を選択します。ユーザーインターフェイスのエディタ画面で、「インストール」－「開始」－「インストールフォルダー」のプロパティにある「InstallAllUsersVisible」をTrueに変更します。

ここで、セットアッププロジェクトをビルドすると、こんなエラーになってしまいました。

すっかり忘れていましたが、GACに登録するアセンブリは、厳密名を持っていないと登録できない仕組みになっています。（いわゆる「DLL Hell」の解決）

これはちゃんと対応しないといけないので、厳密名をアセンブリに付与します。

自分で機能拡張できるのもTFSのいいところということで、カスタムアクティビティを作成してみます。
主要なところ（というか、ほぼ^ ^;）は、「C#.NETでいく？　TFS2010ビルド テンプレートのカスタマイズ（1）」以降と「Ewald Hofman Customize Team Build 2010 – Part 1: Introduction」以降を参考にさせて頂きました。

VSで新規プロジェクトを作成します。テンプレートから「アクティビティ ライブラリ」を選択します。

プロジェクト作成後、TFSのライブラリ（Microsoft.TeamFoundation.Build.Client）を追加します。

次に、プロジェクトにWorkflowテンプレートからコードアクティビティのクラスを追加します。

詳細は割愛させて頂いて、以下のようなソースに変更します。


変更概要としては
　・Microsoft.TeamFoundation.Build.Clientを参照追加
　・クラス属性として「[BuildActivity(HostEnvironmentOption.All)]」を追加
　　→これを指定しないと実行時にエラーになります
　・ワークフローで指定してもらうプロパティを追加する
　　最初の「BuildDetail」は、ビルド結果が格納されているオブジェクトになります
　・BuildDetailに対して、リンク形式の出力結果を追加する
　　AddExternalLinkについての詳細はこちら
という感じです。

一旦ビルドを実行し、エラーがなければワークフローにおいてみます。
プロジェクトにある「Activity1.xaml」を開き、ツールボックスの「CustomActivities」タブに「WriteExternalLink」があるはずです。これをワークフローエディタにドロップし、プロパティで３つの引数が指定できる状態であればOKです。

次は、作成したアクティビティを展開する方法についてです。

さて、WriteBuildMessageでビルド実行結果にメッセージを出力してみます。ツールボックスから、WriteBuildMessageをメッセージ出力したい場所にドラッグします。
今回は、「エージェントで実行」の中の、ビルド実行後に入れてみます。

プロパティで、「Message」に出力したいメッセージを"ダブルクォーテーション付き"で指定します。変更したら、保存→チェックインします。
チェックインまで完了したら、ビルドを実行してみます。
実行結果を確認してみると・・・・・・メッセージが出力されていません＞＜

いろいろネットを検索してみると、メッセージの重要度(Importance)を変更しないと出力されないようですので、設定内容を変更します。

初期値は「Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.Normal」なのですが、これを「Normal」から「High」に変更します。
（ここでもインテリセンスがきくのは流石です）

保存・チェックインしたあと、再度ビルドを実行して、結果を確認してみます。

ちゃんと出力されました。

単純なメッセージはこれで出力できるのですが、当初の目的であったリンク形式でのメッセージ出力はこれではできません。（他のアクティビティでもリンク先のURLを指定する項目はありません）

さて、どうしたものかと悩みましたが、ネットでいろいろ検索してみると、リンク形式でのメッセージ出力ができるカスタムアクティビティを作成している人がいました。
それをそのまま使わせていただこうかと思いましたが、せっかくなのでカスタムアクティビティの作成も行ってみようかと思います。

FindBugsの実行結果をビルド実行結果から参照するためには、ビルド結果メッセージを出力しないといけないはずです。

となると、「ビルドが終わったら」とか「FindBugsが終わったら」といったタイミングで出力することになりそうですが、どこでどうやったら可能なんでしょうか？？

TFSの場合、いろんな処理のフロー（ビルドプロセス）については、ビルド定義で指定されているビルドプロセステンプレートに定義します。
個別に処理を変更した場合には、テンプレートファイルを編集します。
編集例はMSDNのチュートリアル: カスタム ワークフローの定義と Team Foundation ビルドからのデータベースの配置にあります。

TFSのビルドプロセスは、ビルド定義にある「プロセス」で指定されています。

実体は、Windows Workflow Foundation(WF)用のXAMLファイルになっています。
XAMLファイルなので、テキストエディタでペシペシ編集すると想像してしまいますが、
なんと、WF用のエディタ画面があります！
ビルド定義画面で「バージョンコントロールパス」をクリックし、ソース管理エクスプローラーから、ビルドプロセスファイルに指定されているファイル（今回はUpgradeTemplate.xaml）をダブルクリックします。


なんということでしょう、ワークフローエディタ画面になるではありませんか。
ツールボックスにもたくさん入っています。

ビルド結果にメッセージを出力するための部品（アクティビティ）としては、
　・WriteBuildError
　・WriteBuildInformation<T>
　・WriteBuildMessage
　・WriteBuildWarning
の４つになります。

次は、ためしにWriteBuildMessageで単純なメッセージを出力してみます。

まずは、ビルドサーバにFindBugsをインストールします。
JDK／Antと同様、インストール先フォルダをシステム環境変数「FINDBUGS_HOME」に登録するのと、Antと連動させますので「findbugs-ant.jar」をAntのLibフォルダにコピーしておいてください。

次に、Ant用Build.xmlにfindbugs属性を追加し、チェックインします。

追加したのは
　・FindBugs実行用のtaskdef／property追加
　　findbugs.home指定のため、OS環境変数のFINDBUGS_HOMEを参照しています。
　　（${env.FINDBUGS_HOME}）
　
　・findbugs要素の追加
です。
※「${LogLocation}」がちゃんと設定されていれば、チェック結果の出力先(outputFile)が、「${DropLocation}/${BuildNumber}/findbugs-result.html」というややこしい指定にならないのではと思います。ちょっと調べてみると、前からずっとこの仕様(?)のようなのですが、M$さん、なんとかしてください<(_ _)>

ビルドを実行すると、FindBugsのチェック結果が出力されます。

ちゃんとFindBugsが実行されています。
とりあえず、共有フォルダを開けば実行結果も確認できます。

ただ、わざわざ共有フォルダを参照するのではなくて、ビルド実行結果から直接参照するのがスマートだと思いますので、次はビルド実行結果からFindBugsの出力ファイルをリンク参照できるようにします。