次の方法で共有

pull request で作業項目を自動的に完了する

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

作業項目を pull request (PR) にリンクすると、PR が完了したときに、それらの作業項目を自動的に完了することができます。 または、PR のマージ時に作業項目を移行するワークフローの状態を指定することもできます。

この自動化により、作業項目にコード変更の現在の状態が反映され、手動による介入なしに開発ワークフローが効率化されます。

詳細については、「プル リクエストの作成、表示および管理」を参照してください。

前提条件

カテゴリ 必要条件
アクセス許可 - 作業項目を表示、フォロー、編集するには: [このノードの作業項目の表示] および [このノードの作業項目の編集] アクセス許可を [許可] に設定します。 デフォルトでは、 Contributors グループにこれらの権限が与えられます。 詳細については、「作業追跡権限を設定する」を参照してください。
- 作業項目にタグを追加するには:プロジェクト レベルで 新しいタグ定義 を作成する許可セットが 許可に設定されている必要があります。 デフォルトでは、 Contributors グループにこの権限が与えられます。
アクセスレベル - プロジェクト メンバー。
- 作業項目に新しいタグを追加したり、プル リクエストを表示またはフォローしたりするには: Basic 以上のアクセス レベル。
- 作業項目を表示またはフォローするには: 少なくとも ステークホルダー アクセスが必要です。 詳細については、「アクセス レベルについて」を参照してください。
- 閲覧者 グループのメンバーを含むすべてのプロジェクト メンバーは、作業項目を含む電子メールを送信できます。
GitHub のアクセス許可 GitHub リポジトリの寄稿者 です。

作業項目の自動完了

プル要求をマージするときにリンクされた作業項目の自動完了を有効にするには、次の図に示すように、 結合後にリンクされた作業項目を完了するチェック ボックスをオンにします。 選択内容は、将来の PR の既定値として保存されます。

Pull request 完了ダイアログ、マージ後にリンクされた作業項目を完了する

自動完了が発生しない場合

次の状況では、作業項目の種類 (WIT) の作業項目の状態は自動的に [完了]、[ 終了]、または [完了 ] カテゴリに更新されません。

  • 既に解決済みの状態の作業項目: WIT が継承プロセス モデルを使用する作業項目は、既に 解決済みの 状態です。 この場合、システムは状態を更新しません。 たとえば、アジャイル プロセスから派生したバグが、[解決済み] 状態の場合、システムは、状態を [クローズ] 状態に変更しません。
  • 作業項目は既に完了しています: 作業項目は既に 完了 状態カテゴリにあります。 これ以上遷移は必要ありません。
  • ワークフロー ルールは遷移を防ぎます。WIT には、作業項目が次の状態に進むのを妨げるワークフロー フィールド ルールが含まれています。 たとえば、ルールでは、作業項目を閉じるときに別のフィールドを定義する必要がある場合があります。
  • オンプレミスのワークフロー構成: オンプレミスのデプロイと Azure Boards ホスト型プロセス モデルの場合は、ワークフローを移行するときに実行するアクション (ACTION 要素) を指定するようにワークフローを変更する必要があります。 詳細については、「WIT のワークフローを変更する」、「アクションを指定する」を参照してください。

ワークフローのカスタマイズの詳細については、「 作業追跡エクスペリエンスのカスタマイズ」を参照してください。

リンクされた作業項目のワークフロー状態を指定する

pull request の説明に情報を入力することで、作業項目を特定のワークフロー状態に切り替えることができます。 指定された作業項目に対して有効なワークフロー状態にプレフィックス #ID を付けます。 この方法では、コードの変更をマージするときに作業項目がどのように切り替わるかを正確に制御できます。

Note

この機能には、Azure DevOps Server 2020.1 更新プログラム以降のバージョンが必要です。

次の例は、1つは解決済状態に、もう1つはレビュー状態に移行するユーザーストーリーを示しています。 また、2 つのタスクも完了としてマーク されます。

pull request のスクリーンショット、ワークフローの状態を設定して #ID 作業項目を移行します。

状態遷移の構文

状態遷移を指定するには、pull request の説明で次の構文パターンを使用します。

  • Resolves #123 - 作業項目 123 を解決済み状態に切り替えます
  • Fixes #456 - 作業項目 456 を適切な完了状態に切り替えます
  • Closes #789 - 作業項目 789 を Closed 状態に切り替えます
  • Review #101 - 作業項目 101 をレビュー状態に切り替えます

システムは一般的なキーワードを認識し、作業項目の種類のワークフロー構成に基づいて適切な状態遷移を適用します。

関連付けられている作業項目の自動完了を無効にする

ユーザーがプル リクエストを完了したときに、関連付けられている作業項目の自動完了を無効にするには、次の手順を実行します。

  1. プロジェクト設定>Repositories に移動し>リポジトリを選択します。
  2. [設定] タブで、[メンション作業項目の解決をコミットする] のトグルをオフにします。

この設定を無効にすると、コミット コメントのメンションで作業項目を閉じることはできません (たとえば、「修正 #123」)。 この設定は、プル要求の完了と直接コミットメンションの両方に影響します。

ベスト プラクティス

作業項目の自動補完を使用する場合は、次のベスト プラクティスを検討してください。

  • 作業項目の状態を確認する: 自動完了を有効にする前に、作業項目の状態がチームのワークフローの期待に合っていることを確認します。
  • 特定の状態遷移を使用する: 正確な制御が必要な場合は、既定の完了動作に依存するのではなく、プル要求の説明で状態遷移構文を使用します。
  • ワークフロー ルールのテスト: カスタム ワークフロー ルールが自動状態遷移を妨げていないようにします。
  • チームとコミュニケーションを取る: すべてのチーム メンバーが、作業項目の追跡に対する自動完了の影響を理解していることを確認します。

トラブルシューティング

作業項目が想定どおりに自動的に完了しない場合:

  1. アクセス許可を確認する: 作業項目を編集するために必要なアクセス許可があることを確認します。
  2. ワークフロー ルールを確認する: 状態遷移を妨げるワークフロー フィールド ルールがないことを確認します。
  3. 作業項目のリンクを検証する: 作業項目が pull request に適切にリンクされていることを確認します。
  4. 現在の状態を確認する: 作業項目がまだ完了状態になっていないことを確認します。
  5. リポジトリ設定を確認する: リポジトリ設定で自動完了が有効になっていることを確認します。

関連コンテンツ

  • Last updated on