SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Visual Studio Team System 徹底活用

フィールドの規則を使ってTFSの作業項目を高度に作りこむ

Visual Studio Team System 徹底活用(4)

  • X ポスト
  • このエントリーをはてなブックマークに追加

 Visual Studio Team System 2008 Team Foundation Serverの作業項目にはさまざまな制約をかけるためのフィールドの規則という機能が用意されています。これを利用することで作業項目はより使いやすくなります。また、作業項目の編集に制限をかけることもできます。今回は、フィールドの規則の種類や利用方法、利用シーンを理解して、より高度に作業項目を作りこめることを目指します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

はじめに

 本稿は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ファイルを編集する場合には、次のリストのようにしてフィールドの規則を適用します。

[リスト1]フィールド規則の適用
<FIELD name="名前" refname="Jp.CodeZine.WIT04.Name" type="String">
  <REQUIRED />
</FIELD>

 このように、すべてのフィールドの規則は、<FIELD>要素のサブ要素として定義することになります。なお、この例では、必須入力であることを示すフィールドの規則を適用しています。では、次にフィールドの規則を適用する場所を確認しておきます。実は、作業項目定義内にはフィールドの規則を適用できる場所が何か所か用意されています。具体的には、フィールド定義、状態定義、状態遷移定義の3か所でフィールドの規則を適用することができます。

フィールド定義のフィールド規則

 フィールド定義にフィールドの規則を適用するのは一番基本的な適用方法です。作業項目のxml要素でみると、<FIELDS>要素内に定義された各フィールドにフィールドの規則を適用する方法になります。ここで適用したフィールドの規則は、他の規則がないときに常に適用される規則で、言わば静的に決められる規則です。作業項目のワークフローによらず、他の規則が存在しない場合に常に規則を適用させておきたい場合には、この中で定義することになります。

状態定義のフィールド規則

 作業項目の状態定義の中でもフィールドの規則を適用することができます。簡単にこの状況を表現してみるとリスト2のようになります。

[リスト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のようになります。

[リスト3]状態遷移定義のフィールド規則の例
<WORKFLOW>
  <TRANSITIONS>
    <TRANSITION from="" to="アクティブ">
      <FIELDS>
        <FIELD refname="System.AssignedTo">
          <DEFAULT from="currentuser" />
        </FIELD>
      </FIELDS>
    </TRANSITION>
  </TRANSITIONS>
</WORKFLOW>

 状態定義と同様に状態遷移定義であるTRANSITION要素の中にFIELD要素が含まれていることに注目してください。この部分にあるフィールド定義の構成は状態定義の時と同様です。ここで定義したフィールドの規則は、作業項目が状態遷移するときにのみ有効になるもので、この例では作業項目が新規に作成されたときに適用される規則という位置づけになります。この例では、作業項目が新規作成されたときにSystem.AssignedTo(担当者)フィールドの値が作業項目を作成したユーザーの名前に設定されることになります。状態遷移定義内でのフィールドの規則は今回の例のように状態が移り変わるときに自動的に変わるフィールドの値を設定しておきたいときに利用するのが一番効果的です。

次のページ
利用できるフィールドの規則

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Visual Studio Team System 徹底活用連載記事一覧

もっと読む

この記事の著者

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

WINGSプロジェクト りばてぃ(リバティ)

WINGSプロジェクトについて> 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きたい。著書記事多数。 RSS Twitter: @yyamada(公式)、@yyamada/wings(メンバーリスト) Facebook

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/4346 2009/10/02 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング