次の方法で共有

作業の追跡をサポートするためのパイプラインの構成

  • [アーティクル]

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

パイプラインを使用した Azure DevOps Services 全体の統合と追跡可能性をサポートするために、いくつかのオプションを構成できます。 パイプラインの状態を報告したり、ステータス バッジの構文をコピーしたり、ビルドとリリースへの作業項目の自動リンクを設定したりできます。

サポートされているパイプラインと作業追跡の統合機能

ユーザー ストーリーと機能の開発サイクルを進めていくと、いくつかの機能でエンド ツー エンドの追跡可能性がサポートされるようになります。 Azure Repos と同様に、[ビルド]、[ビルドに統合]、および [リリース時に統合] というリンクの種類を使用して、作業項目をパイプライン オブジェクトにリンクできます。 [リリース環境で統合] リンクは、Classic リリース パイプラインの [リリース状態を Boards に報告する] オプションが有効化されている場合のみ作成できます。

作業項目を Azure Pipelines オブジェクトにリンクするリンクの種類の概念図。

次の表は、Azure Boards と Azure Pipelines との間の統合ポイントをまとめたものです。 オプションと構成手順は、YAML パイプラインと Classic パイプラインのどちらを構成するか、および Azure DevOps のバージョンによって異なります。 特に明記されていない限り、ほとんどのオプションは、Azure Repos Git リポジトリに対して実行されるパイプラインでサポートされています。

機能

説明

サポートされているバージョン

作業項目をビルドに手動でリンクする

作業項目から、同じプロジェクト内または組織内の他のプロジェクトのビルドにリンクできます。 詳細については、「別のオブジェクトからの作業項目にリンクする」を参照してください。

すべてのバージョン

作業項目からリンクされているビルドを表示する

[リンク] タブでは、手動または自動で作業項目にリンクされているすべてのビルドを確認できます。詳細については、「別のオブジェクトから作業項目にリンクする」、「リンクされたオブジェクトの一覧を確認する」を参照してください。

すべてのバージョン

作業項目をビルドに自動でリンクする

"ビルドで統合された" リンクで開発コントロールを設定するために必要です。 リリースの一部である作業項目またはコミットは、成果物のバージョンから計算されます。 たとえば、Azure Pipelines の各ビルドは、一連の作業項目とコミットに関連付けられます。 詳細については、この記事で後述する「作業項目を自動リンク」を参照してください。

YAML、Azure DevOps Server 2020 以降

作業項目をリリースに自動でリンクし、デプロイ状態を作業項目に報告する (クラシックのみ)

"リリース ステージで統合された" リンクで作業項目フォームのデプロイ コントロールを設定するために必要です。 詳細については、この記事で後述する「デプロイ状態を Boards に報告する」を参照してください。

Azure DevOps Server 2020 以降

ビルドまたはリリースにリンクされている作業項目の一覧を表示する

ビルドまたはリリースに含まれる作業項目を確認して開きます。

YAML、Azure DevOps Server 2020 以降

失敗時に作業項目を作成する (クラシック)

ビルドが失敗したときに作業項目を自動で作成し、必要に応じて作業項目のフィールドの値を設定します。 詳細については、この記事で後述する「失敗時に作業項目を作成する」を参照してください。

2018 以降のバージョン

作業項目のクエリ タスク、クエリから返された一致する作業項目の数がしきい値以内であることを確認します。

このタスクを使用して、作業項目クエリによって返される一致項目の数が、構成されているしきい値内であることを確認します。 詳細については、「作業項目タスクをクエリする」、「ゲートと承認でデプロイを制御する」を参照してください。

Azure DevOps Server 2020 以降のバージョン

前提条件

  • クラシック リリース パイプラインの統合オプションを構成するには、リリースを編集するためのアクセス許可が必要です。
  • 作業項目をコミットおよびプル要求にリンクするには、作業項目に割り当てられたエリア パスについて、[このノードの作業項目の編集] アクセス許可が [許可] に設定されている必要があります。 既定では、共同作成者グループにはこのアクセス許可が設定されています。
  • 作業項目を表示するには、作業項目に割り当てられているエリア パスについて [このノードの作業項目の表示] アクセス許可を [許可] に設定している必要があります。

パイプライン設定、ビルド オプション、または統合オプションを開く

パイプライン設定を開く

YAML 定義のリリース パイプラインの場合は、[パイプライン設定] ダイアログを使用して統合を構成します。

  1. パイプラインを開き、その他のアクション を選択し、[設定] を選択します。

    パイプライン設定を開く。

    [パイプライン設定] ダイアログが表示されます。 自動リンクの詳細については、この記事で後述する「作業項目を自動リンクする」を参照してください。

    YAML パイプライン設定のダイアログ。

この設定は、Azure DevOps Server 2019 以前のバージョンでは使用できません。

自動リンクを有効にすると、大量のビルドやリリースを手動で検索しなくても、作業が組み込まれたビルドやリリースを追跡できます。 各ビルドと作業項目が正しく関連付けられると、作業項目フォームの開発制御に自動的に表示されます。 リリース ステージと作業項目が関連付けられると、作業項目フォームの開発コントロールに自動的に表示されます。

自動リンクを有効にすると、大量のビルドを手動で検索しなくても、作業が組み込まれたビルドを追跡できます。 各ビルドと作業項目が正しく関連付けられると、作業項目フォームの開発制御に自動的に表示されます。

  1. 「パイプライン設定を開く」で説明されているように、[パイプライン設定] を開きます。

  2. [このビルドの新しい作業を自動的にリンク] を有効にします。

    [パイプライン設定] ダイアログ、[このビルドの新しい作業を自動的にリンク] のスクリーンショット。

    有効にすると、各リリースの実行を伴う選択した pull request にリンクされているすべての作業項目に対して [ビルドに統合] リンクが生成されます。

この機能は、Azure DevOps Server 2019 の YAML パイプラインではサポートされていません。

自動リンクに含まれる作業項目とは

ソフトウェアを開発している際、ブランチ、コミット、または pull request を作成するときに作業項目をリンクできます。 あるいは、作業項目からの Git 開発の推進に関するページの説明に従って、作業項目からブランチ、コミット、または pull request を開始し、これらのオブジェクトを自動的にリンクすることもできます。 たとえば、ここでは、[注文の取り消し] フォームのユーザー ストーリーから新しいブランチを作成します。

作業項目フォームから表示する [ブランチの作成] ダイアログ。

作業項目をビルドに自動リンクすると、次の計算が行われます。

  • 初めてのビルドの場合:

    • ビルドに関連付けられているブランチ、コミット、pull request にリンクされているすべての作業項目を特定します。

  • 2 回目以降のビルドの場合:

    • ビルドされている現在のコミット (C1) に関連付けられているすべての作業項目を特定します。
    • 同じソース ブランチの最後に成功したビルドのコミット (C2) に関連付けられているすべての作業項目を特定します。
    • コミット ツリー内の C1 と C2 の間のコミットに関連付けられているすべての作業項目を特定します。

ビルドの失敗時に作業項目を作成する (クラシック)

ビルド パイプラインが失敗した場合、問題の修正を追跡する作業項目を自動的に作成できます。 作業項目の種類を指定し、要求者またはその他のフィールドに自動的に割り当てるオプションを設定できます。 要求者は、ビルドをトリガーしたユーザーに対応します。

ヒント

[失敗時に作業項目を作成する] オプションは、クラシック パイプラインでのみサポートされています。 これを YAML パイプラインで実現するには、[リリースの失敗時にバグを作成する] などのマーケットプレース拡張機能を使用するか、Azure CLI または REST API の呼び出しを使用して自分で実装することができます。

  1. 「ビルド プロパティ」で説明されているように、パイプラインのビルド オプションを開きます。

  2. [失敗時に作業項目を作成する] を有効にし、作成する作業項目の種類を選択します。 必要に応じて、[要求者に割り当てる] チェック ボックスをオンにして [割り当て先] フィールドを設定し、作成する作業項目内で設定するフィールドを追加します。

    たとえば、ここでは [バグ] 作業項目の種類を選択し、優先度フィールドとタグ フィールド、およびそれらの値を指定しています。

    ビルド オプションの [失敗時に作業項目を作成する] のスクリーンショット。

  3. パイプラインを保存します。

フィールドの参照名を確認するには、作業項目フィールドのインデックスから調べます。 継承されたプロセスを介して追加するカスタム フィールドの場合、Azure DevOpsは、プレフィックスが Custom. が付いた分かりやすいフィールド名に基づいて参照名を割り当てます。たとえば、DevOps Triage という名前のフィールド追加します。 参照名は Custom.DevOpsTriage です。 参照名内にスペースは使用できません。

ステータス バッジを取得または有効にする

  1. パイプラインの その他のアクションを開き、[状態バッジ] を選択します。

    YAML パイプラインの [その他のアクション] メニュー オプションのスクリーンショット。

  2. 目的のブランチとスコープを選択し、[クリップボードにコピー] を選択してイメージまたは Markdown 構文をコピーします。

    YAML パイプラインの [状態バッジ] のスクリーンショット。

リポジトリのホストに配置の状態を報告する (クラシック)

コードが Azure Repos Git リポジトリに格納されている場合は、Azure Repos ページにバッジを表示するようにリリース パイプラインを構成できます。 バッジは、特定のコミットがデプロイされた場所と、デプロイが成功しているか失敗しているかを示します。 このオプションを選択すると、コードのコミットからデプロイまでの追跡可能性が向上します。

クラシック パイプラインの統合オプションのスクリーンショット。展開の状態をリポジトリ ホストに報告します

デプロイの状態は、Azure Repos の次のセクションに表示されます。

  • ファイル: 選択されたブランチの最新のデプロイの状態を示します。
  • コミット: 各コミットのデプロイの状態を示します (継続的インテグレーション (CD) トリガーがリリースに対して有効になっている必要があります)。
  • ブランチ: 各ブランチの最新のデプロイの状態を示します。

複数のステージがある複数のリリース パイプラインにコミットがデプロイされる場合、それぞれがバッジにエントリを持ち、各ステージごとに状態が表示されます。 既定では、リリース パイプラインを作成すると、デプロイの状態がすべてのステージについて通知されます。 ただし、状態バッジにデプロイの状態を表示するステージを選択することができます (たとえば、運用ステージのみを表示します)。 チーム メンバーは、状態バッジを選択して、リリース パイプラインの選択された各ステージの最新のデプロイ状態を表示できます。

配置の状態を Jira に報告する (クラシック)

作業項目に Jira の問題を含め、ステージ完了時にすべての問題へのリンクを作成します。 Azure Pipelines for Jira アプリを Jira Software クラウドにインストールし、組織を追加して接続します。

クラシック パイプラインの統合オプションのスクリーンショット。展開の状態を Jira に報告します

Jira 問題追跡との統合をサポートするには、Azure DevOps for Jira をインストールし Azure DevOps 組織を Jira Software インスタンスに接続します。 複数の組織を 1 つのインスタンスに接続し、すべてのチームおよび関連プロジェクトのデータを取得できます。 詳細については、「Azure DevOps を Jira に接続する」を参照してください。