ワークフローの状態にルールを適用する (継承プロセス)

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

作業項目の種類のワークフロー状態を追加または変更した後、ワークフローの状態の変更に応じて適用される 1 つ以上のルールを定義できます。 ワークフロー状態にルールを追加すると、次のシナリオがサポートされます。

• 承認プロセスをサポートする
• 承認されていないユーザーが無効な状態を設定できないようにする
• State の変更に基づいてフィールドを必須または読み取り専用またはその他の値にする
• ある状態から別の状態への移行を制限する
• 特定のユーザーまたはグループへの状態遷移を制限または許可する
• 監査要件をサポートするために制御されたワークフロー プロセスを維持する
• 親作業項目のクローズを自動化する

ワークフローの状態を変更するときに適用されるルールを定義する方法については、この記事を参照してください。

• ワークフロー ルールの種類を理解する
• ワークフローの状態とルールの制限とベスト プラクティス
• フィールド値を設定するか、状態の選択に基づいてフィールドを読み取り専用または必須にする
• 状態遷移の制限
• 特定のユーザーまたはグループへの状態遷移を制限または許可する
• 親作業項目の状態遷移を自動化する

重要

この記事は、Azure DevOps Services および Azure DevOps Server 2019 以降のバージョンに適用されます。 TFS 2018 以前のコレクションで定義されているプロジェクトをカスタマイズするには、「 オンプレミス XML プロセス モデル」を参照してください。

ワークフロー ルール

次の表は、定義できるワークフロー ルールの 3 つのグループを示しています。 最初のグループは、作業項目が作成されたとき、選択した状態にある場合、またはある状態から別の状態に移動されたときに、標準アクションを適用します。 これらの標準アクションは、フィールドの値を設定するか、フィールドを読み取り専用または必須にします。 このグループでは、1 つまたは 2 つの条件と複数のアクションを指定できます。

2 番目と 3 番目のグループでは、状態遷移の制限がサポートされています。 これら 2 つのグループを使用すると、作業項目が移動した状態を示す条件を 1 つだけ指定できます。 その後、1 つ以上のアクションを指定して、その状態から他の状態への移行を制限できます。

---

Condition

サポートされているアクション

---

フィールド値を設定するか、状態に基づいて読み取り専用/必須にする

---

ユーザーまたはグループメンバーシップに基づいて、フィールド属性を設定するか、状態遷移を制限します

---

注意

継承されたプロセスをカスタマイズすると、そのプロセスを使用するすべてのプロジェクトが、カスタマイズを反映するように自動的に更新されます。 このため、カスタマイズをorganizationにロールアウトする前にテストするために行うカスタマイズが多数ある場合は、テスト プロセスとテスト プロジェクトを作成することをお勧めします。 詳細については、「 継承されたプロセスの作成と管理」を参照してください。

ワークフローの状態とルールの制限

次の表は、継承プロセスに対するワークフローの状態とルールの上限をまとめたものです。

Object	継承の上限
プロセスに対して定義された作業項目の種類	64
作業項目の種類に対して定義されたワークフローの状態	32
作業項目の種類に対して定義されたルール	1024

ワークフローの状態とルールを定義する際には、パフォーマンスの問題を最小限に抑えるために、次のガイダンスを検討することをお勧めします。

• WIT に対して定義するルールの数を最小限に抑えます。 1 つの WIT に対し複数のルールを作成できますが、ルールの追加は、ユーザーが作業項目を追加したり変更するときにパフォーマンスに悪影響を与える可能性があります。 ユーザーが作業項目を保存すると、その作業項目の種類のフィールドに関連付けられているすべてのルールが検証されます。 特定の条件下では、ルールの検証式が複雑になり SQL で評価できません。
• 定義するカスタム WIT の数を最小限に抑えましょう。

ワークフロー ルールは、次のいずれかのインターフェイスを使用して作業項目を追加または変更するときに適用されます。

• Web ポータル: 作業項目フォーム、一括更新、クエリ ビューでの更新
• Web ポータル: かんばんボードまたはタスクボード、作業項目を列に移動する
• Visual Studio 2017 以前のバージョンの作業項目フォーム
• CSV ファイル形式: 一括インポートまたは更新
• Excel: 一括インポートまたは更新
• REST API: 作業項目を追加または変更する

ルールを定義する

ワークフローの状態に基づいてルールを定義する前に、まず次の要素を定義してください。

• ワークフローのカスタマイズに関するページの説明に従って、必要なワークフローの状態
• ルールでユーザー設定フィールドの指定が必要な場合は、「フィールドの追加と管理」の説明に従って、そのフィールドを作業項目の種類に追加します。
• ユーザーまたはグループのメンバーシップに基づいて変更を許可または制限するためのセキュリティ グループの指定が規則で必要な場合は、「ユーザーまたはグループを追加または削除する」の説明に従って、そのセキュリティ グループを定義し 、セキュリティ グループを管理します。

ルールの定義の基本については、「 カスタム ルールを追加する」を参照してください。 その記事で定義されている前提条件を満たしている必要があります。

フィールド値を設定するか、フィールドを読み取り専用または必須にする

ルールの最初のグループ化では、ルールごとに 1 つまたは 2 つの条件と最大 10 個のアクションを指定できます。

アクティブな作業の前にチーム リーダーの承認を確保する例

この例では、開発チームは、チーム リーダーによって承認されるまで、ユーザー ストーリーが機能しないようにしたいと考えています。 既定のワークフロー状態は使用中であり、1 つのユーザー設定フィールド ( 承認済みユーザー)、およびセキュリティ グループ (チーム リード グループ) のみが追加されます。

既定のワークフローの状態

ルールの要件

アクティブな作業の前に承認を確保するには、次の規則を定義する必要があります。

• [状態] が [新規] から [アクティブ] に移動したときに、[承認済みユーザー] フィールドに入力する必要がある
• チーム リード グループに属していないユーザーを [承認済みユーザー] フィールドに入力するように制限する
• [状態] が [新規] または [削除済み] に移動したときに [承認済み] フィールドをクリアする

ルールの定義

ルールの要件は、次の 4 つのルール定義に変換されます。

   

---

ルール名

Condition

アクション

---

[承認済み] [新規] の場合はクリア済み

いつ A work item state changes to New

そうしたら Clear the value of Approved By

[削除時に承認済み] クリア済み

いつ A work item state changes to Removed

そうしたら Clear the value of Approved By

承認済み (読み取り専用)

いつ Current user is not member of group Team Leads Group

そうしたら Make read-only Approved By

承認済み必須

いつ A work item state changes from New to Active

そうしたら Make required Approved By

---

状態遷移の制限

条件 を指定する場合は、 A work item state moved from ...その条件のみを指定できます。 最大 10 個のアクションを指定できます。

状態遷移と承認済み状態の制限の例

ビジネス グループで使用される用語に従って、次のワークフロー状態がユーザー ストーリーに対して定義されます。 [新規]、[解決済み]、[削除済み] の各継承状態は非表示になります。 代わりに、[ 提案]、[ レビュー中]、[ 切り取り 状態] が使用されます。 さらに、3 つの追加の状態 ( 調査、 設計、 承認済み) が定義されています。 これらの状態は、次の図に示すように、シーケンスに従う必要があります。

制限なしに、ユーザーは 1 つの State から他の State に移動できます。これは、シーケンス内で前方と後方の両方です。

ルールの要件

より制御されたワークフローをサポートするために、ビジネス グループは、User Story 作業項目の種類で次の前方および逆の状態遷移をサポートするルールを設定することにしました。

• 提案されたは、研究とカットにのみ移動できます
• リサーチはデザインとカットにのみ移行できます
• デザインは、リサーチ、承認済み、カットにのみ移行できます
• 承認済みでは、[デザイン]、[アクティブ]、[切り取り] にのみ移動できます
• [アクティブ] は [レビュー中] にのみ移動できます
• [校繂] で [アクティブ] (追加の作業が見つかりました)、[閉じた] または [切り取り] にのみ移動できます
• クローズすると 、[ リサーチ]、[ デザイン]、[ アクティブ]、[ レビュー中 ] に移動できます (ユーザーが作業項目をエラーで閉じた場合に使用できます)
• [切り取り ] は [提案済み] にのみ移動できます。

注意

状態遷移を制限する場合は、ユーザーがエラーで状態を移動する場合を考慮してください。 ユーザーが正常に回復できるようにする必要があります。

さらに、ビジネス グループは必須フィールドにルールを適用する必要があります。

• [状態] が [承認済み] から [アクティブ] に移動したときに、[承認済みユーザー] フィールドに入力する必要がある
• [承認済み承認者] グループに属するユーザーのみが [ 承認済み ユーザー] フィールドに入力できるようにする
• [状態] が [切り取り] に移動したときに [承認済み] フィールドをクリアする
• 状態が [アクティブ] に移動したときに[同意条件の入力を必須にする]

ルールの定義

上記の制限を実装するために、プロセス管理者はカスタム の [承認済み ID] フィールド、 承認済み承認者 セキュリティ グループ、および次の 11 個の規則を追加します。

   

---

ルール名

Condition

アクション

---

提案された状態

いつ A work item state moved from Proposed

そうしたら Restrict the state transition to Design
および Restrict the state transition to Approved
および Restrict the state transition to Active
および Restrict the state transition to In Review
および Restrict the state transition to Closed

調査の状態

いつ A work item state moved from Research

そうしたら Restrict the state transition to Proposed
および Restrict the state transition to Approved
および Restrict the state transition to Active
および Restrict the state transition to In Review
および Restrict the state transition to Closed

デザインの状態

いつ A work item state moved from Design

そうしたら Restrict the state transition to Proposed
および Restrict the state transition to Research
および Restrict the state transition to Active
および Restrict the state transition to In Review
および Restrict the state transition to Closed

承認済みの状態

いつ A work item state moved from Approved

そうしたら Restrict the state transition to Proposed
および Restrict the state transition to Research
および Restrict the state transition to Design
および Restrict the state transition to In Review
および Restrict the state transition to Closed

アクティブ状態

いつ A work item state moved from Active

そうしたら Restrict the state transition to Proposed
および Restrict the state transition to Research
および Restrict the state transition to Design
および Restrict the state transition to Approved
および Restrict the state transition to Closed

レビュー状態

いつ A work item state moved from In Review

そうしたら Restrict the state transition to Proposed
および Restrict the state transition to Research
および Restrict the state transition to Design
および Restrict the state transition to Approved

クローズ状態

いつ A work item state moved from Closed

そうしたら Restrict the state transition to Proposed
および Restrict the state transition to Cut

切り取り状態

いつ A work item state moved from Cut

そうしたら Restrict the state transition to Research
および Restrict the state transition to Design
および Restrict the state transition to Approved
および Restrict the state transition to Active
および Restrict the state transition to In Review
および Restrict the state transition to Closed

承認済み状態の必須フィールド

いつ A work item changes from Approved to Active

そうしたら Make required Acceptance Criteria
および Make required Approved By

承認された承認者

いつ Current user is not a member of Authorized Approvers

そうしたら Make read-only Approved By

[承認済み] フィールドをクリアする

いつ A work item state changes to Cut

そうしたら Clear the value of Approved By

---

状態遷移の制限を確認する

プロセスに対してルールが定義され、プロジェクトがプロセスで更新されたら、ブラウザーを更新し、作業項目フォームとかんばんブラウザーから操作をチェックします。

前の表で定義したルールについては、次の [状態] ドロップダウン メニューが表示されます。 かんばんボードを開き、ある状態から別の状態に移動する機能をチェックします。

提案	研究	設計	Approved
アクティブ	レビュー中	解決済み	切り取り

ユーザーまたはグループのメンバーシップに基づいて状態遷移を制限する

ユーザーまたはグループメンバーシップに基づいて 2 つの条件のいずれかを指定する場合、 Current user is member of group ... または Current user is not member of group ...を指定できる条件は 1 つだけです。 また、アクション Restrict the transition to state...を指定する場合は、1 つのアクションのみを指定できます。

注意

作業項目は、それらに適用されるルールの対象となります。 ユーザーまたはグループのメンバーシップに基づく条件付きルールは、Web ブラウザー用にキャッシュされます。 作業項目の更新が制限されている場合は、これらのルールのいずれかが適用されている可能性があります。 自分には当てはまらない問題が発生したと思われる場合は、作業項目フォームでの IndexDB のキャッシュの問題に関する記事を参照してください。

親作業項目の状態遷移を自動化する

子作業項目に対して行われた状態の割り当てに基づいて親作業項目の状態遷移を自動化するには、Web フックを追加し、 状態遷移の自動化 GitHub プロジェクトで提供されているコードと構成を使用できます。

注意

状態遷移の自動化 GitHub プロジェクトは、Azure Boardsのサポートされている機能ではありません。そのため、製品チームではサポートされていません。 これらの拡張機能を使用する際の質問、提案、または問題については、GitHub プロジェクト ページで発生させます。

状態変更に基づいて再割り当てを自動化する

アジャイル プロセスのバグ作業項目の種類には、以前、バグを作成したユーザーに再度割り当てるルールがありました。 このルールは、既定のシステム プロセスから削除されています。 次の条件とアクションを使用して、ルールを復元したり、他の作業項目の種類と同様のルールを追加したりできます。

いつA work item state changes to[解決済み] の [Copy the value from 作成者] を [割り当て先] に設定します。

関連記事

注意

継承されたプロセスに加えられた変更は、監査ログを通じて確認できます。 詳細については、「 監査ログへのアクセス、エクスポート、フィルター処理」を参照してください。

• ワークフローのカスタマイズ
• カスタムルールを追加する
• 作業項目フォームのキャッシュ