カテゴリー: TFS2012

明けましておめでとうございます。
つたないブログですが、本年もよろしくお願いします。<(_ _)>

ふとTFS2012のライセンス情報を確認しようとしたところ、2010の情報はよく出てくるんですが、2012についてはあまり出てこなかったので、ちょっとメモ代わりに作成します。
（出てこない理由として、ホワイトペーパー「Visual Studio 2012とMSDNのライセンス ホワイトペーパー」にきれいにまとまっているからかもしれませんが。）

まずは注意事項ですが、ここから以降の内容はあくまで個人的に関心のある内容を勝手にまとめたものですので、実際に導入される際には上記ホワイトペーパーおよびマイクロソフトへの問い合わせにて確認願います。

Lab Management関連は当面自分が使う予定がないので割愛させて頂きます（マテコラ

ここからはまとめたメモになります。
○サーバライセンス１つにつき、１台のサーバに割り当てることができる
　ここで「１台」の対象になるのは「アプリケーション層」です。
　SQL Serverとかビルドサーバを別サーバにインストールしても、アプリケーション層のインストールサーバが１台であれば、ライセンスは１つでよいということです。

○以下のソフトは「任意の数」の「コンピュータ」（サーバではない）で実行できます。
　・ビルドサービス
　・SharePoint Extensions
　・Project Server Extensions
　・チームエクスプローラー
　チームエクスプローラーが任意のコンピュータにインストールできるのは押さえてませんでした^ ^;

○SQL Server 2012 Standardの１インスタンスをTFS2012のＤＢとして使用可能（除くExpress）
　TFS 2012 ExpressはSQL Server 2012 Expressを使用するので対象外になります。

○上記SQL Serverライセンスを行使した場合、TFS2012のSQL Server Reporting ServicesはSQL Server CAL不要。
　TFSのレポートのみ利用するユーザは、TFS CALすら不要！

○MSDNライセンス（Professional以上）が付与されたユーザーが１人以上いる場合、VSをビルドサービスの一部としてインストール可能
　MSDNライセンスですのである意味当たり前ですが、「全員」ではなく「１人以上いる場合」というのが有難いなと思います。

○こんな使い方であればTFS CALは不要（但し、Windows Server CAL／SharePoint CAL／SQL Server CAL[TFS付属ライセンス以外で使用した場合]は必要）
　・作業項目の入力／表示／編集のみ
　・TFSのレポートにアクセスする
　・SCOM(System Center Operations Manager)を使用してTFSにアクセスする
　・Feedback Client for TFSを使用してTFSにアクセスする
　・TFSの外部に手動で頒布されて静的データを表示する
　・チームプロジェクトやプロジェクトコレクションの作成などのシステム管理を目的として最大２つまでのデバイスまたは２人までのユーザーがTFSにアクセスする

○TFS Web Accessの機能のうち、TFS CALだけでは使用できない機能
　・バックログとスプリントの計画ツール
　・フィードバックの要求と管理機能
　これらの機能を使用する場合、MSDNライセンス（Ultimate／Premium／Test Professional以上）が必要です。
　　※ProfessionalはNG
　　参考情報：MSDNの「Web アクセス許可による機能」
　　（この資料内で「フル」として割り当てできる機能が「TFS CALだけでは使用できない機能」）

○TEE(Team Explorer Everywhere)の「インストール」はライセンスフリー。
　接続ライセンスは今までの内容の通り。（VSとかからアクセスするのと変わらない）
　TFS Web Accessのフル機能を使用しないのであれば、TFS CALとWindows Server CALで使用可能。

といった感じのようです。

まとめた後の感想ですが、
　「Visual Studio 2012 Premium with MSDNサブスクリプション以上が欲しいw」

　TFS Web Accessのバックログとスプリントの計画ツールとかが使えるのはやはり大きいと思います。たとえアジャイル開発ではなくウォーターフォール開発だったにしても、作業状況をこれだけ容易に確認できる機能は使いたいです。
　さらに、VS自体の純粋な機能差も含めて考えるとPremiumがPremiumすぎます
！！
　
　仕事で購入を検討するのであれば、Premiumは選択肢として挙げるべきと思います。

　（でも、この前会社でProfessional購入したばっかりなんですよね．．．( ;∀;)）

「ALM Advent Calender」２２日目への参加記事になります。

以前に
・「１つのTFSプロジェクトで、.NETとJavaの共存は可能か？」
で、1つのチームプロジェクトでJavaと.NETプロジェクトのそれぞれに対してゲートチェックインを設定した場合の動作について記載しましたが、TFS2012 with Update1で改めて確認してみました。

今回、少しだけパワーアップして、
　・Native C++プロジェクト
　・C#プロジェクト
　・Javaプロジェクト
の3つを１つのチームプロジェクトとして登録し、それぞれのプロジェクト用にゲートチェックイン用のビルド定義を作成しました。

最初はC#プロジェクトでチェックインを実行します。


なぜか、ビルド定義の選択肢に「CI-Build-CPlus」がありません。
「CI-Build-CSharp」を選択して実行すると、正常にビルドが実行されました。

次にNative C++プロジェクトでチェックインを実行します。


今度はビルド定義の選択肢に「CI-Build-CSharp」がありません。
「CI-Build-CPlus」を選択して実行すると、こちらも正常にビルドできました。

最後にJavaプロジェクトでチェックインを実行します。

？？？、対象のビルド定義が「CI-Build-Java」のみです。
このまま実行すると、正常にビルドできました。

ということで、結論は「複数言語を使用した場合のゲートチェックインでも問題ない」ですが、ビルド定義の選択条件についてはよくわかりません。
→修正した（シェルブ対象となった）ファイルが格納されているフォルダと、その上位（親とか）のフォルダをビルド対象とするビルド定義が選択肢に上がっているような気がしますが、確認できる情報が見つかってません。

「ALM Advent Calender」１３日目への参加記事になります。

TFS2012とVS2012をUpdate1環境にしたところ、今までは怒られなかったビルドで警告が出てました。


「格納フォルダーをクロークする必要があります。」と出ています。
ちなみに、クロークは「除外」のことです。
除外しろと言われてもどこを．．．？？

とりあえず、メッセージに記載されているリンク先を参照してみます。
英語にページに飛びますが、右上の言語を「日本－日本語」に変更すれば日本語ページに移動できます。
すると、こんなことが書いてありました。


「必要なフォルダーをすべて含める」のはいいとして、「必要なフォルダーのみを含める」と言われても、必要でないフォルダーって？？

念のため、ビルド定義を見ると、


RTM版ではエラーになりませんでしたが、Update1では「入力が必要である」という警告になっていました。

無い頭をひねってみましたが考えても何も思いつかないので、新しいビルド定義から学ぶことにしてみました。


なんと、最初から「クローク」状態の定義が追加されています！！

ということで、結論は「RTM版でデフォルトのままビルド定義を作成したものをUpdate1に移行した場合、ワークスペースの定義にクローク対象を追加する必要がある」ということです。（「警告メッセージを無視する」という手もありますが、警告とはいえエラーをそのままにするのは精神衛生上よくないかと）

ちなみに、クローク対象として「/[プロジェクトフォルダ]/Drops」が追加されていますが、これはクラウドで稼働しているTeam Foundation Serviceを使ったチームプロジェクトでビルド定義を作成した場合、ビルド出力を格納するフォルダーになります。

個人的な想像ですが、Team Foundation Serviceのビルド定義で「Drops」フォルダを含めた場合、ビルドに必要のないファイル、しかもある程度大きなファイル(.exe／.dllなど)がビルドサーバに転送されることになり、ビルド実行速度／リソースに影響があるのでこの制約が追加されたのではと思います。

オンプレミス環境では「Drops」は使用しないと思いますので、何も考えずにクローク対象として「Drops」を追加しても問題ないと思います。

「ALM Advent Calender」４日目への参加記事になります。

「Microsoft Visual Studio Team Foundation Server 2012 Build Extensions」を使ってAntのBuild.xmlを記述するときに、ビルドに関する情報を使いたい時があります。
（ビルド時のフォルダとか、ビルド時に採番された番号など）

Antの中でechoを使って出力してもいいのですが、ビルド実行時のパラメータを変更することで簡単にログへ出力することができます。

事前にAntを実行するビルド定義を作成し、作成したビルド定義をVisual Studio Shellから実行する時にパラメータを一部変更します。
「パラメータ」タブを選択し、「ログの詳細度」から"Detailed"か"Diagnostic"を指定してから実行します。（ここで指定した内容は１回だけ適用されます）

ビルドが終了すると、ログにAnt実行時のコマンドラインが出力されます。

コマンドライン引数の中で、「-D」で指定されているものがTFSからAntに渡される情報になります。（-D[パラメータ名]=[値]という形式です）

使用例としては、「BuildNumber」をJarファイルのメタ情報として埋め込んでおけば、後でどのビルドで生成したものかが簡単に判別できます。

注意点ですが、残念ながらEclipse+Team Exploere Everywhere(TEE)からではこの手順が使えませんので、Visual Studio Shellから実行してください。
（Eclipseから実行した場合、「パラメータ」タブがありません。TEEを使用するためにVisual Studio Shellは必須ではありませんが、1環境に1台ぐらいはインストールしておいたほうが便利だと思います。）

今まで行ってきた各種チェックのエラー有無判定とJarファイル作成部分についてです。

何も考えずにJUnit／CheckStyle／FindBugsを使うと
　・JUnit／CheckStyleでエラー検知したら、それ以降の処理が実行されなかった
　　→「FindBugsのレポートが作られない」とか。
　・FindBugsでエラー検知したのに、ビルドエラーにできない
といったことになります。
これだと、エラーを見逃してしまうことになるので、
　・エラーチェックは全て実行する
　・何かしらエラーを検知した場合にはビルドをエラーにする
ようにしないといけません。

そのために、今までの各種チェックタスクで
　・エラーを検知しても処理を継続する
　・エラーを検知した場合のみ、プロパティをセットする
というオプションを指定していました。
処理の継続はチェック処理のタスク内で完結していますが、「何かしらエラーを検知した場合にはビルドをエラーにする」ために、プロパティがセットされていればAntをエラー終了させる処理を追加します。


最初の「echoproperites」タスクは、ビルドログファイルにエラーを検知したかどうかを簡単に出力するために入れています。「*.failed」が存在した場合、こんな感じで出力されます。


最初の２行はヘッダ部、残り３行がプロパティ名とセット内容になります。
全て正常であれば、ヘッダ部しか出力されません。

次の「condition」タスクで、Antをエラー終了させるかどうか判定しています。
この場合、junit.failed／findbugs.error.failed／findbugs.warnings.failed／findbugs.warnings.failedのどれかがセットされていれば、metrics.failedをセットすることにしています。
最後に、「fail」タスクでmetrics.failedがセットされていればAntをエラー終了させています。
今回は、この後にJarファイル作成(make-jar)を動かすようにしていますので、エラーがあったときにはJarファイルを作成しません。

残りはJarファイル作成部分です。


特別なことはしていません。
・出力先をBinaries配下に指定し、TFSのビルド画面にある「格納フォルダを開く」から参照できるようにする
・マニフェストファイルに、ビルド番号をセットする
　こんな感じでセットされます。

長々と書きましたが、TFS+Javaでのビルド自動化の基礎はこんな感じかなと思ってます。

気が付いた方がいらっしゃるかもしれませんが、今回の内容ではBuild Extensionsを追加するだけでTFS側に対する特別な設定／定義ファイルの変更ありません。
フォルダ構成に気を付ければ、Antを作成するだけでTFSでもこれだけできるということです。
なお、TFSのビルド定義からAntのターゲットを指定したいという方は「TFSでのJavaビルド環境作成：AntのTarget指定方法」を参考にしてみてください。

最後ですが、「VS2012 Premium/Ultimate+TFS 2012」だとちょっとした設定だけでこれだけのことができるので、どれだけ強力な環境かということも思い知りました。
（ようは.NETで開発したい orz）

FindBugs部分についてです。

ポイントですが、
　・レポートの出力先をBinaries配下にする(outputFile="${findbugs.result.dir}/FindBugsResult.html")
　・エラーを検知したときのみに、プロパティをセットする
　　errorProperty="findbugs.error.failed"
　　warningsProperty="findbugs.warnings.failed"

あと、その２でも書きましたが、サーバのOS環境変数に「LANG=ja_JP.UTF-8」が設定されていないと、レポートの日本語部分が文字化けします。

次が最後ですが、今まで行ってきた各種チェックのエラー有無判定とJarファイル作成部分についてです。

カバレッジ取得準備～テスト・カバレッジレポート作成部分についてです。

最初は、カバレッジ取得準備部分です。


Cobertura独自の取得処理を追加したクラスファイルの出力先を個別に指定する(todir=${cobertura.instrument.dir})だけです。後は普通に記述してください。^ ^;

次はJUnitの実行部分です。


基本的には普通に記述すれば大丈夫ですが、
○テスト結果ファイルについて
　・出力ファイルの形式をxmlにする
　・出力先をBinaries配下にする
　　こうすると、TFSのビルド結果に反映できるようになります。
　　※デフォルトで問題ないのですが、出力ファイル名が「TEST-*.xml」に従わないと、TFSのビルド結果に反映されません。
○処理継続について
　CheckStyleと同様に
　・テストエラーを検知しても処理を継続させる（haltonfailure="off"）
　・テストエラーを検知したときのみ、プロパティをセットする（failureproperty="junit.failed"）
を指定します。

さらに、テスト結果レポートの作成についてです。


レポートの出力先をBinaries配下にしておき、後でTFSの格納フォルダから参照できるようにしておきます。

次はカバレッジ取得レポートの作成です。


出力先をBinaries配下にすることぐらいで、基本通りで問題ありません。

次は、FindBugs部分についてです。

CheckStyle部分についてです。


「src」配下にあるファイルを対象にして、チェックを実行します。
（テスト用ソースが格納される「testsrc」は対象になりませんので、テスト用ソースがいくら汚くても問題ありませんｗ）

ポイントですが、
　・failOnViolation="false"
　　エラーを検知しても処理を継続する（Antを終了しない）
　・failureProperty="checkstyle.failed"
　　エラーを検知したときだけ、指定したプロパティをセットする
　・レポートの出力先（style out）を「Binaries」配下にする
　　パス定義として「${checkstyle.result.dir}」を「${BinariesRoot}/CheckStyleResult」としています
の３つです。
「checkstyle.failed」は、後ほどエラー検知有無で使用します。

次はカバレッジ取得準備～テスト・カバレッジレポート作成部分についてです。

まず、ビルドタスクの順番はこうしました。

ソースのビルド(build)→テストソースのビルド(testbuild)→CheckStyle(checkstyle)→カバレッジ取得準備(instrument-cobertura)→JUnitテスト実行＆レポート作成(junitreport)→カバレッジレポート作成(coverage)→FindBugs実行(findbugs)→エラー有無確認(checkmetrics)→Jarファイル作成(make-jar)

さて、最初のソースのビルド(build)／テストソースのビルド(testbuild)についてです。


元々のソースに対する出力先は「bin」配下に、テストソースに対する出力先は「testbin」に分離し、最後にJarファイルを作成する際の対象を「bin」配下のファイルだけにすればいいようにしています。

次はCheckStyle部分についてです。

build.xmlの先頭には各種パスの定義を記載していますが、まずは全体のフォルダ構成はこうしました。


今回、TFSのプロジェクト名を「JavaProject1」、ビルド定義名を「CI-Build」にしています。

TFSのビルドを実行すると、「Sources」配下にソースファイルなどが展開され、ワークフォルダを作成しつつビルドが進み、最終生成物を「Binaries」配下に格納するという感じになります。

build.xmlのフォルダパス定義部分です。


「～_HOME」はOS環境変数を参照しています。
「${BinariesRoot}」は、TFS上での最終生成物の格納先フォルダを示す定義で、TFSのビルドサービスから実行されると自動的に設定されます。（今回は「\Build\1\JavaProject1\CI-Build\Binaries」がセットされます）

基本的には、HOMEの設定と、生成物の出力先の設定を行ってます。
１つ、「cobertura.instrument.dir」についてですが、カバレッジ取得のため、coberturaがオリジナルソースに独自の処理を追加するのですが、追加されたクラスファイルを格納するためのフォルダを指定しています。

次は各処理で指定するクラスパス定義とFindBugs／CheckStyle／Coberturaタスクを使うためのtaskdefです。


基本的には、各処理のマニュアルに記載されている通りです。

次はソースのビルド処理(javacタスク)部分についてです。