次の方法で共有

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

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

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

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

ユーザー ストーリーと機能の開発サイクルを進めていくと、いくつかの機能でエンド ツー エンドの追跡可能性がサポートされるようになります。 Azure Repos と同様に、[ビルド]、[ビルドに統合]、および [リリース時に統合] というリンクの種類を使用して、作業項目をパイプライン オブジェクトにリンクできます。 [ リリース環境に統合] リンクを作成するには、クラシック リリース パイプラインで [ リリース状態を 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 以降

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

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

すべてのバージョン

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

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

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

前提条件

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

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

パイプライン設定を開く

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

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

    [設定] オプションを示す [その他のアクション] メニューが開いている YAML パイプラインのスクリーンショット。

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

    このビルド オプションの新しい作業項目を自動的にリンクする YAML パイプライン設定ダイアログのスクリーンショット。

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

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

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

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

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

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

ソフトウェアを開発している際、ブランチ、コミット、または 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 に接続する」を参照してください。

  • Last updated on