TFS Power Toolsをインストールすると、VSに[ ツール ]メニューの新しい項目が表示されます。
スクリーンショットは、タスクアイテムの編集を開始するために何を行う必要があるかをすでに示しています。 [ツール]> [プロセスエディター]> [作業項目の種類]> [サーバーからWITを開きます。 この選択により、サーバー上の変更をすぐに取得できます。 一般的に、最後のメニューのすべてのアイテムは、それ自体を物語っています。最小限の実験で、それらのアクションのアイデアを得ることができます。
[サーバーからWITを開く]を選択すると、接続するTFSサーバーを選択するよう求められます。その後、プロジェクトコレクションとプロジェクト自体が表示されます。 変更を行うプロジェクトを選択する必要があります。プロジェクトを選択すると、最終ステップ、つまり編集する要素を選択する必要があります。
実験要素として、タスクを使用できます。
開くと、Task要素のフィールドの設定を含む画面が表示されますが、この段階では[ ワークフロー ]タブに注目します。
[ワークフロー]タブで、状態要素と遷移要素の標準ビューと場所を確認できます。
さて、今私たちはツールボックスに注意を払っていますが、必要な要素は2つしかないため、利用可能な要素が豊富な選択肢とあなたの心を混同することはありません。
当然、作業を始める前に、紙に描くか、希望する条件の順序と移行の理由を自分で決定して、移行ルールを決定するとよいでしょう。 前の記事によると、すでにそのような注文があると仮定します。 つまり 最後に、次のようなものを取得します。
最初に注意したいのは、初期状態の作成です。 スキームの規則に従って 、初期状態のない遷移リンク要素が 少なくとも1つ存在する必要があります 。 図では、これはProposed状態への遷移です。 この時点で、今後の状態と新しい遷移を作成し、それらを使用して回路を開始すると、困難が生じる可能性があります。 何らかの理由で、状態または状態の履歴により、回路が保存されない場合があります。 ですから、私の基本的な行動の後に、私のアドバイスはより頻繁に続くでしょう。
新しい初期状態の作成が困難な場合は、まず新しい遷移を含む中間状態を作成して保存することをお勧めします。 次に、古い初期状態を新しい要素に転送します。 ほとんどの場合、これにより問題を解決できます。 これは、TFSデータベース自体の作業項目の現在の状態が原因で発生する場合もあります。
簡単なものから始めましょう。Hold状態を状態図に追加します。 ツールバーで[状態]を選択し、便利な場所にドラッグします。 一般に、線が交差しないように要素を配置しようとすると、読みにくくなります。
状態項目をドラッグした後、状態の名前をダブルクリックできます。 ただし、正確かつ注意してください。 名前の外側をダブルクリックすると、ルールエディターが開き、ワークアイテムのフィールドに入力されます。 [状態]フィールドでタスクを編集すると、入力した名前が表示されます。 この段階では、他のフィールドがこの状態になったときに、他のフィールドの状態を変更する必要はありません。そのため、移行を進めることができます。
[遷移リンク]を選択し、遷移の開始点と終了点を選択します。
新しい遷移要素が表示されます。 ここで回路を保存しようとすると、エラーが2つでも表示されます。
私が注目したい「主な」エラーは次のとおりです：少なくとも1つの理由を追加するために、Open Transition Hold〜Activeを開きます。 2番目のエラーも重要であり、到達できない状態であることを示します。 したがって、 状態への各遷移には、遷移の理由が必要です。
このエラーを解消するには、遷移要素のタイトルをダブルクリックして、次のウィンドウが表示されるようにします。
このウィンドウはモーダルではないため、他のウィンドウの背後で簡単に失われることに注意してください。 また、他のスタジオウィンドウのように、タスクバーのスタジオアイコンに「スナップ」しません。 以下のスクリーンショットをご覧ください。
Wordのように二重境界線がないことに気付くかもしれません。 トランジション編集ウィンドウは開いていますが。
したがって、表示されるウィンドウには、必要なデータを入力できる2番目の[ 理由 ]タブが必要です。
[ 編集 ]をクリックするか、選択した行をダブルクリックして、値を編集できます 。 インターフェイスからわかるように、デフォルト値を指定できます。 編集を開始すると、新しい画面が最初の画面と完全に一致して重なり合うサイズで表示されます。 また、モーダルではなく、これらのウィンドウはすべて非常に簡単に失われます。
まだ2番目のブックマークは必要ありません。 しかし、その上で、タスクの他のフィールドにいくつかのルールを設定できます。
適切なボタンを押すと、移行の新しい理由/条件が追加/削除されます。
デフォルト値の切り替えはこの画面からは実行されませんが、条件編集モードに入る必要があります。
この場合、「デフォルトで」マーカーを持つ2つの要素の存在の検証は行われないため、注意してください。 結果は次のようなものです。
ここで、アクティブからホールドへの移行をもう1つ追加し、条件を設定しました。 その後、すべてが保存されます。
ある状態から別の状態への遷移でさらに考えられる変更を検討してください。 ホールド状態からアクティブ状態への移行後、と仮定します。 いくつかのフィールドの値を変更したり、それらの不変性を保証したいとします。
これを行うには、編集のために遷移要素を再度開き、[ フィールド ]タブに移動します。
新しいフィールドを追加すると、入力するフィールドを選択できる新しい画面が表示されます。 スクリーンショットでは、緑のフィールドはかなり難しい条件を作成するためにマークされ、赤のフィールドは基本的なチェックのみが可能です。 残念ながら、ほとんどのルールは科学的な突っ込みによってチェックされます。
たとえば、ある状態から別の状態への移行中にAreaPathフィールドの値が失われないようにします。 これを行うには、ドロップダウンリストから目的のフィールドを選択します。
ルールの編集に進みます。
ルールを選択します
次に、どのユーザーグループを操作するかを尋ねるウィンドウが表示されます。 フィールドを空のままにすると、すべての人に機能します
次に、すべてのウィンドウが消えるまで[OK]を押します。 その結果、スクリーンショットのようにビューを取得します。
保存しようとすると、そのような警告が表示されます。
これを克服することは、可能であれば困難であり、追加のライブラリを作成する必要がありますが、これまではこれを行いませんでした。 それに、さらに、TFS Aggregatorのような他の手段を使用して整理することもできます。 むしろ、別の記事のトピックです。 ただし、 Microsoft.VSTS。* Spaceのすべてのフィールドでは、ルールは機能します。 これを確認するには、他の条件を調べます。 一般的な実験のためのフィールドがあります！
熱心な経験豊富な読者は、おそらくアクションフィールドがいくつかのトランジションで満たされていることに気づきました。チェックインを実行すると、エレメントは自動的に別の状態に切り替わります。 残念ながら、デフォルトでは、 Microsoft.VSTS.Actions.Checkinイベントのみが利用可能です。 これらのイベントは、他のTFSコンポーネントをトリガーするためのマーカーにすぎません。 残念ながら、MSDNには、イベントを実装する方法、そのような値に対応する独自のコンポーネントを記述する方法、および遷移のアクションセクションからそのような値を読み取る方法に関する情報がありません。 それは役に立ちますが。 たとえば、ジュニア開発者がメインブランチのコードをチェックせずに、シェルフにコードを置くと、その結果、タスクはレビューが必要な状態になります。
一般に、これは状態図を設定するためのほとんどすべての可能性です。 それ以外はすべて、これらのアクションの繰り返しです。 これが、開発プロセスを改善するためのアイデアの実装に役立つことを願っています。