はじめに
本稿はVisual Studio Team System 2008 Team Foundation Server（以下、TFS）に用意されている作業項目という機能を使い倒すというシリーズの第4回です。今までの回では作業項目を定義するための要素の理解や基本的なカスタマイズの方法、TFS Power Toolsというツールを利用した便利なカスタマイズの方法などを確認してきました。第4回となる今回は、作業項目定義に用意されているフィールドの規則という機能を理解し、より高度に作業項目定義を作成できるようになることを目指します。
対象読者
- .NET Frameworkを利用した開発プロジェクトに携わっている人
- Visual Studio Team System 2008に興味がある人
- Team Foundation Serverの作業項目のカスタマイズに興味がある人
必要な環境と準備
本稿で解説している内容を実際に行うためにはVisual Studio Team System 2008 Team Foundation Serverが利用できる環境が必要です。
このための手順はシリーズ第一回の「TFSの作業項目をプロジェクトに合わせてカスタマイズする（前編）」の必要な環境と準備で解説していますのでそちらを参照してください。
フィールドの規則とは
TFSの作業項目定義にはフィールドの規則と言われるフィールドの動作と制約を定義する機能が用意されています。これは例えば、名前というフィールドが必須入力のフィールドであることを定義したり、フィールドの入力内容をあらかじめ決められたリストの中から選択するように設定したり、といったことを行うためのものです。作業項目定義を作成する立場からこの機能を考えると、入力を強制させたいフィールドを決定したり、入力できる内容を絞ったりすることで、利用者に作成者の意図を伝えることができます。逆に利用者からみると作成者が想定している内容をより早く正確に入力できるようになり、入力の負荷を軽減していくことができます。
本稿ではこれからフィールドの規則についてさまざまな内容を確認していきますが、その前に1点だけ述べておきます。フィールドの規則を利用することで、作業項目の入力に当たってかなりの制限をかけることができるようになります。ですが、それは作業項目の使い勝手をよくする場合もあれば、使い勝手を悪くしてしまう場合もあります。作業項目定義を作りこもうとした際、入力してもらいたい項目や作業項目の使われ方などを厳密に検討していけばいくほど、さまざまな制約をかけたくなってしまうものです。しかし、あまり厳しい制約は使い勝手を極端に悪くしてしまい、結果としてまったく使われないものになってしまうという危険性をはらんでいます。
作業項目定義の検討は簡単にできるものではなく、それなりの時間を要するものです。ですが、そんな時間をかけて作成したものが使われないとしたらそんな悲しいことはないですよね。そんな自体を防ぐためにも、使い勝手を上げるための制約は有効活用し、使い勝手を下げてしまう制約はかける前に今一度よく検討するようにしてください。作業項目定義はできるだけ柔軟に利用できるように作成し、運用でカバーできるような場合にはそういった方法でうまくやっていくほうが、よく利用されるようになって結果としてよい成果を上げられるようになるはずです。
フィールド規則を適用する場所
フィールドの規則の詳細を確認する前に、フィールドの規則の基本的な書き方と規則を適用する場所を確認しておきましょう。作業項目定義のxmlファイルを編集する場合には、次のリストのようにしてフィールドの規則を適用します。
<FIELD name="名前" refname="Jp.CodeZine.WIT04.Name" type="String"> <REQUIRED /> </FIELD>
このように、すべてのフィールドの規則は、<FIELD>要素のサブ要素として定義することになります。なお、この例では、必須入力であることを示すフィールドの規則を適用しています。では、次にフィールドの規則を適用する場所を確認しておきます。実は、作業項目定義内にはフィールドの規則を適用できる場所が何か所か用意されています。具体的には、フィールド定義、状態定義、状態遷移定義の3か所でフィールドの規則を適用することができます。
フィールド定義のフィールド規則
フィールド定義にフィールドの規則を適用するのは一番基本的な適用方法です。作業項目のxml要素でみると、<FIELDS>要素内に定義された各フィールドにフィールドの規則を適用する方法になります。ここで適用したフィールドの規則は、他の規則がないときに常に適用される規則で、言わば静的に決められる規則です。作業項目のワークフローによらず、他の規則が存在しない場合に常に規則を適用させておきたい場合には、この中で定義することになります。
状態定義のフィールド規則
作業項目の状態定義の中でもフィールドの規則を適用することができます。簡単にこの状況を表現してみるとリスト2のようになります。
<WORKFLOW>
<STATES>
<STATE value="アクティブ">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ClosedDate">
<EMPTY />
</FIELD>
</FIELDS>
</STATE>
</STATES>
</WORKFLOW>
状態定義であるSTATE要素の中にFIELD要素が含まれていることに注目してください。この部分のフィールド定義は、フィールドの規則を適用するために定義されています。そのため、refname以外の属性がないことがポイントです。このrefname属性は、フィールドの規則を適用するためのフィールドを識別するために利用しています。
ここで定義したフィールドの規則は、作業項目がこの状態の時のみ有効になるもので、通常のフィールド定義の中で定義していたフィールドの規則と対比するとこちらは動的に適用される規則ということができます。例えば、リスト2の例では、ClosedDateというフィールドの値をクリアするように設定されていますが、フィールドの状態がアクティブなので、終了日に値が入っているのはおかしいということを表現するために設定されています。
このようにある状態の時にだけ適用したいフィールドの規則は、作業項目定義の状態定義の中で設定していきます。
状態遷移定義のフィールド規則
作業項目の状態遷移定義の中でもフィールドの規則を適用することができます。簡単にこの状況を表現してみるとリスト3のようになります。
<WORKFLOW>
<TRANSITIONS>
<TRANSITION from="" to="アクティブ">
<FIELDS>
<FIELD refname="System.AssignedTo">
<DEFAULT from="currentuser" />
</FIELD>
</FIELDS>
</TRANSITION>
</TRANSITIONS>
</WORKFLOW>
状態定義と同様に状態遷移定義であるTRANSITION要素の中にFIELD要素が含まれていることに注目してください。この部分にあるフィールド定義の構成は状態定義の時と同様です。ここで定義したフィールドの規則は、作業項目が状態遷移するときにのみ有効になるもので、この例では作業項目が新規に作成されたときに適用される規則という位置づけになります。この例では、作業項目が新規作成されたときにSystem.AssignedTo（担当者）フィールドの値が作業項目を作成したユーザーの名前に設定されることになります。状態遷移定義内でのフィールドの規則は今回の例のように状態が移り変わるときに自動的に変わるフィールドの値を設定しておきたいときに利用するのが一番効果的です。
