...または、TFS 2010でいくつかのアクションを自動化する方法。



TFS 2012の場合、著者は更新されたバージョンを迅速にリリースすることを約束しますが、私の意見では、APIが変更されていないかほとんど変更されていないという事実を考えると、この小さなプロジェクトは新しいTFS 2012 RCで開始される可能性が高いと言えます。

アイデア

私の最後の記事（ one 、 two ）では、TFSのプロセステンプレートの構成について説明していますが、これらのテンプレートは実際には切り離されていますが、実際には、Child、Parent、Rerelated Toなどの関係によって作業で接続されています。 この接続を使用して回路全体に対話性を追加し、要素が実際に接続され、接続および状態のタイプに応じて互いの状態に実際に反応するようにすることは論理的です。 メトリックでいくつかの累積計算を行うために、これらのデータはすべて利用可能であり、自動モードで使用できるため、日常的なアクションの時間を短縮できます。



関連する要素の状態遷移の自動化が時間を節約する場合、多くのシナリオを思いつくことができます。 標準スキームでは、状態が変化すると、同じワークアイテムに属するフィールドを変更することができますが、これでは十分ではありません。



たとえば、ユーザーストーリーにすべてのアーティファクトがあり、動作する準備ができている状況を想像してください。このストーリーを実装するために特定のタスクが作成されています。 この状況では、ストーリーは開発準備完了状態にあり、すべてのタスクは提案済み状態にあります。 開発者はタスクを実行し、その状態をActiveに変更します。 次に、ストーリーの状態をWIP （Work In Progress）に変更する必要があります。 ただし、この手順は自動化できます！ そして自動化は、順番に、より大きな秩序と美をもたらします。 つまり 開発者が仕事に取りかかるとすぐに、ストーリー全体の状態が自動的に変わりました！



または、たとえば、コンポーネントの操作の新しい状況が突然明らかになったため、ストーリー全体の作業を一時停止することが決定されました。 作業にはいくつかのタスクがあり、一部はまだ開始されていませんが、一部は完了しています。 履歴を保留ステータスに転送する場合、すべてのアクティブなタスクを保留ステータスに転送する必要があります。 手動でこれを行うのは面倒ですが、自動化することもできます。 または、1つのタスクが保留状態になり、ストーリー全体が保留状態になった場合の逆の状況。







また、すべてのタスクが解決され、履歴のステータスが自動的に解決済み状態に切り替わる場合にも便利な機能になります。



また、子供から親までのさまざまなメトリックデータを自動的に計算すると便利です。 たとえば、完了した残りの作業。 または、テストおよび開発のために作業を評価するためのさまざまなフィールドがある場合、作業全体のフィールドの値を自動的に計算できます。

実装

はい、既に推測できるように、上記の目的のために、TFS 2010- TFS Aggregatorのサーバーアドオンを使用できます。 このアドオンはサーバー側で機能するため、さまざまなルールの実装は非常に迅速に行われます。 もちろん、接続が確立されてキャッシュされるため、最初の処理には7〜10秒かかります。 通常、他の更新は、クライアントを更新できるよりも速く行われます。

設置

TFS Aggregatorは、タスク実行ライブラリとXML形式の構成ファイルの2つのファイルのみで構成されています。



アドオンをダウンロードして解凍した後、両方のファイルをTFSアドオンディレクトリに転送する必要があります。 通常、次の場所にあります。C：\ Program Files \ Microsoft Team Foundation Server 2010 \ Application Tier \ Web Services \ bin \ Plugins。



以上です。 TFSは指定されたディレクトリを監視し、ファイルがコピーされると、サーバーはそれをメモリにロードします。

カスタマイズ

すべての設定はAggregatorItems.xmlファイルに含まれています。 このファイルには、接続に関する情報と、プロセスで適用されるすべてのルールに関する情報が含まれています。



そのため、AggregatorItems.xmlファイルの主要コンポーネントを検討してください。

  <？xml version = "1.0" encoding = "utf-8"？> 

ファイルヘッダーを変更する必要はありません。

  <AggregatorItems tfsServerUrl = "http：// tfs2010dev：8080 / tfs"> 

AggregatorItems ：構成のメイン要素であるルート要素。

tfsServerUrl： TFSサーバーのアドレス。



この行は、アドレスをTFSサーバーに設定します。 tfs2010 devの代わりに、アドレスをサーバーに書き込む必要があります。 もう1つ微妙な違いがあります。アドレスはプロジェクトのコレクションにつながるはずです。 プロジェクトがDefaultCollectionというデフォルトのコレクションにない場合は、コレクションの名前を指定する必要があります。 たとえば、私の場合、プロジェクトはMigrationProjectコレクションに含まれているため、行は次のようになります。

  <AggregatorItems tfsServerUrl = "http：// violet-tape-tfs：8080 / tfs / MigrationProject"> 

コレクションの名前は、プロジェクトを選択するとスタジオで確認できます。 例：

  <AggregatorItem operationType = "Numeric" operation = "Sum" linkType = "Parent" linkLevel = "2" workItemType = "Task"> 

AggregatorItem ：集約ルールを示します。

operationType ：数学演算を実行するか、テキスト変数を使用するかを決定します。 これまでのところ、数値または文字列の2つの値のみが使用可能です。 デフォルトは数値です。 数値タイプが選択されている場合、作業フィールドはdoubleまたは整数タイプである必要があります。

operation ：関係するフィールドに適用される数学演算を示します。 現在、加算、減算、乗算、除算（合計、減算、乗算、除算）のみがサポートされています。 デフォルトでは、追加が選択されています。

linkType ：親または同じ要素が集約ターゲットになるかどうかのリンクのタイプを示します。 したがって、可能な値は次のとおりです。Self、Parent。 デフォルトはSelfです。

linkLevel ：linkTypeがParentとして指定されている場合、このパラメーターは、いくつの親が上がるかを示します。 デフォルトでは、値は1です。

workItemType ：ルールが適用される作業項目（タスク、バグなど）の名前。

  <TargetItem name = "Total Estimate" /> 

TargetItem ：TFS内の更新するフィールドを示します。 単一のコピーにルールが含まれている場合があります。

name ：集計結果を対象とするTFSのフィールドの名前。

  <SourceItem name = "Estimated Dev Work" /> 

SourceItem ：データソースとなるTFSのフィールドを示します。 数回使用できます。

name ：データが取得されるTFSのフィールドの名前。

  <条件> 

条件 ：集計がトリガーされたときに満たす必要がある条件を決定します。 オプションのフィールド。

  <Condition leftField = "Finish Date" operator = "GreaterThan" rightValue = "$ NOW $" /> 

条件 ：集約が発生する条件を定義します。

leftField ：式の左オペランド。 フィールドは、ターゲット作業項目で指定されたタイプである必要があります。 workItemTypeプロパティで指定されています。

operator ：比較演算子。 文字列の場合、2つのEqualToステートメント、NotEqualToが定義されています。 数値には、LessThan、GreaterThan、LessThanOrEqualTo、GreaterThanOrEqualToなどの追加の数値が定義されています。 デフォルトでは、EqualToが使用されます。

rightValue ： leftFiledのデータと比較される値。 このプロパティを定義するか、rightFieldを定義する必要があります。 可能なマクロは、$ NOW $および$ NULL $です。

rightField ：フィールドは、ターゲット作業項目で指定されたタイプである必要があります。 左のオペランドと比較。 rightValueが指定されている場合は使用されません。

  <マッピング> 

マッピング ：文字列集計の値のリストを提供します。

  <Mapping targetValue = "Done"包括的= "And"> 

マッピング ：可能な集約の単一要素を表します。 条件が機能する場合、マッピングの結果は、targetValueからAggregationItemのTargetItemへの値のエントリになります。

targetValue ：置換に使用される値。

包括的 ：このパラメーターは、マッピングが機能するために、SourceValueセットからすべて（および）またはいずれか（Or）の値を満たす必要があるかどうかを担当します。

  <SourceValue>が削除されました</ SourceValue> 

SourceValue ：マッピングがトリガーするために満たさなければならない可能な値。





ここで、作業項目からフィールド名に言及するときは、名前空間ではなく短い名前を記述する必要があることに注意してください。



これで定義が終了し、具体的な例を検討できます。

例

履歴のWIP状態への移行に関する例から始めることができます。 この例は、最近の記事の図に基づいています。

  <AggregatorItem operationType = "String" linkType = "Parent" linkLevel = "1" workItemType = "Task">
    <TargetItem name = "State" />
    <SourceItem name = "State" />
    <マッピング>
       <Mapping targetValue = "WIP"包括的= "Or">
          <SourceValue>アクティブ</ SourceValue>
       </マッピング>
    </マッピング>
 </ AggregatorItem> 

ここでは、文字列を使用して作業が実行され、親要素を使用して、タスクレベルで変更が開始されることが示されています。 変更を分析するためのデータソースは、タスク要素（ workItemType ）のStateフィールド（ SourceItem ）であり、宛先もStateフィールド（ TargetItem ）ですが、親要素（ linkType ）です。 この場合、親はUserStory、Bug、またはその他の要素のいずれかです。 マッピングセクションでは、リソースの値がAcitveになった場合、値をWIP （ targetValue ）に変更する必要があると説明しています。



状態の遷移の条件は、内部TFSツールによって引き続きチェックされることを理解することが重要です。 このような遷移が回路に記述されていない場合、ある状態から別の状態に切り替えることはできません。 完了した説明フィールドやストーリーポイントなどの遷移条件が満たされない場合、ある状態から別の状態に切り替えることはできません。 つまり これは、オーバードライブおよび上書きワークフロー環境ではありません。 最終的な状態は、すべてのルールを考慮して、指定された状態から達成可能でなければなりません。



正直なところ、この特定の遷移では、AssignedToフィールドの値をNETWORK SERVICEにリセットしましたが、これは他の自動化された遷移では発生しません。 奇跡！ 開発者がこの問題で私を助けてくれることを願っています。そして、何が間違っていたのかをお話しします。



別の例は、すべてのタスクが完了したときに履歴がResloved状態に移行することです。

 

 <AggregatorItem operationType = "String" linkType = "Parent" linkLevel = "1" workItemType = "Task">
    <TargetItem name = "State" />
    <SourceItem name = "State" />
    <マッピング>
       <Mapping targetValue = "Resolved"包括的= "And">
          <SourceValue>解決済み</ SourceValue>
          <SourceValue>クローズ</ SourceValue>
          <SourceValue>放棄された</ SourceValue>
       </マッピング>
    </マッピング>
 </ AggregatorItem> 

ここでは、文字列を使用して作業が実行され、親要素を使用して、タスクレベルで変更が開始されることが示されています。 変更の分析のデータソースは、タスク要素（workItemType）の状態フィールド（SourceItem）であり、宛先は状態フィールド（TargetItem）でもありますが、親要素（linkType）です。 マッピングセクションでは、リソースの値がResolved、Closed、Abandonedのいずれかになった場合、値がResolved（targetValue）に変更されることを説明しています。



これらの例は私にとって非常に効果的であり、タスクを処理するときに実行する必要のあるアクションが少なくなったことは非常に素晴らしいことです。



次の例のグループはチェックしませんでしたが、それらのパフォーマンスについて特別な疑いはありません。



次の例では、開発者とテスターの推定総作業量を自動的に計算します。 結果は、タスク要素自体の[推定作業時間]フィールドに記録されます。

  <AggregatorItem operationType = "Numeric" operation = "Sum" linkType = "Self" workItemType = "Task">
    <TargetItem name = "Estimated Work" />
    <SourceItem name = "Estimated Dev Work" />
    <SourceItem name = "Estimated Test Work" />
 </ AggregatorItem> 

開発者のページにはさらに例がありますが、すべて同じです。

計画中

プロジェクトは自由時間で行われますが、開発者の計画も大規模です。 そのため、近い将来、親から子孫に集約できるようになります。 この状況では、たとえば、作成時に親から継承/コピーされたIterationPathおよびその他のものを変更する方が簡単です。



AggregatorItemsファイルエディタの作成を検討してください。



また、workItemTypeに複数の要素を指定できるようにする予定です。



たとえば、今日-5日間など、条件の値の差を使用できるようにします。 同じ計画には、数式で任意の係数を使用する可能性が含まれています。 プラグインコードは係数値の名前を持つフィールドを検索するため、現時点ではこれは不可能です。



AggregatorItemsファイルから条件を再実行しない良い方法を見つけてください。 いくつかのルールが正常に機能し、その結果、ルールが再びトリガーされるようになったとします。 今回は、変更はもう発生しておらず、すべてが順調です。 もちろん、結果は真実であるため、これは致命的ではありませんが、不要なアクションは迷惑です。

プラグインが機能しない場合

すべてを正常にアンパックし、正しいディレクトリにインストールし、必要に応じて設定ファイルを編集しましたが、うまくいきませんでした...



さて、以下はすべてが実際に正しく行われているかどうかを確認するための小さなチェックリストです。

• TFS 2010を使用しています。
• 親子リンクを含む集約ルールで言及されているすべての要素
• ルールの実行が必要なアイテムを更新しました。 TFS集約は、アイテムが更新され、ルールがこれを決定でき、すべての条件が機能した場合にのみ機能します。 将来、おそらくこの振る舞いは変わるでしょう。
• AggregatorItems.xmlファイルを更新し、サーバーに正しいアドレスを入力しました。 同時に、プロジェクトのコレクションの名前を忘れないでください。
• dllファイルとAggregatorItems.xmlファイルの両方をTFSプラグインディレクトリにコピーしました。
• 要素、ソース、およびデータシンクに正しい名前を指定しました。
• 設定ファイルはutf-8エンコードで保存されます。 メモ帳++は、彼女を「BOMなしのutf-8」と呼びます。 これは全体として重要ではありませんが、それでもなお重要です。

いずれにしても、何も機能しない場合は、いくつかの簡単なルールファイルを作成して、もう一度やり直してください。



この場合、これが機能しない場合は、作業項目の設定とAggregatorItems.xmlファイルをTFSAggregatorIssues@spamex.comの開発者にエクスポートすることをお勧めします。

合計

私はプラグインが本当に好きだったので、自分のニーズに合わせて設定しましたが、今ではその仕組みに満足しています。 AssignedToフィールドの変更に関する開発者からの情報を取得するだけであり、一般的にすべてが非常に良いでしょう。