Blog

今回は、Antのjavacタスクで使用するソースファイル／クラスファイルのフォルダ指定についてです。
TFSでビルドを実行すると、指定された状態（通常は最新バージョン）のファイルを自動的に取得します。取得先は、ビルドエージェント作成時に作業ディレクトリに指定したフォルダになります。

クラスファイルなどのビルド生成ファイルの出力先についてはいろいろ考えがあると思いますが、今回はTFSのビルド結果出力フォルダに出力したいと思います。

javacタスクでは、ソースファイルのフォルダは「srcdir」属性、クラスファイルの出力先フォルダは「destdir」属性で指定できますが、この内容をTFSで使用するフォルダと連動させます。
実は、MSBuildからAntを実行する際に、TFSBuild.projでTFSで使用する情報の一部がプロパティとしてセットされています。

デフォルトでセットされているのは以下の情報です。
　BinariesRoot
　BuildDefinitionName
　BuildDefinitionUri
　BuildDirectory
　BuildNumber
　DropLocation
　LogLocation
　SourceGetVersion
　TestResultsRoot
　TeamProject
　WorkspaceName
　WorkspaceOwner
各項目の内容については、MSDNのTeam Foundation ビルド アクティビティ、またはIBuildDetail Propertiesに記載されています。
但し、「LogLocation」はなぜかセットされていません。（今回、これが結構痛いです）

この情報を組み合わせてソースファイル／クラスファイルのフォルダ指定を行いたいのですが、Javaプロジェクト名はTFS側では管理されていないので、MSBuildの引数に追加し、Antに渡すプロパティ情報にも追加します。
以下の内容で「JavaProjectName」というプロパティ指定をTFSBuild.projに追加し、修正内容をチェックインします。

TFSビルド定義の方は、MSBuildの引数に「JavaProjectName」を追加し、保存します。

次に、EclipseからBuild.xmlを以下のように変更し、チェックインします。

変更内容は
　・javacタスクのsrcdir属性に指定するソースフォルダをsrcbaseプロパティとして組み立てる。
　・javacタスクのdestdir属性に指定するクラスファイル出力フォルダdestbaseプロパティとして組み立てる。
　・destbaseプロパティにセットしたフォルダをjavacタスク実行前に作成する
になっています。
※クラスファイルの出力先がTFSのビルド結果出力フォルダになっていませんが、TFSのビルドが完了したときに、「${BuildDirectory}/binaries」配下の内容がTFSのビルド結果出力フォルダにコピーされます。

これで、Eclipseからビルドを実行すると、.classファイルがTFSのビルド結果出力フォルダに出力されます。

次は、ソースファイルの静的解析ツールであるFindBugsをビルド時に実行してみます。

前回、Ant用Build.xmlが実行できたのにメッセージが出力されなかったのは、Ant実行時のTarget名を指定していなかったためです。
Antでは（Antじゃなくてもそうだと思いますが）、一連のまとまった処理をTargetとして定義し、実行時にTarget名を指定することでいろいろ動作を切り替えます。
今回作成したBuild.xmlは、

という内容で作成しました。<project default="">と指定しているので、実行時にTarget名を指定しないと何も実行されません。

しかし、AntのTarget名を指定するところはどこにもありませんでした。
VisualStudio IDEからビルド定義を開いても、AntのTarget名を指定する項目はありません。

多少力技かと思いますが、MSBuildプロジェクトファイルを修正して、MSBuildの引数でAntのTarget名を指定できるようにします。
ここからはVisualStudio IDEでの作業になります。
まずは、TFSプロジェクトのフォルダとローカルフォルダのマッピングをしておきます。
チームエクスプローラーから「ソース管理」をダブルクリックし、ソース管理エクスプローラーを開きます。

ローカルパスのところに「マップされていません」とあるので、クリックします。

マッピングするフォルダを指定し、「マップ」を押すとソース管理エクスプローラーに戻ります。
MSBuild用のプロジェクトファイルは「TeamBuildTypes」－「[ビルド定義名(ここではJavaBuild)]」－「TFSBuild.proj」になります。
まずは編集のために、最新ファイルを取得します。
「TFSBuild.proj」を右クリックし、「最新バージョンの取得」を選択します。

取得が終わったら、ダブルクリックしてファイルを開きます。
ファイルの最後のほうにAnt関連のパラメータを指定する記述があります。(AntBuildFile要素)

Target要素に指定した名称がAnt実行時のTarget名として使われますが、何も指定はありません。ここに、MSBuildの引数を当てはめることにします。
Target要素の内容として「$(AntTarget)」を追加し、保存→チェックインします。

次に、TFSのビルド定義を変更します。
チームエクスプローラーから「JavaBuild」を右クリックし、「ビルド定義の編集」を選択します。

「詳細」の中にある「MSBuild引数」のところに「Property:AntTarget=test」を追加し、保存します。

Eclipseから再度ビルドを実行し、結果を確認します。

ちゃんとAntの"test"Targetが実行され、メッセージが表示されました。

次は、Antのjavacタスクで指定するソースファイル／クラスファイルの場所指定についてです。

前回作成したBuild.xmlを使うTFSのビルド定義を作成します。
チームエクスプローラーから「ビルド」を右クリックし、「新しいビルド定義」を選択します。

VisualStudio IDEから作成するのとほぼ同じですが、一部異なります。
ビルド定義名は「JavaBuild」で作成してみます。

トリガーは「手動」のままです。

ワークスペースはデフォルトのままにします。

ビルドの規定値で、「ビルドコントローラー」にはビルドサーバで稼働しているビルドコントローラーの名称（デフォルトのままで作成した場合、「既定のコントローラー – [ビルドサーバ名]）を選択します。また、ビルド結果（結果ログ、作成したバイナリファイルなど）を保存／公開するための共有フォルダ名を入力します。

次項目がVisualStudio IDEとは完全に異なります。VisualStudio IDEから作成したときは「プロセス」となっていて、MSBuildとかWF(Windows Workflow Foundation)エンジンへのパラメータを設定するのですが、TEE(Team Explorer Everywhere)からビルド定義を作成（編集）したときには、MSBuild用のファイルを指定する内容になります。
ビルド定義を作成したときには、MSBuildプロジェクトファイルは作成されていませんので、「作成」ボタンが表示されます。

ビルド構成のウィザードが起動されます。今回はAntを使用するので、「既存のAnt BuildfileによるMSBuild構成」を選択し、「次へ」を押します。

TFSビルド定義で使用するAntビルドファイルとして、先ほど作成したBuild.xmlを指定します。

「完了」を押すと、MSBuildプロジェクトファイルが作成され、元のTFSビルド定義編集画面に戻りますので、「OK」を押して定義作成を終了します。

これで、TFSビルドからAnt用Build.xmlが実行できるようになったので、おためしで実行してみます。

ビルドが完了したら、実行結果を確認してみます。

結果一覧から最新ビルド結果レコードをダブルクリック

概要のところに「ログファイルの表示」がありますので、これをクリックすると、Ant用Build.xmlのログファイルが表示されます。

「BUILD SUCCESSFUL」と出力されてるので、Antそのものは起動されているのですが、、Build.xmlで記載したメッセージが出力されていません。
どうするかはこの次で。

続いて、TFSのビルド定義からAntを起動できるようにします。

まずは、VSからTFSプロジェクトを作成します。その後、Eclipseから作成したTFSプロジェクトに接続します。

そして、EclipseでJavaプロジェクトを作成し、TFSプロジェクトに登録します。

「保留中の変更」にいろいろでてくるので、とりあえず「チェックイン」してしまいます。
その後、Team Foundation Server チームエクスプローラーから「ソース管理」をダブルクリックし、ソース管理エクスプローラーからJavaプロジェクトフォルダの下にある「.settings」のフォルダをクローク（ファイル同期対象外にする）します
（Team Foundation Server チームエクスプローラーはパースペクティブから開けます）

Javaソースファイルを作成し、TFSにチェックインします。
次に、Ant用のBuild.xmlファイルを作成し、TFSにチェックインします。
最初はビルドでエラーがでても嫌なので、メッセージだけ出力することにします。

次は、TFSのビルド定義の作成です。

ほぼ１ヶ月ごとの更新になってます^ ^;

さて、今までクライアント側（Eclipse）のことは何回か書きましたが、これからはサーバ側のことについて書いてみたいと思います。
（ほんとは.NETで全部開発したいのに．．．）
※あくまで１例です

今回、こんな環境を前提で作業を行います。

TFSのアプリケーションサーバ（tfs02）とビルドサーバ（build2008r2）を分けてみました。
プロジェクト管理は１サーバで集中管理するけど、ビルドは言語別で環境を分離するかなという想定です。

まずは、ビルドサーバにJDKとAntをインストールします。JDKは16.u18、Antは1.8.1を使ってみました。
インストールそのものに注意点はありません。JDKはインストーラーの言うことに従い、Antはただ解凍するだけです。

インストール終了後、JDKとAntのインストールフォルダをシステム環境変数に追加します。
今回は、JDKは「JAVA_HOME」、Antは「ANT_HOME」で追加します。

最後のデータ移行です。

○移行用設定ファイル作成
　データ移行のための設定ファイルを作成します。
　基本はMSDNのサンプルでOKなのですが、かの有名な川保さんのページにあるように、設定ファイルのサンプルに一部情報が不足しています。(接続先TFSのcollection属性）
　collection属性を付け加えた設定ファイルのサンプルはこんな感じになります。
　　<?xml version="1.0" encoding="utf-8"?>
　　<SourceControlConverter>
　　      <ConverterSpecificSetting>
　　            <Source name="VSS">
　　                  <VSSDatabase name="[VSS DBファイルの格納フォルダ]"></VSSDatabase>
　　                  <UserMap name="[ユーザマッピングファイル名]"></UserMap>
　　            </Source>
　　            <ProjectMap>
　　            <Project Source="$/" Destination="$/[TFSプロジェクト名]"></Project>
　　            </ProjectMap>
　　      </ConverterSpecificSetting>
　　      <Settings>
　　        <TeamFoundationServer name="[TFSサーバ名]"
　　         port="8080"
　　         protocol="http"
　　         collection="tfs/[接続先Collection名]"></TeamFoundationServer>
　　       <Output file="[移行結果出力ファイル名]"></Output>
　　     </Settings>
　　</SourceControlConverter>

○データ移行実行
　Visual Studio コマンドプロンプト(2010)を管理者権限で起動します。

　VSSConverterコマンドをMigrateオプションをつけて実行します。
　VSSConverter Migarate [移行用設定ファイル名]

　ここで、KB950185のパッチが適用されていないと、こんな確認メッセージが表示されます。

　しかし、2011/07/23時点で、MSのKB950185の情報ページを見ると、パッチファイルはダウンロードできない状態になっています。
　ここにはあるようですが、これを使ってサポートが受けれるかどうかは確認していません。

　’Y’を入力すれば、とりあえず処理は継続できます。

　２～３個の確認メッセージとVSS接続時のパスワード確認後に、実際の移行処理が実行されます。（状況に応じて確認メッセージは変わります）

　しばらくすると、移行が完了します。
　全体的な移行結果については[移行結果出力ファイル名(.xml)]に出力されます。

一度設定ファイルが出来上がってしまえば、移行対象が複数あってもファイルコピペ→一部修正で対応できるので、さほど難しくはないと思います。
あとは、VSSが壊れていないことを祈るのみです^ ^;

　移行対象のVSSに対して、移行可能かどうかの分析と、VSSを使用したユーザ一覧を出力させます。
　次に、VSS側ユーザ一覧を元に、VSS上で使用されていたユーザと、TFS上のユーザを結びつけるための準備をします。

○分析用設定ファイルの作成
　VSS移行ツールであるVSSConverter.exeを使用して、VSS上で使用されていたユーザ名一覧をファイルに出力します。
　概要については、MSDNサイト内の
　「方法 : ソース管理の分析および移行の設定ファイルを作成する」
　「VSS コンバータ設定ファイルのサンプル」
　になります。
　サンプルとしてはこんな感じです。
　　<?xml version="1.0" encoding="utf-8"?>
　　<SourceControlConverter>
　　      <ConverterSpecificSetting>
　　            <Source name="VSS">
　　                  <VSSDatabase name="[VSS DBファイルの格納フォルダ]"></VSSDatabase>
　　                  <UserMap name="[ユーザ一覧出力ファイル名(.xml)]"></UserMap>
　　            </Source>
　　            <ProjectMap>
　　            <Project Source="$/"></Project>
　　            </ProjectMap>
　　      </ConverterSpecificSetting>
　　      <Settings>
　　       <Output file="[分析結果出力ファイル名(.xml)]"></Output>
　　     </Settings>
　　</SourceControlConverter>
　※設定ファイルの文字コードをUTF-8で保存しないと実行時に怒られます。
　分析の時点では、TFSに関する情報は必要ありません。

○分析実行
　Visual Studio コマンドプロンプト(2010)を管理者権限で起動します。

　VSSConverterコマンドをAnalyzeオプションをつけて実行します。
　VSSConverter analyze [分析用設定ファイル名]

　しばらくすると、分析が完了します。

　全体的な分析結果については[分析結果出力ファイル名(.xml)]に、VSS内で使用されたユーザ一覧については[ユーザ一覧出力ファイル名(.xml)]に出力されます。

○TFSプロジェクト作成
　移行先のTFSプロジェクトを作成します。

○TFSプロジェクトに対して利用ユーザを設定
　VSS内で使用されたユーザの割り当て先となるユーザを、TFSプロジェクトに登録します。

○ユーザマッピング定義ファイル作成
　分析時に作成されたユーザ一覧ファイルを元に、VSS側ユーザとTFS側ユーザのマッピング定義を作成します。
　・変更前（分析時）
　　  <UserMap From="VSSUser01" To="" />
　　  <UserMap From="VSSUser02" To="" />
　　  <UserMap From="VSSUser03" To="" />
　・変更後
　　  <UserMap From="VSSUser01" To="TFSUser01" />
　　  <UserMap From="VSSUser02" To="TFSUser02" />
　　  <UserMap From="VSSUser03" To="TFSUser03" />

　さて、TFS環境が構築できたら次は移行ということで、VSSからTFSへの移行例みたいなものを。

○準備物
　・Visual Studio 2010／SQL Server 2008
　　Professional以降であれば、VSをインストールした環境で大丈夫です。
　　Team Explorer環境だと、SQL ServerがインストールされないのでNGです
　　→VSS移行ツール(VSSConverter)は、移行処理にSQL Serverを使用します。
　　Expressは．．．確認してません^ ^;
　・Visual SourceSafe 2005
　　VSS6.0dでは移行できません。
　　ただ、VSS2005が必要なのは移行処理で使用する端末のみです。元データはVSS6.0dのままで実行は可能です。
　・移行後に保持されない情報の確認
　　MSDNサイト内の「ソース管理の移行のための VSSConverter コマンド ライン ツール」に掲載されています。
　　今回は、これらの対象がない前提にします。
　・（できれば）実機
　　仮想環境でも実行は可能ですが、結構リソースを食いまくるみたいで、「止まったか？」と思うほど時間がかかる場合があります。
　　あくまで一例ですが、
　　　仮想環境：２日
　　　　CPU：１個(SCVMM上では1.00GHz PentiumⅢ Xeon)
　　　　メモリ：1GB
　　　　OS：Win7
　　　実機　　：３０分
　　　　CPU：Core 2 Duo（詳細は忘れました^ ^;）
　　　　メモリ：1GB
　　　　OS：Win7
　　という結果がでたので、実機を準備したほうが幸せだと思います。

TFS2010のライセンス上、TFSだけで使用する場合に限り、SQL Server Standardが使用可能となっていましたが、出荷タイミングの問題で2008に限定され、2008R2は使用できませんでした。
（あくまでライセンス上の問題であり、使用上は問題ないようです）

しかし（というか、やっと）、ライセンス上でも2008R2が使用可能になったとbharryのブログに記事が掲載されました。
MSDN Subscribers can now upgrade their TFS 2010 SQLServer to SQL 2008 R2

これで、Windows Server 2008 R2にTFSを構築するのに警告メッセージを見なくて済みます(^_^;)