ワークフローの状態にルールを適用する (継承プロセス)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
作業項目の種類のワークフローの状態を追加または変更した後、ワークフローの状態の変化に応じて適用される 1 つ以上のルールを定義できます。 ワークフローの状態にルールを追加すると、次のシナリオがサポートされます。
- 承認プロセスをサポートする
- 承認されていないユーザーが無効な状態を設定できないようにする
- State の変更に基づいてフィールドを必須または読み取り専用またはその他の値にする
- ある状態から別の状態への移行を制限する
- 特定のユーザーまたはグループへの状態切り替えを制限または許可する
- 監査要件をサポートするために制御されたワークフロー プロセスを維持する
- 親作業項目のクローズを自動化する
- 承認プロセスをサポートする
- 承認されていないユーザーが無効な状態を設定できないようにする
- State の変更に基づいてフィールドを必須または読み取り専用またはその他の値にする
- ある状態から別の状態への移行を制限する
- 親作業項目のクローズを自動化する
- 承認プロセスをサポートする
- State の変更に基づいてフィールドを必須または読み取り専用またはその他の値にする
- 親作業項目のクローズを自動化する
ワークフローの状態を変更するときに適用されるルールを定義する方法については、この記事を参照してください。
- ワークフロー ルールの種類を理解する
- ワークフローの状態とルールの制限とベスト プラクティス
- [状態] の選択に基づいて、フィールド値を設定するか、フィールドを読み取り専用または必須にする
- 状態遷移を制限する
- 特定のユーザーまたはグループへの状態切り替えを制限または許可する
- 親作業項目の状態遷移を自動化する
- ワークフロー ルールの種類を理解する
- ワークフローの状態とルールの制限とベスト プラクティス
- [状態] の選択に基づいて、フィールド値を設定するか、フィールドを読み取り専用または必須にする
- 状態遷移を制限する
- 親作業項目の状態遷移を自動化する
- ワークフロー ルールの種類を理解する
- ワークフローの状態とルールの制限とベスト プラクティス
- [状態] の選択に基づいて、フィールド値を設定するか、フィールドを読み取り専用または必須にする
- 親作業項目の状態遷移を自動化する
重要
継承プロセス モデルは、それをサポートするように構成されたプロジェクトで使用できます。 古いコレクションを使用している場合は、プロセス モデルの互換性を確認してください。 オンプレミスのコレクションがオンプレミスの XML プロセス モデルを使用するように構成されている場合は、そのプロセス モデルのみを使用して作業追跡エクスペリエンスをカスタマイズできます。 詳細については、「 プロジェクト コレクションのプロセス モデルを選択するを参照してください。
ワークフロー ルール
次の表は、定義できるワークフロー ルールの 3 つのグループを示しています。 最初のグループは、作業項目が作成されたとき、選択した状態にある場合、またはある状態から別の状態に移動されたときに、標準アクションを適用します。 これらの標準アクションは、フィールドの値を設定するか、フィールドを読み取り専用または必須にします。 このグループでは、1 つまたは 2 つの条件と複数のアクションを指定できます。
2 番目と 3 番目のグループは、状態遷移の制限をサポートします。 これら 2 つのグループを使用すると、作業項目が移動した状態を示す条件を 1 つだけ指定できます。 その後、1 つ以上のアクションを指定して、その状態から他の状態への移行を制限できます。
次の表は、定義できるワークフロー ルールの 2 つのグループを示しています。 最初のグループは、作業項目が作成されたとき、選択した状態にある場合、またはある状態から別の状態に移動されたときに、標準アクションを適用します。 これらの標準アクションは、フィールドの値を設定するか、フィールドを読み取り専用または必須にします。 このグループでは、1 つまたは 2 つの条件と複数のアクションを指定できます。
2 番目のグループは、状態遷移の制限をサポートしています。 この 2 番目のグループでは、作業項目が移動した状態を示す条件を 1 つだけ指定できます。 その後、1 つ以上のアクションを指定して、その状態から他の状態への移行を制限できます。
Note
一部の機能では、Azure DevOps Server 2020.1 更新プログラムのインストールが必要です。 詳しくは、Azure DevOps Server 2020 Update 1 RC1 リリース ノートの Boards に関する説明をご覧ください。
設定できるワークフロー条件とアクションを次の図に示します。 作業項目が作成されたとき、選択した状態にある場合、またはある状態から別の状態に移動されたときに、標準アクションを適用できます。 これらの標準アクションは、フィールドの値を設定するか、フィールドを読み取り専用または必須にします。 この一連のルールでは、1 つまたは 2 つの条件と複数のアクションを指定できます。
Condition
サポートされているアクション
フィールド値を設定するか、状態に基づいて読み取り専用/必須にする
状態に基づいて遷移を制限する
状態とユーザーまたはグループのメンバーシップに基づいて、フィールドを非表示にするか、フィールドを読み取り専用または必須にする
ユーザーまたはグループメンバーシップに基づいて、フィールド属性を設定するか、状態遷移を制限します
Note
継承されたプロセスをカスタマイズすると、そのプロセスを使用するすべてのプロジェクトにそのカスタマイズが自動的に反映されます。 スムーズな移行を確実に行うために、組織全体でカスタマイズを実装する前にテスト プロセスとプロジェクトを作成することをお勧めします。 詳細については、「 継承されたプロセスの作成と管理を参照してください。
ワークフローの状態とルールの制限
次の表は、継承プロセスに対するワークフローの状態とルールの上限をまとめたものです。
Object | 継承の上限 |
---|---|
プロセスに対して定義された作業項目の種類 | 64 |
作業項目の種類に対して定義されたワークフローの状態 | 32 |
作業項目の種類に対して定義されたルール | 1024 |
ワークフローの状態とルールを定義する際には、パフォーマンスの問題を最小限に抑えるために、次のガイダンスを検討することをお勧めします。
- WIT に対して定義する規則の数を最小限に抑えます。 1 つの WIT に対し複数のルールを作成できますが、ルールの追加は、ユーザーが作業項目を追加したり変更するときにパフォーマンスに悪影響を与える可能性があります。 ユーザーが作業項目を保存すると、その作業項目の種類のフィールドに関連付けられているすべてのルールが検証されます。 特定の条件下では、ルールの検証式が複雑になり SQL で評価できません。
- カスタム作業項目の種類の数を最小限に抑えます。
ワークフロー ルールは、次のいずれかのインターフェイスを使用して作業項目を追加または変更するときに適用されます。
- Web ポータル: 作業項目フォーム、一括更新、クエリ ビューでの更新
- Web ポータル: ボードまたはタスクボード、作業項目を列に移動する
- Visual Studio 2017 以前のバージョンの作業項目フォーム
- CSV ファイル形式: 一括インポートまたは更新
- Excel: 一括インポートまたは更新
- REST API: 作業項目を追加または変更する
ルールを定義する
ワークフローの状態に基づいてルールを定義する前に、次の要素を定義します。
- ワークフローの状態は、「 ワークフローをカスタマイズする」の説明に従って行います。
- ルールでユーザー設定フィールドの指定が必要な場合は、「 フィールドの追加と管理」の説明に従って、そのフィールドを作業項目の種類に追加します
- ユーザーまたはグループのメンバーシップに基づいて変更を許可または制限するセキュリティ グループの指定が規則に必要な場合は、「 ユーザーまたはグループの追加または削除、セキュリティ グループの管理に関するページの説明に従って、そのセキュリティ グループを定義します。
ルールの定義の基本については、「 カスタム ルールの追加」を参照してください。 その記事で定義されている前提条件を満たしている必要があります。
フィールド値を設定するか、フィールドを読み取り専用または必須にする
ルールの最初のグループ化では、ルールごとに 1 つまたは 2 つの条件と最大 10 個のアクションを指定できます。
アクティブな作業の前にチーム リーダーの承認を確保する例
この例では、開発チームは、チーム リーダーによって承認されるまでユーザー ストーリーが動作しないようにする必要があります。 既定のワークフロー状態が使用され、1 つのユーザー設定フィールド ( Approved By、セキュリティ グループ Team Leads Group のみが追加されます。
既定のワークフローの状態
ルールの要件
作業中の作業の前に承認を確保するには、次の規則を定義します。
- State が New から Active に移動する場合は、Approved By フィールドに入力する必要があります
- Team リード グループに属していないユーザーを制限し割り当て者フィールドに入力します
- State が New または Removed に移動したときに、Approved By フィールドをクリアします
ルールの定義
規則の要件は、次の 4 つのルール定義に変換されます。
ルール名
Condition
アクション
承認者 新規時にクリア済み
いつ A work item state changes to New
そうしたら Clear the value of Approved By
Approved By cleared when Removed
いつ 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 個のアクションを指定できます。
Note
この機能には、Azure DevOps Server 2020.1 更新プログラム以降のバージョンが必要です。
状態遷移と承認済み状態の制限の例
ユーザー ストーリーには、次のワークフロー状態が定義されています。 New、Resolved、および Removed継承された状態は非表示になります。 代わりに、 Proposed、 In Review、および Cut States が使用されます。 さらに、 Investigate、 Design、 Approved という 3 つの状態が定義されています。 次の図に示すように、これらの状態はシーケンスに従う必要があります。
制限なしに、ユーザーは、シーケンス内の前後の両方で、1 つの状態から他の状態に移動できます。
ルールの要件
より制御されたワークフローをサポートするために、ビジネス グループは、ユーザー ストーリーの作業項目の種類に対する次の前方および逆の状態遷移をサポートするルールを設定することにしました。
- 提案 は Research と Cut にのみ移動できます
- Research は Design と Cut にのみ移動できます
- デザイン は、 Research、 Approved、および Cut にのみ移動できます。
- 承認済み は、 Design、 Active、および Cut にのみ移動できます。
- アクティブ は In Review にのみ移動できます
- レビューでは は Active (その他の作業が見つかりました)、 Closed または Cut にのみ移動できます
- クローズ は、 Research、 Design、 Active、 In Review に移動できます (ユーザーが作業項目をエラーで閉じた場合に使用できます)
- 切り取り は Proposedにのみ移動できます。
Note
状態遷移を制限する場合は、ユーザーがエラー状態で状態を移動する場合を考慮してください。 ユーザーが正常に回復できるようにしたい。
さらに、ビジネス グループは必須フィールドにルールを適用する必要があります。
- [状態] が [承認済み] から [アクティブ] に移動したときにフィールドに入力するが必要です
- 承認された承認者グループに属するユーザーのみが Approved By フィールドに入力することを許可します
- State が Cut に移動したら、Approved By フィールドをクリアします
- 状態が Active に移動するとAcceptance Criteria が入力されている必要があります
ルールの定義
上記の制限を実装するために、プロセス管理者はカスタム Approved By ID フィールド、 Authorized Approvers セキュリティ グループ、および次の 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
状態遷移の制限を確認する
プロセスに対してルールが定義され、プロジェクトがプロセスで更新されたら、ブラウザーを更新し、作業項目フォームとブラウザーから操作を確認します。
前の表で定義したルールについては、次の [状態] ドロップダウン メニューが表示されます。 ボードを開き、ある状態から別の状態に移動する機能を確認します。
提案 | 調査 | デザイン | 承認済 |
---|---|---|---|
![]() |
![]() |
![]() |
![]() |
アクティブ | レビュー中 | 終了済 | 切り取り |
![]() |
![]() |
![]() |
![]() |
ユーザーまたはグループのメンバーシップに基づいて状態遷移を制限する
ユーザーまたはグループのメンバーシップ、 Current user is member of group ...
、または Current user is not member of group ...
に基づいて 2 つの条件のいずれかを指定する場合は、1 つの条件のみを指定できます。 また、アクション Restrict the transition to state...
を指定する場合は、1 つのアクションのみを指定できます。
Note
作業項目は、それらに適用されるルールの対象となります。 ユーザーまたはグループのメンバーシップに基づく条件付きルールは、Web ブラウザー用にキャッシュされます。 作業項目の更新が制限されている場合は、これらのルールのいずれかが適用されている可能性があります。 自分には当てはまらない問題が発生したと思われる場合は、作業項目フォームでの IndexDB のキャッシュの問題に関する記事をご覧ください。
親作業項目の状態遷移を自動化する
子作業項目の状態の割り当てに基づいて親作業項目の状態遷移を自動化するには、「 自動作業項目の状態遷移を参照してください。
状態変更に基づいて再割り当てを自動化する
アジャイル プロセスのバグ作業項目の種類には、以前はバグを作成者に再割り当てするルールがありました。 既定のシステム プロセスからこの規則を削除しました。 次の条件とアクションを使用して、ルールを復元したり、他の作業項目の種類と同様のルールを追加したりできます。
When A work item state changes to
Resolved Then Copy the value from
Created By to Assigned To。
関連記事
Note
監査ログを使用して、継承されたプロセスに加えられた変更を確認します。 詳細については、「 アクセス、エクスポート、およびフィルター監査ログを参照してください。