Share via

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

  • [アーティクル]

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

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

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

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

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

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

機能

説明

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

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

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

すべてのバージョン

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

リンクが手動でされているか、自動でされているかにかかわらず、作業項目からリンクされているすべてのビルドを [リンク] タブから表示できます。詳細については、他のオブジェクトからの作業項目へのリンク、リンクされたオブジェクトの一覧の表示に関するページを参照してください。

すべてのバージョン

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

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

YAML、Azure DevOps Server 2020 以降
クラシック、TFS 2017.2 以降

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

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

Azure DevOps Server 2020 以降

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

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

YAML、Azure DevOps Server 2020 以降
クラシック、TFS 2017.2 以降

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

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

TFS 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 の問題を含め、ステージ完了時にすべての問題へのリンクを作成します。 JIRA Software クラウドに Jira 用 Azure Pipelines アプリをインストールし、組織を追加して接続を作成します。

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

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