次の方法で共有

状態、遷移、または理由に基づいたフィールド割り当ての自動化

  • [アーティクル]

更新 : 2011 年 1 月

Visual Studio アプリケーション ライフサイクル管理 (ALM) 内の他の場所で発生するイベント、または Visual Studio ALM の外部で発生するイベントに基づいて、作業項目をある状態から別の状態に自動的に遷移させることが必要な場合があります。 たとえば、コール トラッキング ツールで発生するイベントに基づいて、バグの状態遷移を自動化する場合があります。 作業項目の種類モデルおよび作業項目トラッキング API は、他のシステムによる作業項目の自動遷移をサポートするように拡張されています。

作業項目の状態を変更するコードがある場合は、ACTION 要素を使用して該当する状態遷移とアクションを関連付けることによって、そのコードをジェネリック化することができます。 [WorkItem.GetNextState] メソッドにアクションの値を渡すと、その作業項目のアクション後の状態を取得できます。 バージョン管理チェックイン ダイアログ ボックスでは、このメソッドを使用してバグを解決し、チェックインに関連付けられているタスクを閉じます。

ACTION は、ACTIONS の子要素で、省略可能な要素です。

注意

Microsoft Web サイトの「Extending Team Foundation (Team Foundation の拡張)」のページで説明されているように、作業項目トラッキング API は Visual Studio ALM SDK の一部です。

たとえば、ユーザーが変更をチェックインした後に、作業項目を "解決済み" 状態に自動的に遷移させるよう事前設定されているツールがあるとします。 ただし、統合プロバイダーの側では、作業項目の種類の作成者がどの状態を "解決済み" として宣言しているのかわかりません。 作成者が意味したこととしては、解決、終了、完了、テスト可能、ビルド可能などさまざまな状態が考えられます。 このような場合、作業項目の種類の作成者全員が "解決済み" と明示した状態を必ず含めるように決めるという方法もあります。

その解決策は過度に制限的です。 また、状態をローカライズできないため、国際的な観点からも望ましくありません。 代わりに、システム インテグレーターは "チェックイン" や "完了" など、作業項目を自動的に遷移させるアクションを宣言できます。 作業項目の種類の作成者は、このアクションを宣言することで適切な遷移を発生させることができます。

このトピックの内容

  • ACTION 要素の構文

  • 自動化をサポートするために必要な手順

  • 状態遷移とアクションの関連付け

  • 遷移アクションの詳細

  • 自動遷移のエラー チェック

ACTION 要素の構文

ACTION 要素では、次の構文を使用します。 value 属性ではアクションの名前を指定します。この属性は必須です。 アクションでは、フィールド参照名と同じ名前付け規則に従う必要があります。 たとえば、Team Foundation バージョン管理 は Microsoft.VSTS.Actions.CheckIn を使用して、チェックインに関連付けられている作業項目に適した遷移を特定します。 詳細については、「作業項目トラッキング オブジェクトの名前付け規則」を参照してください。

<ACTION value="NameOfAction" />

minOccurs="0"

maxOccurs="unbounded"

自動化をサポートするために必要な手順

ツールを作業項目トラッキングと統合するには、そのツールで次の手順を実行できる必要があります。

  1. アクションが実行されたときに、作業項目がどの状態に遷移するかを決定する

  2. 作業項目を "to" 状態に設定する

    作業項目トラッキング API には、これらの手順を実行する各種メソッドが用意されています。 作業項目トラッキング API は、Visual Studio ALM SDK の一部です。 詳細については、Microsoft Web サイトの「Team Foundation Server SDK」を参照してください。

    注意

    特定の状態への遷移を発生させたトランザクション アクションは記録されません。 遷移を発生させたアクションを追跡する必要がある場合は、アクションを追跡する追加の作業項目フィールドを指定するか、理由値を定義します。

ページのトップへ

状態遷移とアクションの関連付け

状態遷移アクションを使用すると、ワークフロー内のさまざまな時点で作業項目の遷移を自動化できます。 たとえば、Team Foundation Server のバージョン管理システムでは、チェックイン時に作業項目の自動遷移をサポートする必要があります。 これをサポートするために、"microsoft.vsts.actions.checkin" アクションが定義されています。

作業項目の種類の作成者は、"Working" という状態を持つ "Defect" という作業項目の種類を定義し、開発者が変更を加えるときにこの作業項目を使用できます。 作業項目の種類の作成者は、"Ready To Build" という別の状態も定義できます。これは、障害の影響を受けたコードが、夜間ビルドで使用できる状態にあることを開発者が宣言したことを意味します。

作成者は、次を宣言することによって、チェックイン操作時に作業項目を "Working" 状態から "Ready To Build" 状態に自動的に遷移できます。

<TRANSITION from="Working" to="Ready To Build">
   <ACTIONS>
      <ACTION value="microsoft.vsts.actions.checkin"/>
   </ACTIONS>
</TRANSITION>

ページのトップへ

遷移アクションの詳細

状態遷移アクションを使用すると、ワークフロー内のさまざまな時点で作業項目の遷移を自動化できます。 遷移アクションを使用する場合は、次の点に考慮してください。

  • 遷移アクションは省略できます。 作業項目インスタンスの現在の状態が、指定されたアクションのアクション エントリを持つ場合、"to" 状態が返されます。 そうでない場合、戻り値は Null になります。 統合では、Null の戻り値が適切に処理されます。 つまり、次のようになります。

    • 処理が中止されません。

    • 必要なアクションが見つからなかったために統合が自動遷移を実行しなかったことを示すトレースまたはログが残されます。

  • 作業項目の種類ごとに、アクションは、From State/Action のペアに対して一意である必要があります。 つまり、作業項目の種類の作成者は、同じアクションに対して複数の "to" 状態を指定できません。

  • ただし、同じ遷移における複数のアクションはサポートされているので、次の例に示すように複数の自動遷移統合を実行できます。

    <TRANSITION from="Working" to="Ready To Build">
   <ACTIONS>
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
      <ACTION value="ADatum.Actions.Complete"/>
   </ACTIONS>
</TRANSITION>

  • アクション名はプログラミング可能な名前であり、英字のみ使用できます。

  • アクション名は、販売元と顧客の間での競合を回避するために、フィールド参照名と同じ参照名前空間規則に従って指定される必要があります。 ただし、この規則はツールでは使用されません。 Visual Studio ALM では Microsoft.VSTS.Actions.<your action> が使用されます。

ページのトップへ

自動遷移のエラー チェック

インテグレーターが行うことができる自動遷移は 2 種類あります。 1 つは、ユーザー アクションによって発生する自動遷移です。 もう 1 つは、夜間ビルドなど、無人のオートメーションによって発生する自動遷移です。

  • ユーザー アクションによる自動遷移   この種類の自動遷移では、ユーザーがおり、規則に関連して生じる懸案事項に対応できます。 作業項目の種類の作成者が統合で認識されない必須フィールドを追加したときに生じる状況を確実にサポートする必要があります。 この状況をサポートするには、自動遷移を実行した後で、作業項目の種類を調べて、規則の違反がないか確認します。 違反が見つかった場合は、フォームを表示して、ユーザーが解決できるようにします。

  • 無人のオートメーションによる自動遷移   懸案事項を解決できるユーザーはいないということを前提とします。 この場合、統合は適切な形で失敗します。 エラー ログには、自動遷移が試行されたことと、エラーの理由が表示されます。

いずれの種類の自動遷移を定義するときも、遷移の終了時に各作業項目が有効な状態に達し、ユーザーによる操作が必要ないように遷移を定義しておきます。 言い換えると、遷移先の状態に対して定義されているすべての規則が、全フィールドの既定値またはコピーされた値によって満たされるようにします。 遷移の後でいずれかのフィールドが無効になる場合には、状態遷移は失敗します。

フィールドが無効にならないようにするために、以下の操作を行います。

  • 状態遷移に DEFAULTREASON を定義します。

  • 状態遷移後にフィールドが必須フィールドになる場合は、DEFAULT 規則要素または COPY 規則要素を使用してフィールドの値を指定します。

たとえば、作業項目の状態を "処理中" から "ビルド準備完了" に遷移する遷移アクションのチェックインを作成したとします。 "ビルド準備完了" の作業項目の規則では、"解決者" フィールドを設定することが必要です。 次に、TRANSITION セクションの "ResolvedBy" に対して、DEFAULT 規則要素または COPY 規則要素を定義します。 さらに、ユーザーによる操作を必要とせずに必須フィールドを確実に設定できるように、DEFAULTREASON を定義します。

ページのトップへ

参照

概念

フィールドの規則を適用するタイミングと場所

Associating a State Transition with an Action

履歴の変更

日付

履歴

理由

2011 年 1 月

ACTION 要素を使用してフィールド割り当てを自動化する方法を取り上げたトピックを統合。

情報の拡充