次の方法で共有


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

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

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

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

重要

継承プロセス モデルは、それをサポートするように構成されたプロジェクトで使用できます。 古いコレクションを使用している場合は、プロセス モデルの互換性を確認してください。 オンプレミスのコレクションがオンプレミスの XML プロセス モデルを使用するように構成されている場合は、そのプロセス モデルのみを使用して作業追跡エクスペリエンスをカスタマイズできます。 詳細については、「プロジェクト コレクションのプロセス モデルを選択する」を参照してください 。

前提条件

Azure DevOps のワークフロー状態にルールを適用するには、特定のアクセス許可とアクセス レベルが必要です。

  • アクセス許可:

    • プロジェクト レベルでセキュリティ グループとアクセス許可を管理するにはプロジェクト管理者になります。これには、ワークフローの状態に関する規則の設定が含まれます。
    • 作業項目追跡アクセス許可を持ちます。これにより、作業追跡領域を管理できます。この領域は、プロジェクト管理者グループのメンバーに付与することも、特定のアクセス許可を使用して付与することもできます。
  • アクセス レベル:

    • Basic アクセス権を持つことは、通常、作業項目を管理し、ワークフローの状態にルールを適用する必要があるほとんどのユーザーに十分です。

ワークフロー ルールを理解する

次の表は、定義できるワークフロー ルールの 3 つのグループの概要を示しています。

  1. 標準アクション:

    • 作業項目が作成されたとき、選択した状態にある場合、またはある状態から別の状態に移動されたときに適用されます。
    • アクションには、フィールドの値の設定、フィールドの読み取り専用の設定、フィールドの必須設定などがあります。
    • 1 つまたは 2 つの条件と複数のアクションを指定できます。
  2. 状態遷移の制限 (グループ 1):

    • 作業項目の移動の状態を示す 1 つの条件を指定します。
    • その状態から他の状態への遷移を制限するアクションを定義します。
  3. 状態遷移の制限 (グループ 2):

    • 最初のグループと同様に、作業項目が移動された状態を示す 1 つの条件を指定します。
    • その状態から他の状態への遷移を制限するアクションを定義します。

次の表は、定義できるワークフロー ルールの 2 つのグループの概要を示しています。

  1. 標準アクション:

    • 作業項目が作成されたとき、選択した状態にある場合、またはある状態から別の状態に移動されたときに適用されます。
    • アクションには、フィールドの値の設定、フィールドの読み取り専用の設定、フィールドの必須設定などがあります。
    • 1 つまたは 2 つの条件と複数のアクションを指定できます。
  2. 状態遷移の制限:

    • 作業項目の移動の状態を示す 1 つの条件を指定します。
    • その状態から他の状態への遷移を制限する 1 つ以上のアクションを定義します。

Note

一部の機能では、Azure DevOps Server 2020.1 更新プログラムのインストールが必要です。 詳しくは、Azure DevOps Server 2020 Update 1 RC1 リリース ノートの Boards に関する説明をご覧ください。

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


Condition

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


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

条件、作業項目が作成される

アクション、作業項目が作成される


状態に基づいて遷移を制限する

条件、作業項目が移動される

アクション。状態に基づいてトランザクションを制限します。


状態とユーザーまたはグループのメンバーシップに基づいて、フィールドを非表示にするか、フィールドを読み取り専用または必須にする

条件、ユーザー グループ メンバーシップ

アクション。状態とメンバーシップに基づいてトランザクションを制限します。


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

条件、ユーザー グループ メンバーシップ

アクション。状態とメンバーシップに基づいてトランザクションを制限します。


Note

継承されたプロセスをカスタマイズすると、そのプロセスを使用するすべてのプロジェクトにそのカスタマイズが自動的に反映されます。 スムーズな移行を確実に行うために、組織全体でカスタマイズを実装する前にテスト プロセスとプロジェクトを作成することをお勧めします。 詳細については、「 継承されたプロセスの作成と管理を参照してください。

ワークフローの状態とルールの制限について

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

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

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

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

ワークフローの状態とルールを定義するときは、次のガイドラインに従ってパフォーマンスの問題を最小限に抑えます。

  • WIT: のルールの数を制限します。作業項目の種類 (WIT) に対して複数のルールを作成できますが、ユーザーが作業項目を追加または変更すると、より多くのルールがパフォーマンスに悪影響を与える可能性があります。 ユーザーが作業項目を保存するときに、作業項目タイプのフィールドに関連付けられているすべてのルールが検証されます。 場合によっては、規則の検証式が複雑になりすぎて SQL が評価できなくなる場合があります。
  • カスタム作業項目の種類の数を制限する: カスタム作業項目の種類の数を減らすことは、最適なパフォーマンスを維持するのに役立ちます。

ルールを定義する

ワークフローの状態に基づいてルールを定義する前に、次の要素が配置されていることを確認します。

ルールの定義の詳細については、「 カスタム ルールの追加」を参照してください。

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

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

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

この例では、開発チームは、チーム リーダーによって承認されるまでユーザー ストーリーが機能しないようにする必要があります。 既定のワークフロー状態が使用され、ユーザー設定フィールド、 Approved By、セキュリティ グループ 、 Team リード グループが追加されます。

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

アジャイル プロセス、ユーザー ストーリー、既定のワークフロー状態

ルールの要件

作業中の作業の前に承認を確保するには、次の規則を定義します。

  • 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 更新プログラム以降のバージョンが必要です。

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

ユーザー ストーリーには、次のワークフロー状態が定義されています。 NewResolved、および Removed継承された状態は非表示になります。 代わりに、 ProposedIn Review、および Cut States が使用されます。 さらに、 InvestigateDesignApproved という 3 つの状態が定義されています。 次の図に示すように、これらの状態はシーケンスに従う必要があります。

ユーザー ストーリー、ワークフローの状態

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

ルールの要件

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

都道府県 移行ルール
提案済み Research および Cut にのみ移動できます
調査 Design および Cut にのみ移動できます
デザイン ResearchApproved、および Cut にのみ移動できます
承認済み DesignActive、および Cut にのみ移動できます
アクティブです In Review にのみ移動できます
レビュー中 Active (その他の作業が見つかりました)、Closed または Cut にのみ移動できます
クローズ済みです ResearchDesignActiveIn Review に移動できます (ユーザーが作業項目をエラーで閉じた場合に使用できます)
切り取り Proposed にのみ移動できます

Note

状態遷移を制限する場合は、ユーザーがエラーで状態を移動する可能性がある場合を考慮します。 ユーザーが正常に回復できることを確認します。

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

  • 状態が Approved から Active に移動するときに、Approved By フィールドに入力する必要があります。
  • 承認者グループのユーザーのみが Approved By フィールドに入力できるようにします。
  • 状態が Cut に移動したら、Approved By フィールドをクリアします。
  • 状態が Active に移動したときに、Acceptance Criteria フィールドに入力する必要があります。

ルールの定義

前述の制限を実装するために、プロセス管理者はカスタム Approved By ID フィールド、 Authorized Approvers セキュリティ グループ、および次の規則を追加します。


ルール名

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 のキャッシュの問題に関する記事をご覧ください。

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

子作業項目の State 割り当てに基づく親作業項目の状態遷移を自動化するには、「 自動作業項目の状態遷移を参照してください。

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

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

When A work item state changes to Resolved Then Copy the value from Created By to Assigned To