Azure DevOps Server 2020 リリース ノート


| Developer Community
| システム要件と互換性
| ライセンス条項
| DevOps ブログ
| SHA-1 ハッシュ |


この記事では、この記事の最新リリースに関する情報をAzure DevOps Server。

デプロイのインストールまたはアップグレードの詳細については、「Azure DevOps Serverの要件 」をAzure DevOps Serverしてください

他の製品Azure DevOps Serverダウンロードするには、ダウンロード ページ の Azure DevOps Serverを参照してください

Azure DevOps Server 2020 への直接アップグレードは、Azure DevOps Server 2019 以降Team Foundation Server 2015 以降でサポートされています。 TFS の展開が TFS 2013 以前の場合は、2020 年 2020 年にアップグレードする前に中間手順を実行Azure DevOps Serverがあります。 詳細については、「 インストール」ページ を参照してください。


Azure DevOps Server 2020.0.1 Patch 3 リリース日: 2021 年 5 月 11 日

2020.0.1 Azure DevOps Server修正プログラムをリリースしました。

  • Microsoft.TeamFoundation.TestManagement.Client を使用テスト結果データの不整合。

2020.0.1 Azure DevOps Server 2020.0.1 を使用している場合は、Azure DevOps Server 2020.0.1 Patch 3 をインストールする必要があります

インストールの確認

  • オプション 1: devops2020.0.1patch3.exe CheckInstall を実行devops2020.0.1patch3.exeは、上記のリンクからダウンロードされたファイルです。 コマンドの出力には、パッチがインストールされている、またはインストールされていないと表示されます。

  • オプション 2: 次のファイルのバージョンを [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll 確認します。 Azure DevOps Server 2020.0.1 は既定で に c:\Program Files\Azure DevOps Server 2020 インストールされます。 2020.0.1 Azure DevOps Server Patch 3 をインストールした後、バージョンは 18.170.31228.1 です。

Azure DevOps Server 2020.0.1 Patch 2 リリース日: 2021 年4月13日

注意

Azure DevOps Server 2020 を使用している場合は、まず Azure DevOps Server 2020.0.1 に更新する必要があります。 2020.0.1 をインストールしたら、Azure DevOps Server 2020.0.1 Patch 2 をインストールします。

以下を修正する Azure DevOps Server 2020.0.1 の 修正プログラム をリリースしました。

この修正プログラムの修正プログラムを実装するには、次の手順に従って、 一般的な修正プログラムのインストールAzureResourceGroupDeploymentV2 、および AzureResourceManagerTemplateDeploymentV3 タスクのインストールを実行する必要があります。

一般的なパッチのインストール

Azure DevOps Server 2020.0.1 がある場合は Azure DevOps Server 2020.0.1 Patch 2をインストールする必要があります。

インストールの確認

  • オプション 1: を実行します devops2020.0.1patch2.exe CheckInstall 。 devops2020.0.1patch2.exe は、上記のリンクからダウンロードされたファイルです。 コマンドの出力は、修正プログラムがインストールされているか、インストールされていないことを示します。

  • オプション 2: 次のファイルのバージョンを確認します。 [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll 既定では、2020.0.1 はにインストールされ c:\Program Files\Azure DevOps Server 2020 ます。 Azure DevOps Server Azure DevOps Server 2020.0.1 Patch 2 をインストールすると、バージョンは18.170.31123.3 になります。

AzureResourceGroupDeploymentV2 タスクのインストール

注意

以下に説明する手順はすべて、Windows コンピューター上で実行する必要があります。

インストール

  1. AzureResourceGroupDeploymentV2.zipパッケージをコンピューター上の新しいフォルダーに抽出します。 例: D:\tasks\AzureResourceGroupDeploymentV2

  2. ご利用のコンピューターに合わせて、Node.js 14.15.1 と npm (Node.js ダウンロードに含まれています) をダウンロードしてインストールします。

  3. 管理者モードでコマンド プロンプトを開き、次のコマンドを実行して tfx-cli をインストールします。

npm install -g tfx-cli
  1. "フル アクセス" 特権で個人用アクセス トークンを作成し、それをコピーします。 この個人用アクセス トークンは、tfx login コマンドの実行時に使用されます。

  2. コマンド プロンプトから次を実行します。 プロンプトが表示されたら、サービス URL と個人用アクセス トークンを入力します。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. 次のコマンドを実行して、サーバー上にタスクをアップロードします。 手順 1 で抽出した .zip ファイルのパスを使用します。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

AzureResourceManagerTemplateDeploymentV3 タスクのインストール

注意

以下に説明する手順はすべて、Windows コンピューター上で実行する必要があります。

インストール

  1. AzureResourceManagerTemplateDeploymentV3.zipパッケージをコンピューター上の新しいフォルダーに抽出します。 例:D:\tasks\AzureResourceManagerTemplateDeploymentV3

  2. お使いのマシンに応じて、Node.js 14.15.1 と npm (Node.js ダウンロードに含まれています) をダウンロードしてインストールします。

  3. 管理者モードでコマンド プロンプトを開き、次のコマンドを実行して tfx-cli をインストールします。

npm install -g tfx-cli
  1. "フル アクセス" 特権で個人用アクセス トークンを作成し、それをコピーします。 この個人用アクセス トークンは、tfx login コマンドの実行時に使用されます。

  2. コマンド プロンプトから次を実行します。 プロンプトが表示されたら、サービス URL と個人用アクセス トークンを入力します。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. 次のコマンドを実行して、サーバー上にタスクをアップロードします。 手順 1 で抽出した .zip ファイルのパスを使用します。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2020.0.1 Patch 1 リリース日: 2021 年 2 月 9 日

2020.0.1 Azure DevOps Server修正プログラムをリリースしました。 詳細については、ブログ記事を参照してください。

Azure DevOps Server 2020 Patch 3 リリース日: 2021 年 2 月 9 日

2020 年 2020 年Azure DevOps Server修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

Azure DevOps Server 2020.0.1 リリース日: 2021 年 1 月 19 日

Azure DevOps Server 2020.0.1 はバグ修正のロールアップです。 2020.0.1 Azure DevOps Server直接インストールするか、既存のインストールからアップグレードできます。 アップグレードでサポートされているバージョンは、Azure DevOps Server 2020、Azure DevOps Server 2019、Team Foundation Server 2012 以降です。

このリリースには、次のバグの修正プログラムが含まれています。

  • 2019 年 2019 年 Azure DevOps Server 1 月からアップグレードの問題を解決します。この問題は、アップグレード後に Git プロキシが動作を停止する可能性があります。
  • 2020 年 2020 年にアップグレードするときに、Team Foundation Server 2017 より前の非 ENU コレクションの System.OutOfMemoryException 例外を修正Azure DevOps Serverしました。 このレポートで報告された問題を 、フィードバック チケット Developer Community解決します
  • サービスが不足している場合に発生するMicrosoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll。 このレポートで報告された問題を 、フィードバック チケット Developer Community解決します
  • 2020 年 2 月にアップグレード中に Analytics で無効な列名Azure DevOps Server修正しました。 このレポートで報告された問題を 、フィードバック チケット Developer Community解決します
  • テスト ケースの結果にテスト ケースのステップを表示するときに XSS を格納します。
  • ポイントのデータを TCM に移行中のアップグレード ステップの失敗。

Azure DevOps Server 2020 Patch 2 リリース日: 2021 年1月12日

以下を修正する Azure DevOps Server 2020 の 修正プログラム をリリースしました。 詳細については、ブログ記事を参照してください。

  • テストの実行の詳細に、OpsHub 移行を使用して移行されたテストデータのテストステップの詳細が表示されない
  • ' TeamFoundation ' の初期化子で例外が発生します。 TCMLogger
  • Azure DevOps Server 2020 に移行すると、保持されていないビルドが直ちに削除されます
  • データプロバイダーの例外の修正

Azure DevOps Server 2020 Patch 1 日付: 2020 年12月8日

以下を修正する Azure DevOps Server 2020 の 修正プログラム をリリースしました。 詳細については、ブログ記事を参照してください。

  • CVE-2020-17145 : Azure DevOps Server と Team Foundation Services のスプーフィングの脆弱性

Azure DevOps Server 2020 リリース日: 2020 年10月6日

Azure DevOps Server 2020 はバグ修正のロールアップです。 これには、以前にリリースされた Azure DevOps Server 2020 RC2 のすべての機能が含まれています。

注意

Azure DevOps 2020 サーバーには、Git 仮想ファイルシステム (GVFS) で使用されるアセンブリの1つのインストールに関する問題があります。

Azure DevOps 2019 (任意のリリース) または Azure DevOps 2020 リリース候補からアップグレードする場合、以前のリリースと同じディレクトリにインストールすると、アセンブリはインストールされ Microsoft.TeamFoundation.Git.dll ません。 Microsoft.TeamFoundation.Git.dll <Install Dir>\Version Control Proxy\Web Services\bin 、、およびフォルダーを検索して、問題が発生したことを確認でき <Install Dir>\Application Tier\TFSJobAgent <Install Dir>\Tools ます。 ファイルが見つからない場合は、修復を実行して、不足しているファイルを復元できます。

修復を実行するには、 Settings -> Apps & Features Azure DevOps Server マシン/VM でにアクセスし、Azure DevOps 2020 サーバーで修復を実行します。 修復が完了したら、マシン/VM を再起動できます。

Azure DevOps Server 2020 RC2 リリース日: 2020 年8月11日

Azure DevOps Server 2020 RC2 はバグ修正のロールアップです。 これには、以前にリリースされた Azure DevOps Server 2020 RC1 のすべての機能が含まれています。

Azure DevOps Server 2020 RC1 の再リリース日: 2020 年 7 月 10 日

このフィードバック チケット を修正Azure DevOps Server 2020 RC1 Developer Communityリリースしました

以前は、Azure DevOps Server 2019 Update 1.1 から Azure DevOps Server 2020 RC1 にアップグレードした後、Web UI の Repos、Pipelines、Wiki でファイルを表示する機能は利用していけでした。 ページのこの領域内で予期しない エラーが発生したことを示すエラー メッセージが表示されています。このコンポーネントを再度読み込むか、ページ全体を更新してみてください。 このリリースでは、この問題を修正しました。 詳細については、ブログ記事を参照してください。

Azure DevOps Server 2020 RC1 リリース日: 2020 年 6 月 30 日

2020 年 1 月の新機能Azure DevOps Server概要

Azure DevOps Server 2020 では、多くの新機能が導入されています。 主な特徴:

個々のセクションに移動して、各サービスのすべての新機能を確認できます。


全般

Azure DevOps CLI の一般提供

2 月に、Azure DevOps拡張機能を導入Azure CLI。 拡張機能を使用すると、コマンドラインから Azure DevOps を操作できます。 拡張機能を向上させ、コマンドを追加するためのフィードバックを収集しました。 拡張機能が一般公開されていることをお知らせします。

Azure DevOps CLI の詳細については、 こちらのドキュメントを参照してください。

発行プロファイルを使用して、デプロイセンターから Azure Web Apps for Windows をデプロイする

これで、発行プロファイルベースの認証を使用して、デプロイセンターから Azure Web Apps for Windows をデプロイできるようになりました。 発行プロファイルを使用して Azure WebApp for Windows にデプロイするアクセス許可がある場合は、このプロファイルを使用してパイプラインをデプロイセンターのワークフローで設定できます。

Boards

タスクボードとスプリントバックログに "親作業項目" フィルターを追加する

スプリントボードとスプリントバックログの両方に新しいフィルターを追加しました。 これにより、要件レベルのバックログ項目 (左側の最初の列) を親別にフィルター処理できます。 たとえば、次のスクリーンショットでは、親が "My big feature" であるユーザーストーリーのみを表示するようにビューをフィルター処理しています。

新しい親作業項目フィルターを示すスクリーンショット。

エラー処理エクスペリエンスの向上––バグ/タスクの必須フィールド

これまで、かんばんボードから、状態の変更がトリガーされたフィールドの規則がある列から別の列に作業項目を移動した場合、カードには赤色のエラーメッセージが表示されます。これにより、作業項目を強制的に開いて根本原因を把握できます。 スプリント170では、作業項目自体を開いていなくても、赤いエラーメッセージをクリックしてエラーの詳細を確認できるようになりました。

赤色のエラーメッセージをクリックしたときに表示される [フィールドが見つかりません] ダイアログボックスを示すスクリーンショット。

作業項目のライブ再読み込み

以前は、作業項目を更新するときに、2番目のチームメンバーが同じ作業項目に変更を加えようとした場合、2番目のユーザーは変更を失います。 これで、両方とも異なるフィールドを編集している限り、作業項目に加えた変更のライブ更新が表示されます。

作業項目のライブ リロードのしくみを示す短いビデオ。

コマンド ラインからイテレーションパスとエリア パスを管理する

コマンド ラインから および コマンドを使用して、イテレーション パスとエリア パスを az boards iteration 管理 az boards area できます。 たとえば、CLI からイテレーションパスとエリア パスを対話形式で設定および管理したり、スクリプトを使用してセットアップ全体を自動化することができます。 コマンドと構文の詳細については、 のドキュメントを参照 してください

作業項目の親列を列オプションとして使用する

これで、製品バックログまたはスプリント バックログ内のすべての作業項目の親を表示するオプションが用意されています。 この機能を有効にするには、目的の バック列のオプション に移動し、[親] 列を 追加 します。

[バックログ] オプションが列のオプションされたバックログのスクリーンショット。

プロジェクトで使用されるプロセスを変更する

チームが行うのと同じ方法でツールを変更する必要があります。これで、任意のアウトオブザボックス プロセス テンプレートから他の任意のアウトオブザボックス プロセスにプロジェクトを切り替える必要があります。 たとえば、プロジェクトをアジャイルからスクラム、または Basic から Agile に変更できます。 詳細な詳細なドキュメントについては、こちらを参照 してください

[プロセスの変更] オプションが選択されている [プロジェクト] タブのスクリーンショット。

レイアウトからカスタム フィールドを非表示にする

プロセスをカスタマイズするときに、フォーム レイアウトからカスタム フィールドを非表示にできます。 フィールドは、クエリと REST API から引き続き使用できます。 これは、他のシステムと統合するときに追加のフィールドを追跡する場合に便利です。

[レイアウトから非表示にする] オプションを示すスクリーンショット。

3つの新しい Azure Boards レポートを使用して、チームの正常性に関する洞察を得る

表示できない内容を修正することはできません。 そのため、作業プロセスの状態と正常性を常に把握しておく必要があります。 これらのレポートを使用すると、重要なメトリックを簡単に追跡できるようになり、Azure Boards の労力を最小限に抑えることができます。

3つの新しい対話型レポートは、 バーンダウン累積フローダイアグラム (CFD)、 ベロシティ です。 レポートは、[新しい分析] タブで確認できます。

スプリントバーンダウン、作業のフロー、チームのベロシティなどのメトリックにより、チームの進行状況を可視化し、次のような質問に答えることができます。

  • このスプリントの残りの作業量を確認できます。 私たちは、完了することを追跡していますか。
  • 開発プロセスのどのステップが最も時間がかかっているか。 これについて何かを実行できますか。
  • 前のイテレーションに基づいて、次のスプリントに対して計画する必要がある作業量を確認できます。

注意

以前にヘッダーに表示されていたグラフは、これらの強化されたレポートに置き換えられました。

新しいレポートは完全に対話型であり、ニーズに合わせて調整できます。 新しいレポートは、各ハブの [ 分析] タブ で確認できます。

  • バーンダウングラフは、 スプリント ハブの下にあります。

    [分析] タブのバーンダウングラフのスクリーンショット。

  • 関連カードをクリックすると、[ボードバックログ] の下の [分析] タブ から CFD レポートとベロシティレポートにアクセスできます。

    [分析] タブの累積フローダイアグラムレポートとベロシティレポートのスクリーンショット。

新しいレポートでは、チームに関するより詳細な制御と情報が得られます。 次に例をいくつか示します。

  • スプリント バーンダウンとベロシティ レポートは、作業項目の数または残りの作業の合計を使用するために設定できます。
  • プロジェクトの日付に影響を与えることなく、スプリント バーンダウンの期間を調整できます。 そのため、チームが通常、各スプリント計画の最初の日を費やす場合は、グラフを一致して反映することができます。
  • バーンダウン グラフに、週末を示す透かしが表示されます。
  • [デザイン] のようなボード列を削除して、チームが制御できるフローに焦点を当てるために、このレポートを使用できます。

ストーリー バックログの過去 30 日間のフローを示す、CFD レポートの例を次に示します。

[分析] タブの [累積フロー ダイアグラム] のスクリーンショット。

ベロシティ グラフをすべてのバックログ レベルで追跡できます。 たとえば、機能とエピックの両方を追加できるのに対し、前のグラフでは要件のみをサポートしています。 特徴バックログの過去 6 回のイテレーションのベロシティ レポートの例を次に示します。

[分析] タブのベロシティ グラフのスクリーンショット。

タスクボードの列をカスタマイズする

タスクボードの列をカスタマイズするためのオプションが追加されました。 これで、列の追加、削除、名前の変更、並べ替えを行えます。

タスクボードで列を構成するには、 に移動 列のオプション。

[タスク] オプションが選択列のオプションタスクボードのスクリーンショット。

この機能は、サービスの提案に 基づいて Developer Community。

バックログで完了した子作業項目の表示と非表示を切り替える

多くの場合、バックログを絞り込むときに、完了していない項目のみを表示する必要があります。 これで、バックログで完了した子項目を表示または非表示にできます。

切り替えがオンになっている場合は、すべての子項目が完了状態であることがわかります。 トグルがオフの場合、完了状態のすべての子項目はバックログから非表示になります。

バックログの子項目を表示または非表示にする方法を示す短いビデオです。

作業項目にタグを付けるときに表示される最新のタグ

作業項目にタグを付けると、[オートコンプリート] オプションに、最近使用した最大5つのタグが表示されるようになります。 これにより、作業項目に適切な情報を簡単に追加できるようになります。

作業項目にタグを付けるときに表示される最新のタグを示すスクリーンショット。

グループメンバーシップに対する読み取り専用および必要な規則

作業項目の規則を使用すると、作業項目フィールドに特定のアクションを設定して、その動作を自動化できます。 規則を作成して、グループのメンバーシップに基づいてフィールドを読み取り専用または必要に応じて設定することができます。 たとえば、製品所有者に対して、機能の優先順位を設定する機能を付与し、他のユーザーに対して読み取り専用にすることができます。

[新しい作業項目の規則] ダイアログボックスの [条件] セクションと [アクション] セクションのスクリーンショット。

システムの候補リストの値をカスタマイズする

重要度、アクティビティ、優先度などのシステム候補リストの値をカスタマイズできるようになりました。候補リストのカスタマイズは、作業項目の種類ごとに同じフィールドに対して異なる値を管理できるようにスコープ設定されます。

システムの候補リストの値をカスタマイズする方法を示す短いビデオです。

新しい作業項目 URL パラメーター

新しい作業項目 URL パラメーターを使用して、作業項目へのリンクをボードまたはバックログと共有します。 パラメーターを URL に追加することで、ボード、バックログ、またはスプリントエクスペリエンスで作業項目ダイアログを開くことができるようになりました ?workitem=[ID]

リンクを共有しているすべてのユーザーが、リンクを共有したときと同じコンテキストで移動します。

テキストフィールドで people、work items、Pr に言及する

フィードバックをお聞きして、作業項目の説明領域 (および他の HTML フィールド) で、コメント内ではなく、ユーザー、作業項目、および作業項目に関するコメントをメンションする機能が必要だったと聞いています。 作業項目のユーザーと共同作業を行っている場合や、作業項目の説明で PR を強調表示したいが、その情報を追加する方法がなかった場合があります。 これで、作業項目のすべての長いテキスト フィールドで、ユーザー、作業項目、および PRs をメンションできます。

こちらで例を参照できます。

作業項目の [説明] 領域でユーザー、作業項目、および作業項目をメンションできる画面のスクリーンショット。

  • ユーザーのメンションを使用するには、メンションするユーザーの名前と記号 @ を入力します。 @mentions の作業項目フィールドでは、コメントに対して行うような電子メール通知が生成されます。
  • 作業項目のメンションを使用するには、署名の後に作業項目 ID またはタイトル # を入力します。 #mentions 2 つの作業項目間にリンクが作成されます。
  • PR メンションを使用するには、 を追加 します。 の後に PR ID または名前が続きます。

ディスカッション コメントに対する反応

主な目標の 1 つは、作業項目をチームの共同作業に向け合う方法です。 最近、Twitter で アンケートを実施 し、作業項目に関するディスカッションで必要なコラボレーション機能を確認しました。 コメントへの反応が投票に勝ったので、追加します。 Twitter ポーリングの結果を次に示します。

回答者の 35% Azure DevOpsコメントに対するリアクション機能が望ましいことを示す twitter ポーリングのスクリーンショット。

任意のコメントに反応を追加できます。また、2 つの方法でリアクションを追加できます。コメントの右上隅にあるスマイリー アイコンと、既存の反応の横にあるコメントの下部にあります。 必要に合わせて 6 つの反応を追加するか、1 回または 2 回だけ反応を追加できます。 反応を削除するには、コメントの下部にある反応をクリックすると削除されます。 以下では、反応を追加するエクスペリエンスと、コメントに対する反応の外観を確認できます。

コメントへの反応を追加できることを示すスクリーンショット (2 つの方法があります)。

ダッシュボードに Azure Boards レポートをピン留めする

スプリント155の更新プログラムには、 CFD レポートと Velocity レポートの更新バージョンが含まれていました。 これらのレポートは、ボードとバックログの [分析] タブで利用できます。 ダッシュボードにレポートを直接ピン留めできるようになりました。 レポートをピン留めするには、レポートの上にマウスポインターを移動し、省略記号 [...] を選択します。メニューを ダッシュボードにコピー します。

[ダッシュボードにコピー] オプションを示すスクリーンショット。

ボードバックログでロールアップを使用して親項目の進行状況を追跡する

ロールアップ列には、階層内の数値フィールドまたは子孫項目の進行状況バーや合計が表示されます。 子孫項目は、階層内のすべての子項目に対応します。 1つまたは複数の rollup 列を製品またはポートフォリオのバックログに追加できます。

たとえば、作業項目ごとに 進行状況 を示し、閉じられた子孫項目の割合に基づいて先祖作業項目の進行状況バーを表示します。 エピックの子孫項目には、すべての子機能とその子またはグランドの子作業項目が含まれます。 フィーチャーの子孫項目には、すべての子ユーザーストーリーとその子作業項目が含まれます。

バックログ内の作業項目のスクリーンショット。

Taskboard のライブ更新

変更が発生すると、タスクボードが自動的に更新されるようになりました。 他のチームメンバーが taskboard でカードを移動または並べ替えている場合、ボードはこれらの変更によって自動的に更新されます。 F5 キーを押して、最新の変更内容を確認する必要がなくなりました。

ロールアップ列のカスタムフィールドのサポート

カスタム フィールドを含む任意のフィールドでロールアップを実行できます。 ロールアップ列を追加する場合でも、クイック リストからロールアップ列を選択できます。ただし、既定のプロセス テンプレートの一部ではない数値フィールドにロールアップする場合は、次のように独自に構成できます。

  1. バックログで、[列のオプション] をクリックします。 次に、パネルで [ロールアップ列の追加] をクリックし、カスタム ロールアップを構成します

    [ロールアップ列の追加] ドロップダウン リストのスクリーンショット。

  2. [進行状況バー ] と [合計] の間選択します
  3. 作業項目の種類またはバックログ レベルを選択します (通常、バックログは複数の作業項目の種類を集計します)。
  4. 集計の種類を選択します。 作業項目の数または****合計。 [合計] では、集計するフィールドを選択する必要があります。
  5. [OK] ボタンをクリックすると、列オプション パネルに戻り、新しいカスタム列の順序を変更できます。

新しいカスタム列を示す列オプション パネルのスクリーンショット。

[OK] をクリックした後でカスタム列を編集できない点に注意してください。 変更する必要がある場合は、カスタム列を削除し、必要に応じて別の列を追加します。

条件に基づいて作業項目フォームのフィールドを非表示にする新しいルール

作業項目フォームのフィールドを非表示にするために、継承されたルール エンジンに新しいルールが追加されました。 このルールでは、ユーザー グループメンバーシップに基づいてフィールドが非表示にされます。 たとえば、ユーザーが "製品所有者" グループに属している場合は、開発者固有のフィールドを非表示にできます。 詳細については、こちらを参照 してください

カスタム作業項目の通知設定

自分やチームに関連する作業項目を最新の状態に保つことは、非常に重要です。 チームはプロジェクトを使用して共同作業を行い、すべての適切なパーティが関与していることを確認するのに役立ちます。 ただし、利害関係者によって、さまざまな作業に異なるレベルの投資が行われています。また、作業項目の状態を追跡できるようにする必要があります。

以前は、作業項目に従って変更があった場合に通知を受け取る場合、作業項目に加えられたすべての変更に対して電子メール通知を受け取ります。 フィードバックを検討した後、すべての関係者に対して作業項目の柔軟性を高めることになります。 これで、作業項目の右上隅にある [ へ] ボタンの横に新しい [設定] ボタンが表示されます。 これにより、次のオプションを構成できるポップアップが表示されます。

歯車アイコンの上にカーソルを置いた作業項目の右上隅のスクリーンショット。

通知設定 からは、3つの通知オプションから選択できます。 まず、完全なサブスクライブを解除できます。 次に、すべての作業項目の変更について通知を受け取る、完全にサブスクライブすることができます。 最後に、最上位および重要な作業項目の変更イベントについて通知を受け取ることができます。 1つだけを選択することも、3つのオプションをすべて選択することもできます。 これにより、チームメンバーはより高いレベルで作業項目に従うことができ、1回の変更が行われるたびに混乱を受けることはありません。 この機能を使用すると、不要なメールを排除し、重要なタスクに集中することができます。

[通知の設定] ダイアログボックスのスクリーンショット。 [状態の変更] オプションと [イテレーションの変更] オプションと共に選択されています。

作業項目フォームの配置制御をリリースすることをお待ちしています。 このコントロールは、作業項目をリリースにリンクし、作業項目が配置された場所を簡単に追跡できるようにします。 詳細については、 こちらのドキュメントを参照してください。

作業項目フォームの [デプロイ] コントロールを示すスクリーンショット。

CSV ファイルから作業項目をインポートする

これまで、CSV ファイルから作業項目をインポートする方法は、Excel プラグインの使用に依存しています。 この更新プログラムでは、新しい作業項目をインポートしたり、既存の作業項目を更新したりAzure Boardsから直接、ファースト クラスのインポート エクスペリエンスを提供しています。 詳細については、 のドキュメントを参照 してください

CSV ファイルから作業項目をインポートする方法を示す短いビデオ。

親フィールドを作業項目カードに追加する

親コンテキストは、作業項目カードの新しいフィールドとしてかんばんボード内で使用できます。 [親] フィールドをカードに追加し、タグやプレフィックスなどの回避策を使用する必要を回避できます。

[親] オプションが選択された作業項目カードを示すスクリーンショット。

バックログとクエリに親フィールドを追加する

親フィールドは、バックログとクエリ結果を表示するときに使用できます。 親フィールドを追加するには、列オプション ビューを使用 します。

[列オプション] セクションのスクリーンショット。[親] オプションが選択されています。

Repos

pull request のコード カバレッジ メトリックとブランチ ポリシー

これで、変更のコード カバレッジ メトリックが、pull request (PR) ビューに表示されます。 これにより、自動テストを使用して変更を適切にテストできます。 カバレッジの状態は、PR の概要にコメントとして表示されます。 ファイルの差分ビューで変更されたコード行ごとに、カバレッジ情報の詳細を表示できます。

[コード カバレッジ] (PR) ビュー内の変更のコード カバレッジ メトリックpull request示すスクリーンショット。

ファイルに追加された新しいコード行を示すプル要求の相違のスクリーンショット。

さらに、リポジトリの所有者はコードカバレッジポリシーを設定し、テストされていない大規模な変更を分岐にマージできないようになりました。 目的のカバレッジしきい値は、 azurepipelines-coverage.yml リポジトリのルートでチェックインされる設定ファイルで定義できます。カバレッジポリシーは、Azure Repos の [ 追加サービス用のブランチポリシーを構成 する] 機能を使用して定義できます。

[状態の追加] ポリシーオプションのスクリーンショット、およびオプションを選択したときに表示される [ステータスポリシーの追加] セクションが表示されます。

プル要求からコメント通知をフィルター処理する

多くの場合、プル要求のコメントは、通知によって多くのノイズを発生させる可能性があります。 コメント age、コメンター、deleted コメント、メンションされたユーザー、プル要求の作成者、ターゲットブランチ、スレッド参加者によってサブスクライブするコメント通知をフィルター処理できるカスタムサブスクリプションが追加されました。 これらの通知配信登録を作成するには、右上隅にあるユーザーアイコンをクリックし、[ ユーザー設定] に移動します。

プル要求からコメント通知をフィルター処理する方法を示すスクリーンショット。

[フィルター条件] ページと [フィールド] ドロップダウンリストの内容を示すスクリーンショット。

プル要求コメントのサービスフック

リポジトリとターゲットブランチに基づいてプル要求にコメントのサービスフックを作成できるようになりました。

新しいサービスフックサブスクリプションウィザードのスクリーンショット。

指定したパターンのファイルをブロックするポリシー

管理者は、ファイルの種類とパスに基づいて、コミットがリポジトリにプッシュされないようにポリシーを設定できるようになりました。 ファイル名検証ポリシーは、指定されたパターンに一致するプッシュをブロックします。

ファイル名の検証オプションが On に設定されている Policies セクションを示すスクリーンショット。

キーワードを使用してコミットによって作業項目を解決する

修正、修正、固定 など、キー ワードを使用して、既定のブランチに対して行われたコミットを使用して作業 項目を解決****できます。 たとえば、コミット メッセージに "この変更修正済み #476" を記述すると、コミットが既定のブランチにプッシュまたはマージされた時点で作業項目 #476 が完了します。 詳細については、こちらを参照 してください

自動レビュー担当者の粒度

以前は、グループ レベルのレビュー担当者を pull requestに追加するときに、追加されたグループから 1 つの承認だけが必要でした。 自動レビュー担当者を追加するときに、チームから複数のレビュー担当者に承認を要求pull requestポリシーを設定できます。 さらに、要求者が独自の変更を承認するポリシーを追加できます。

[レビュー担当者を自動的に含める] ダイアログ ボックスを示すスクリーンショット。

サービス アカウントベースの認証を使用して AKS に接続する

以前は、AKS デプロイ センター Azure Pipelines接続を構成するときに、接続をAzure Resource Managerしました。 この接続は、パイプラインが構成された名前空間ではなく、クラスター全体にアクセスできます。 この更新プログラムでは、パイプラインはサービス アカウントベースの認証を使用してクラスターに接続し、パイプラインに関連付けられている名前空間にのみアクセスできます。

プレビュー Markdown ファイル (pull requestの比較)

新しい [プレビュー] ボタンを使用して、マークダウン ファイルがどのように表示されるのかプレビューを 確認 できます。 さらに、[表示] ボタンを選択すると、Side-by-side diff からファイルの完全なコンテンツを 確認 できます。

プロジェクトのマークダウン ファイルを示すスクリーンショット。[表示] オプションと [プレビュー] オプションが選択されています。

手動ビルドのビルド ポリシーの有効期限

ポリシーによって、チームのコード品質と変更管理の基準が適用されます。 以前は、自動ビルドのビルド有効期限ポリシーを設定できます。 ビルドの有効期限ポリシーを手動ビルドにも設定できます。

[ビルドの有効期限] セクションが表示された [ビルド ポリシーの追加] ダイアログ ボックスのスクリーンショット。

コミット作成者の電子メールに基づいてコミットをブロックするポリシーを追加する

管理者は、コミットの作成者の電子メールが指定されたパターンと一致しないリポジトリにコミットがプッシュされないように、プッシュポリシーを設定できるようになりました。

[ポリシー] タブのすべての Git リポジトリのポリシーを示すスクリーンショット。 [作成者の電子メール検証をコミットする] オプションが [オン] に設定されています。

この機能は、 開発者コミュニティからの提案 に基づいて、同様のエクスペリエンスを提供しています。 引き続きチケットを開いたままにしておき、他にどのような種類のプッシュポリシーを表示するかをユーザーに知らせていただきます。

プル要求でレビュー対象としてファイルをマークする

場合によっては、多数のファイルに対する変更を含むプル要求を確認する必要があり、既に確認したファイルを追跡することが困難になることがあります。 これで、プル要求でレビュー対象としてファイルにマークを付けることができるようになりました。

ファイル名の横にあるドロップダウンメニューを使用するか、ファイル名をポイントしてクリックすることにより、ファイルをレビュー対象としてマークできます。

注意

この機能は、プル要求をレビューするときに進行状況を追跡することのみを目的としています。 プル要求に対する投票を表すものではないため、これらのマークはレビュー担当者にのみ表示されます。

エクスプローラーでビューが表示されているプロジェクトと、[確認済みとしてマーク] オプションが表示されているスクリーンショット。

この機能は、 開発者コミュニティからの提案に基づいて優先順位が付けられました。

Azure Repos ランディングページ用の新しい Web UI

Azure Repos 内で、最新、高速、およびモバイルに対応した新しいランディングページを試すことができるようになりました。 これらのページは、 新しい Repos ランディングページ として入手できます。 ランディングページには、プル要求の詳細、コミットの詳細、およびブランチの比較を除くすべてのページが含まれます。

Web

Azure Repos のランディングページの新しい web UI のスクリーンショット。

モバイル

Azure Repos のランディングページ用の新しいモバイル UI のスクリーンショット。

リポジトリ間のブランチポリシーの管理

ブランチ ポリシーは、重要なブランチを保護するのにAzure Reposの強力な機能の 1 つです。 プロジェクト レベルでポリシーを設定する機能は、REST APIに存在しますが、そのユーザー インターフェイスは存在しません。 これで、管理者はプロジェクト内のすべてのリポジトリに対して、特定のブランチまたは既定のブランチにポリシーを設定できます。 たとえば、管理者は、プロジェクト内のすべてのリポジトリのすべてのメイン ブランチに対して行われたすべての pull request に対して、2 人の最小レビュー担当者を要求できます。 ブランチ保護の追加 機能は、 リポジトリ プロジェクトの設定に関するページで確認できます。

[ブランチ保護の追加] ダイアログ ボックスのスクリーンショット。

新しい Web プラットフォーム変換ランディング ページ

Repos ランディング ページのユーザー エクスペリエンスを更新して、最新、高速、モバイルに対応しました。 更新されたページの 2 つの例を次に示します。今後の更新で他のページも引き続き更新します。

Web エクスペリエンス:

Web プラットフォーム変換ランディング ページのスクリーンショット。

モバイル エクスペリエンス:

モバイル プラットフォーム変換ファイル ページのスクリーンショット。

モバイル プラットフォーム変換の [コミット] ページのスクリーンショット。

Kotlin 言語のサポート

ファイル エディターで Kotlin 言語の強調表示がサポートされたのでお知らせします。 強調表示すると、Kotlin テキスト ファイルの読みやすさが向上し、エラーをすばやくスキャンして見つけるのに役立ちます。 この機能は、 の提案に基づいてDeveloper Community。

UI に表示されている Kotlin ファイルのスクリーンショット。

ドラフト pull requests のカスタム通知サブスクリプション

プル要求からの電子メール通知の数を減らすために、 ドラフト状態 で作成または更新されたプル要求に対してカスタム通知サブスクリプションを作成できるようになりました。 ドラフトプル要求の電子メールを取得したり、ドラフトプル要求から電子メールを除外したりすることで、プル要求をレビューする準備が整う前にチームに通知されないようにすることができます。

[新しいサブスクリプション] ダイアログボックスのスクリーンショット。この下書きは、フィルター条件機能にオプションとして追加されています。

PR 実用性の向上

確認するプル要求が多数ある場合は、まず、アクションを実行する必要がある場所を理解することは困難です。 プル要求の actionability を向上させるために、[プル要求] リストページで複数のカスタムクエリを作成できるようになりました。これにより、ドラフト状態など、いくつかの新しいオプションを使用してフィルター処理を行うことができます。 これらのクエリは、[自分で作成] と [自分に割り当て] に加えて、プル要求ページに個別の折りたたみ可能なセクションを作成します。 また、[プル要求リスト] ページの [投票] メニューまたはコンテキストメニューを使用して、追加したプル要求を確認することもできます。 カスタムセクションには、レビューを行った、またはレビューを拒否したプル要求に対して個別のタブが表示されるようになりました。 これらのカスタムクエリは、コレクションのホームページの [マイプル要求] タブにあるリポジトリ間で機能します。 プル要求に戻る場合は、その要求にフラグを設定して、リストの先頭に表示することができます。 最後に、オートコンプリートに設定されているプル要求には、一覧で "オートコンプリート" という pill のマークが付けられます。

パイプライン

複数ステージのパイプライン

パイプラインを管理するために、 更新されたユーザーエクスペリエンス に取り組んでいます。 これらの更新によって、パイプラインが最新で、Azure DevOps の方向と一貫性のある状態になります。 さらに、これらの更新により、従来のビルドパイプラインと複数ステージの YAML パイプラインが1つのエクスペリエンスにまとめられます。 これはモバイル対応であり、パイプラインの管理方法についてさまざまな改善をもたらします。 パイプラインの詳細、実行の詳細、パイプライン分析、ジョブの詳細、ログなど、ドリルダウンして表示できます。

新しいエクスペリエンスには、次の機能が含まれています。

  • 複数のステージの表示と管理
  • パイプライン実行の承認
  • パイプラインがまだ進行中の間は、ログにスクロールして戻る
  • パイプラインのブランチごとの正常性。

YAML での継続的デプロイ

YAML CD の機能をAzure Pipelinesしています。 CI、CD、または CI と CD を一緒に実行するために各パイプラインを構成できるよう、統合された YAML エクスペリエンスが提供されました。 YAML CD 機能では、マルチステージ YAML パイプラインを使用してすべてのコレクションで使用できるいくつかの新しい高度な機能が導入されています。 主な特徴:

構築を開始する準備ができたら、複数ステージの CI/CD パイプラインを構築するドキュメント     またはブログを参照してください。

YAML エディターでパイプライン変数を管理する

YAML エディターでパイプライン変数を管理するためのエクスペリエンスを更新しました。 YAML パイプラインで変数を追加または更新するために、クラシックエディターに切り替える必要がなくなりました。

[変数] ダイアログボックスを示すスクリーンショット。

リリースをリリースハブから直接承認する

保留中の承認に対する動作がより簡単になりました。 以前は、リリースの詳細ページからリリースを承認することができました。 リリースハブから直接リリースを承認できるようになりました。

リリースをリリースハブから直接承認する方法を示すスクリーンショット。

パイプラインの概要における Bitbucket の統合とその他の機能強化

パイプラインの作業の開始ウィザードのエクスペリエンスは、Bitbucket リポジトリで動作するように更新されました。 Azure Pipelines では、Bitbucket リポジトリの内容を分析し、実行するための YAML テンプレートを推奨します。

作業の開始ウィザードでよく寄せられる質問は、生成されたファイルの名前を変更する機能です。 現在、リポジトリのルートとしてチェックインされてい azure-pipelines.yml ます。 パイプラインを保存する前に、これを別のファイル名または場所に更新できるようになりました。

最後に、 azure-pipelines.yml その分岐からのプル要求の作成をスキップするように選択できるため、ファイルを別の分岐にチェックインするときに制御が強化されます。

パイプラインをコミットまたは実行せずに、完全に解析された YAML ドキュメントをプレビューする

プレビューは追加されましたが、YAML パイプラインでは実行モードになってい ませ ん。 これで、リポジトリにコミットせずに、または実行しなくても、YAML パイプラインを試すことができます。 既存のパイプラインとオプションの新しい YAML ペイロードが指定されている場合、この新しい API によって完全な YAML パイプラインが返されます。 今後の更新では、この API は新しいエディター機能で使用されます。

開発者向け: 次の dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview ような JSON 本文でに投稿します。

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

応答には、レンダリングされた YAML が含まれる。

YAML での Cron スケジュール

以前は、UI エディターを使用して、YAML パイプラインのスケジュールされたトリガーを指定できます。 このリリースでは、YAML ファイルで cron 構文を使用してビルドをスケジュールし、次の利点を活用できます。

  1. コードとしての構成: コードの一部としてパイプラインと共にスケジュールを追跡できます。
  2. 表現力: UI で実行できたものよりも、スケジュールを定義する際の表現力が高い。 たとえば、1 時間ごとに実行を開始する 1 つのスケジュールを指定する方が簡単です。
  3. 業界標準: 多くの開発者と管理者は、cron 構文に既に精通しています。
schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

また、cron スケジュールに関する問題を簡単に診断できます。 [パイプラインの実行] メニューの [スケジュールされた実行] では、cron スケジュールでエラーを診断するのに役立つ、パイプラインの予定されているいくつかのスケジュールされた実行のプレビューが提供されます。

[スケジュールされた実行] オプションが選択された [パイプラインの実行] メニューを示すスクリーンショット。

サービス接続 UI の更新

サービス接続を管理するために、更新されたユーザー エクスペリエンスに取り組み続け、 これらの更新によって、サービス接続エクスペリエンスが最新の状態で、サービスの接続の方向Azure DevOps。 今年の初めに、プレビュー機能としてサービス接続用の新しい UI が導入されました。 新しいエクスペリエンスを試し、貴重なフィードバックをお寄せいただきありがとうございます。

[新しいサービス接続] ダイアログ ボックスのスクリーンショット。

ユーザー エクスペリエンスの更新に加え、YAML パイプラインでサービス接続を使用する場合に重要な 2 つの機能 (パイプラインの承認と承認とチェック) も追加されました。

[承認とチェック] オプションが表示されている YAML パイプラインの [編集] メニューを示すスクリーンショット。

この更新プログラムでは、新 しいユーザー エクスペリエンスが既定 で有効になります。 プレビューをオプトアウトすることもできます。

注意

新しい機能として、 サービス接続のクロスプロジェクト共有 を導入する予定です。 共有エクスペリエンスとセキュリティロールの詳細については、 こちらを参照してください。

YAML パイプラインでステージをスキップする

手動実行を開始するときに、パイプライン内のいくつかのステージをスキップすることが必要になる場合があります。 たとえば、運用環境にデプロイしない場合、または運用環境のいくつかの環境への配置をスキップする場合などです。 これは、YAML パイプラインで実行できるようになりました。

更新された [実行パイプライン] パネルには、YAML ファイルのステージの一覧が表示されます。また、1つ以上のステージをスキップするオプションもあります。 ステージをスキップする場合は注意が必要です。 たとえば、最初の段階で、後続の段階で必要な特定の成果物が生成された場合、最初のステージをスキップしないでください。 [実行] パネルには、ダウンストリーム依存関係を持つステージをスキップするたびに、一般的な警告が表示されます。 これらの依存関係が真の成果物の依存関係であるか、または展開のシーケンス処理に対してのみ存在するかについては、お客様がそのままです。

[実行するステージ] オプションが呼び出された [パイプラインの実行] オプションを示すスクリーンショット。

ステージをスキップすることは、ステージ間で依存関係を再接続することと同じです。 スキップされたステージの即時下流の依存関係は、スキップされたステージの上流の親に依存します。 実行が失敗した場合、失敗したステージを再実行しようとすると、その試行も同じスキップ動作になります。 スキップするステージを変更するには、新しい実行を開始する必要があります。

Dev オプションと [deploy] オプションを選択して [実行するステージ] セクションを示すスクリーンショット。

既定のエクスペリエンスとしてのサービス接続の新しい UI

新しいサービス接続の UI があります。 この新しい UI は最新の設計標準をベースに構築され、承認、承認、プロジェクト間の共有など、複数ステージの YAML CD パイプラインをサポートするためのさまざまな重要な機能が付属しています。

[パイプラインの実行] ダイアログ ボックスのスクリーンショット。

サービス接続の詳細については、こちらを 参照してください

[実行の作成] ダイアログのパイプライン リソース バージョン ピッカー

[実行の作成] ダイアログでパイプライン リソースのバージョンを手動で選択する機能が追加されました。 パイプラインを別の パイプラインのリソース として使用する場合は、実行の作成時に、そのパイプラインのバージョンを選択できます。

[実行するステージ] ダイアログ ボックスのスクリーンショット。

az AZURE PIPELINES の CLI のAzure Pipelines

パイプライン変数グループと変数管理コマンド

パイプライン変数と変数グループを手動で設定する必要がある場合、YAML ベースのパイプラインをあるプロジェクトから別のプロジェクトに移植する必要があります。 ただし、パイプライン変数グループと変数管理コマンドを使用すると、パイプライン変数と変数グループの設定と管理をスクリプト化できます。このスクリプトを使用すると、バージョン管理が可能になります。パイプラインを移動して別のプロジェクトにパイプラインを移動および設定する手順を簡単に共有できます。

PR ブランチのパイプラインを実行する

PR を作成するときに、変更によってターゲット ブランチでのパイプラインの実行が破損する可能性がある場合、検証が困難になる可能性があります。 ただし、パイプラインの実行をトリガーしたり、PR ブランチのビルドをキューに入れしたりする機能を使用して、ターゲット パイプラインに対して実行することで、行っている変更を検証して視覚化することができます。 詳細 については、az pipelines runaz pipelines build queue コマンド のドキュメントを参照してください。

最初のパイプライン実行をスキップする

パイプラインを作成するときに、YAML ファイルを作成してコミットし、パイプラインの実行をトリガーしないことがあります。原因としては、インフラストラクチャの準備ができていないか、変数や変数のグループを作成および更新する必要があるためです。Azure DevOps CLI を使用すると、--skip-first-run パラメーターを指定することで、パイプラインの作成時に最初の自動パイプライン実行をスキップできます。 詳細については、 az pipeline create command のドキュメント を参照してください。

サービスエンドポイントのコマンド拡張機能

サービスエンドポイント CLI コマンドでは、azure rm と github サービスエンドポイントのセットアップと管理のみがサポートされています。 ただし、このリリースでは、サービスエンドポイントコマンドを使用して、ファイルを介して構成を提供することによりサービスエンドポイントを作成できます。また、最適化されたコマンドである az devops github および az devops service-endpoint azurerm を利用できます。 詳細については、 コマンドのドキュメント を参照してください。

デプロイ ジョブ

配置ジョブは、アプリを環境に配置するために使用される特別な種類の ジョブ です。 この更新プログラムを適用すると、デプロイジョブでの ステップ参照 のサポートが追加されました。 たとえば、一連のステップを1つのファイルで定義し、展開ジョブで参照することができます。

また、デプロイジョブに追加のプロパティのサポートを追加しました。 たとえば、次のように設定できる展開ジョブのプロパティはありません。

  • timeoutInMinutes -自動的にキャンセルされる前にジョブを実行する期間
  • cancelTimeoutInMinutes -"取り消されたタスクがある場合でも常に実行する" を終了するまでにどれくらいの時間を与えるか
  • 条件 -ジョブを条件付きで実行します
  • 変数 -ハードコードされた値を直接追加することも、 変数グループを使用して Azure key vault によってサポートされる変数グループ を参照することもできます。また、 ファイルで定義されている変数のセットを参照することもできます。
  • continueOnError - このデプロイ ジョブが失敗した場合でも、将来のジョブを実行する必要がある場合は 。既定値は 'false' です

デプロイ ジョブの詳細と、デプロイ ジョブを指定するための完全な構文については、「デプロイ ジョブ」 を参照してください

CI パイプラインに関連付けられている CD パイプライン情報を表示する

CI パイプラインをパイプライン リソースと呼ばれる CD YAML パイプラインの詳細にサポートを追加しました。 CI パイプラインの実行ビューに、新しい [関連付けられているパイプライン] タブが表示されます。このタブでは、パイプラインと成果物を使用するパイプラインの実行すべてが見えます。

CI パイプラインに関連付けられている CD パイプライン情報を示すスクリーンショット。

YAML パイプラインでの GitHub パッケージのサポート

最近、YAML パイプラインのリソースとして GitHub から NuGet パッケージと npm パッケージを使用するサポートを追加するパッケージと呼ばれる新しいリソースの種類が導入されました。 このリソースの一部として、GitHub から使用するパッケージの種類 (NuGet または npm) を指定できます。 また、新しいパッケージ バージョンのリリース時に、自動化されたパイプライン トリガーを有効にできます。 現在、サポートは GitHub からパッケージを使用する場合にのみ使用できますが、今後は、NuGet、npm、AzureArtifacts などの他のパッケージ リポジトリからパッケージを使用するようにサポートを拡張する予定です。 詳細については、次の例を参照してください。

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

注意

現在、GitHub パッケージは PAT ベースの認証のみをサポートしています。つまり、パッケージ リソース内の GitHub サービス接続の種類は PAT である必要があります。 この制限が解除された後は、他の種類の認証がサポートされます。

既定では、パッケージはジョブに自動的にダウンロードされません。そのため、リソースで定義されているパッケージを使用できる getPackage マクロが導入されました。 詳細については、次の例を参照してください。

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Kubernetes 環境のリソースビューへのリンクを追加しました。これにより、対応するクラスターの Azure ブレードに移動できます。 これは、Azure Kubernetes Service クラスターの名前空間にマップされている環境に適用されます。

Azure Kubernetes Service クラスターリンクが表示されている Kubernetes environment リソースビューのスクリーンショット。

通知配信登録のリリースフォルダーフィルター

フォルダーを使用すると、簡単に見つけやすく、セキュリティ制御するためにパイプラインを整理できます。 場合によっては、フォルダーの下にあるすべてのパイプラインで表されるすべてのリリースパイプラインのカスタム電子メール通知を構成することができます。 以前は、複数のサブスクリプションを構成するか、サブスクリプションに複雑なクエリを設定して、注目すべきメールを取得する必要がありました。 この更新プログラムを適用すると、[ 配置の完了 ] および [ 承認待ち ] イベントに release folder 句を追加し、サブスクリプションを簡略化できるようになりました。

通知配信登録のリリースフォルダーフィルターのスクリーンショット。

現在、作業項目をクラシックビルドに自動的にリンクすることができます。 ただし、これは YAML パイプラインでは実現できませんでした。 この更新により、このギャップに対処しました。 指定された分岐からのコードを使用してパイプラインを正常に実行すると、Azure Pipelines によって、実行がすべての作業項目に自動的に関連付けられます (そのコード内のコミットを通じて推論されます)。 作業項目を開くと、その作業項目のコードがビルドされた実行が表示されます。 これを構成するには、パイプラインの [設定] パネルを使用します。

複数段階の YAML パイプライン実行のキャンセルステージ

複数段階の YAML パイプラインを実行しているときに、進行中にステージの実行をキャンセルできるようになりました。 これは、ステージが失敗することがわかっている場合や、別の実行を開始する必要がある場合に役立ちます。

失敗したステージの再試行

マルチステージ パイプラインで最も要求される機能の 1 つは、最初から開始することなく、失敗したステージを再試行する機能です。 この更新プログラムでは、この機能の大部分を追加しています。

実行が失敗した場合にパイプライン ステージを再試行できます。 最初の試行で失敗したジョブと、失敗したジョブに推移的に依存するジョブはすべて、すべて再試行されます。

これは、いくつかの方法で時間を節約するのに役立ちます。 たとえば、1 つのステージで複数のジョブを実行する場合、各ステージで異なるプラットフォームでテストを実行することができます。 1 つのプラットフォームでテストが失敗し、他のプラットフォームが合格した場合は、合格したジョブを再び実行しない方法で時間を節約できます。 別の例として、ネットワーク接続が不備のため、デプロイ ステージが失敗した可能性があります。 このステージを再試行すると、別のビルドを生成する必要がなく、時間を節約できます。

この機能にはいくつかの既知のギャップがあります。 たとえば、明示的に取り消すステージを再試行することはできません。 今後の更新でこれらのギャップを解消するために取り組み中です。

複数ステージの YAML パイプラインでの承認

YAML CD パイプラインに手動承認が含まれる場合があります。 インフラストラクチャ所有者は、環境を保護し、パイプライン内のステージがデプロイされる前に手動の承認を求めることが可能です。 インフラストラクチャ (環境) とアプリケーション (パイプライン) の所有者の間でロールを完全に分離することで、特定のパイプラインでのデプロイの手動サインオフを確実に行い、すべてのデプロイで同じチェックを環境に適用する際に集中管理できます。

[リソースの追加] メニューのスクリーンショット。[チェック] オプションに下線が付きます。

dev へのデプロイを実行するパイプラインは、ステージの開始時に承認のために停止します。

デプロイが承認を待っている状態を示すスクリーンショット。

ゲートタイムアウトの制限と頻度の増加

以前は、リリースパイプラインのゲートタイムアウト制限は3日間でした。 この更新プログラムを使用すると、タイムアウト制限が 15 日 に延長され、有効期間が長くなります。 また、ゲートの頻度を 30 分 に増やしました。

Dockerfile の新しいビルドイメージテンプレート

以前は、新しいパイプラインの作成で Dockerfile の新しいパイプラインを作成するときに、イメージを Azure Container Registry にプッシュし、Azure Kubernetes サービスにデプロイすることをお勧めします。 コンテナーレジストリにプッシュする必要なく、エージェントを使用してイメージを構築できる新しいテンプレートを追加しました。

[Docker] ダイアログボックスのスクリーンショット。

Azure App Service アプリの設定を構成するための新しいタスク

Azure App Service では、アプリ設定、接続文字列、その他の一般的な構成設定などのさまざまな 設定 を使用して構成できます。 Web アプリまたはそのデプロイスロットで JSON 構文を使用して、これらの設定を一括して構成することをサポートする新しい Azure Pipelines タスク Azure App Service 設定 が追加されました。 このタスクは、他の App service タスクと共に使用して、Web アプリ、関数アプリ、またはその他のコンテナー化された App Services を デプロイ管理 、および構成できます。

[Azure App Service の設定] ダイアログボックスを示すスクリーンショット。

Azure App Service がプレビューでのスワップをサポートするようになりました

Azure App Service では、デプロイスロットでの preview とのスワップが サポートされるようになりました。 これは、アプリが実際にステージングスロットから運用スロットにスワップされる前に、運用構成でアプリを検証するための優れた方法です。 また、ターゲット/運用スロットにダウンタイムが発生しないようにすることもできます。

Azure App Service タスクで、次の新しいアクションを使用してこのマルチフェーズスワップがサポートされるようになりました。

  • プレビューでのスワップの開始 -プレビュー (複数フェーズのスワップ) でスワップを開始し、ターゲットスロット (たとえば、運用スロット) の構成をソーススロットに適用します。
  • [プレビューでのスワップの 完了] - 保留中のスワップを完了する準備ができたら、[プレビューでのスワップの完了] アクションを選択します。
  • プレビューでのスワップの取り 消し - 保留中のスワップを取り消す場合は、 [プレビューでのスワップの取り消し] を選択します。

[アクション] ドロップダウン Azure App Serviceの新しいマルチフェーズ スワップ設定を含む [管理の管理] ダイアログ ボックスを示すスクリーンショット。

成果物と成果物のAzure Container Registryレベル Docker Hubフィルター

以前は、Azure Container RegistryおよびDocker Hubの正規表現フィルターは、リリース パイプライン レベルでのみ使用できます。 これらは、ステージ レベルでも追加されました。

ステージング レベルで正規表現を使用できる画面のスクリーンショット。

YAML パイプラインでの承認の機能強化

サービス接続とエージェント プールに対する承認の構成が有効になっています。 承認については、インフラストラクチャ所有者と開発者の間のロールの分離に従います。 環境、サービス接続、エージェント プールなどのリソースに対する承認を構成することで、リソースを使用するパイプラインの実行はすべて、最初に承認が必要になります。

エクスペリエンスは、環境の承認の構成に似ています。 ステージで参照されているリソースに対して承認が保留中の場合、パイプラインの実行は、パイプラインが手動で承認されるまで待機します。

[手動承認の使用] ページと [作成] オプションが表示されている [ポリシー] タブを示すスクリーンショット。

コンテナー構造テストのサポート (Azure Pipelines

アプリケーションでのコンテナーの使用が増加するため、堅牢なテストと検証が必要です。 Azure Pipelines、コンテナー構造テスト の サポートが追加されました。 このフレームワークは、コンテナーの内容と構造を確認するための便利で強力な方法を提供します。

一緒に実行できるテストの 4 つのカテゴリ (コマンド テスト、ファイル存在テスト、ファイル コンテンツ テスト、メタデータ テスト) に基づいて、イメージの構造を検証できます。 パイプラインの結果を使用して、"進む"/"不要" の決定を行うことができます。 パイプラインを実行すると、エラーのトラブルシューティングを改善するのに役立つエラーメッセージが表示されます。

構成ファイルとイメージの詳細を入力します

コンテナーの構造のテストページを示すスクリーンショット。

テストデータと概要

概要とテストデータが使用可能であることを示すスクリーンショット。

リリースパイプラインのパイプラインデコレーター

パイプラインデコレーターを使用すると、各ジョブの開始時と終了時にステップを追加できます。 これは、コレクション内のすべてのパイプラインに適用されるため、1つの定義にステップを追加することとは異なります。

私たちは、ビルドと YAML パイプラインのデコレーターをサポートしており、ユーザーはそれらを使用してジョブのステップを一元的に制御しています。 現在、サポートもリリースパイプラインに拡張しています。 拡張機能を作成して、新しい貢献ポイントを対象とするステップを追加することができます。これは、リリースパイプラインのすべてのエージェントジョブに追加されます。

Azure Resource Manager (ARM) をサブスクリプションと管理グループレベルに展開する

以前は、リソースグループレベルへのデプロイのみがサポートされていました。 この更新プログラムを適用すると、サブスクリプションと管理グループレベルの両方に ARM テンプレートをデプロイするためのサポートが追加されました。 これにより、一連のリソースをまとめてデプロイし、別のリソースグループまたはサブスクリプションに配置することができます。 たとえば、Azure Site Recovery 用のバックアップ仮想マシンを別のリソースグループと場所にデプロイします。

複数段階の YAML パイプラインの CD 機能

これで、CI パイプラインによって発行されたアーティファクトを使用して、パイプライン完了トリガーを有効にすることができます。 複数段階の YAML パイプラインでは、 pipelines リソースとしてを導入しています。 YAML で、別のパイプラインを参照し、CD トリガーを有効にできます。

パイプライン リソースの詳細な YAML スキーマを次に示します。

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

さらに、 タスクを使用して、パイプライン リソースによって発行された成果物をダウンロード - download できます。

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

詳細については、成果物のダウンロードに関するドキュメント () を 参照してください

Kubernetes の環境に対するカナリア デプロイ戦略を調整する

アプリケーション更新プログラムの継続的デリバリーの主な利点の 1 つは、特定のマイクロサービスの更新プログラムをすばやく実稼働環境にプッシュする機能です。 これにより、ビジネス要件の変化に迅速に対応できます。 環境 は、デプロイ戦略のオーケストレーションとダウンタイムゼロ リリースの促進を可能にするファーストクラスの概念として導入されました。 以前は、ステップを順番に 1 回実行する runOnce 戦略をサポートしました。 マルチステージ パイプラインでのカナリア戦略のサポートにより、変更を小さなサブセットに徐々に展開することで、リスクを軽減できます。 新しいバージョンに対する信頼度が高まると、インフラストラクチャ内のより多くのサーバーへの展開を開始し、より多くのユーザーをそのバージョンにルーティングすることができます。

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
      - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Kuberenetes のカナリア戦略では、最初に 、postRouteTraffic の間に正常性を監視しながら、10% のポッドと 20% の変更をデプロイします。 すべてがうまくいった場合は、100% に昇格します。

環境での VM リソースのサポートと、複数のマシン間でのローリング デプロイ戦略の実行に関する早期フィードバックを探しています。 登録については、お問 い合わせください。

YAML パイプラインの承認ポリシー

YAML パイプラインでは、リソース所有者によって制御される承認構成に従います。 リソース所有者は、リソースと、リソースを使用するステージの開始前に、承認のためにリソースの一時停止を使用するすべてのパイプラインに対して承認を構成します。 SOX ベースのアプリケーション所有者は、デプロイの要求者が独自のデプロイを承認するのを制限するのが一般的です。

詳細な承認オプション を使用して、申請者の承認を必要としない承認ポリシーを構成し、ユーザーのサブセットから承認を要求することができるようになりました。

[承認の作成] ダイアログボックスを示すスクリーンショット。

ファーストクラスパイプラインリソースとしての ACR

パイプラインの一部として ACR (Azure Container Registry) に発行されたコンテナーイメージを使用し、新しいイメージが発行されるたびにパイプラインをトリガーする必要がある場合は、ACR コンテナーリソースを使用できます。

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

また、ACR イメージのメタデータには、定義済みの変数を使用してアクセスできます。 次の一覧には、パイプラインで ACR コンテナーリソースを定義するために使用できる ACR 変数が含まれています。

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

パイプラインのアーティファクトチェックポリシーを評価するための機能強化

[アーティファクトの評価] チェック が強化され、すぐに使用できるポリシー定義の一覧からポリシーを簡単に追加できるようになりました。 ポリシー定義は自動的に生成され、 チェック構成 に追加されます。これは、必要に応じて更新できます。

[テンプレートの使用] オプションが下線付きで表示された [成果物の評価] ダイアログボックスのスクリーンショット。

[ホワイトリストの作成元] オプションと [Azure パイプラインの構築済みイメージ] オプションが選択されている [アーティファクトポリシーの構成] ダイアログボックスを示すスクリーンショット。

デプロイジョブでの出力変数のサポート

デプロイジョブの ライフサイクルフック で出力変数を定義し、同じステージ内の他の下流のステップとジョブでそれらを使用できるようになりました。

デプロイ戦略の実行中は、次の構文を使用して、ジョブ間で出力変数にアクセスできます。

  • RunOnce 戦略の場合:$[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
  • カナリア 戦略の場合:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
  • ローリング 戦略の場合:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]
// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

マルチジョブ出力変数を設定する方法について詳しくは、こちらをご覧ください。

重要な変更のロールバックを避ける

従来のリリースパイプラインでは、通常の更新に対してスケジュールされた展開に依存します。 ただし、重要な修正プログラムがある場合は、帯域外の手動デプロイを開始することができます。 その場合、古いリリースは引き続きスケジュールされたままです。 スケジュールに基してデプロイが再開されると手動デプロイがロールバックされるので、これは課題でした。 多くのユーザーからこの問題が報告され、修正されました。 この修正により、手動でデプロイを開始すると、環境への以前のスケジュールされたデプロイはすべて取り消されます。 これは、キュー オプションが [最新のデプロイと他のユーザーのキャンセル] として選択されている場合にのみ適用されます。

YAML パイプラインでのリソース承認の簡略化

リソースは、パイプラインの外部にあるパイプラインによって使用される何でもです。 リソースを使用するには、リソースを承認する必要があります。 以前は、YAML パイプラインで承認されていないリソースを使用している場合、リソース承認エラーで失敗しました。 失敗した実行の概要ページからリソースを承認する必要がありました。 さらに、承認されていないリソースを参照する変数を使用している場合、パイプラインは失敗しました。

これで、リソースの承認の管理が容易になりました。 実行は、実行に失敗するのではなく、リソースを使用するステージの開始時点でリソースに対するアクセス許可を待機します。 リソース所有者は、パイプラインを表示し、[セキュリティ] ページからリソースを承認できます。

[開発] ステージが [待機中] 状態で、アクセス許可が必要であるというインジケーターを示すスクリーンショット。

成果物のチェックを評価する

これで、一連のポリシーを定義し、コンテナー イメージ成果物の環境のチェックとしてポリシー評価を追加できます。 パイプラインが実行されると、環境を使用するステージを開始する前に実行が一時停止します。 指定したポリシーは、デプロイされるイメージで使用可能なメタデータに対して評価されます。 チェックが成功すると、チェックは成功し、チェックに失敗した場合はステージを失敗としてマークします。

[アーティファクトポリシーの評価] ダイアログボックスのスクリーンショット。

ARM テンプレートのデプロイタスクの更新

以前は、ARM テンプレートデプロイタスクでサービス接続をフィルター処理していませんでした。 これにより、より広いスコープに ARM テンプレートをデプロイするために、低いスコープのサービス接続を選択すると、デプロイが失敗する可能性があります。 ここでは、サービス接続のフィルター処理を追加して、選択したデプロイスコープに基づいて、スコープが低いサービス接続を除外しました。

環境内の ReviewApp

ReviewApp は、Git リポジトリからのすべてのプル要求を動的な環境リソースにデプロイします。 レビュー担当者は、これらの変更がどのように見えるかを確認したり、他の依存サービスと連携してから、メインブランチにマージして運用環境にデプロイしたりすることができます。 これにより、 reviewApp リソースの作成と管理が容易になり、環境機能のすべての追跡可能性と診断機能を活用できるようになります。 ReviewApp キーワードを使用すると、リソースの複製を作成し (環境内の既存のリソースに基づいて新しいリソースを動的に作成)、環境に新しいリソースを追加できます。

次に示すのは、環境で reviewApp を使用している YAML スニペットのサンプルです。

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

パイプラインから自動およびユーザー指定のメタデータを収集する

パイプラインタスクから自動およびユーザー指定のメタデータコレクションを有効にできるようになりました。 メタデータを使用して、 成果物の評価チェックを使用して、環境にアーティファクトポリシーを適用できます。

[パイプラインからメタデータを公開する] オプションがオンになっている [全般] ダイアログボックスのスクリーンショット。

環境を使用した VM のデプロイ

環境で最も要求される機能の1つは、VM のデプロイでした。 この更新プログラムでは、環境内で仮想マシンのリソースを有効にします。 複数のコンピューター間でデプロイを調整し、YAML パイプラインを使用して ローリング アップデートを実行できるようになりました。 また、各ターゲット サーバーにエージェントを直接インストールし、それらのサーバーへのローリング デプロイを実行することもできます。 さらに、ターゲット マシンで完全なタスク カタログを使用できます。

[仮想マシン] オプションが選択され、呼び出された [新しい環境] ダイアログ ボックスのスクリーンショット。

ローリング デプロイでは、以前のバージョンのアプリケーションのインスタンスを、各イテレーションのマシンセット (ローリング セット) 上のアプリケーションの新しいバージョンのインスタンスに置き換えてください。

たとえば、以下のローリング デプロイでは、各イテレーションで最大 5 つのターゲットが更新されます。 maxParallel は、並列でデプロイできるターゲットの数を決定します。 選択は、デプロイ先のターゲットを除き、いつでも使用可能な状態を維持する必要があるターゲットの数を示します。 それはまた、デプロイの間に成功と失敗の条件を判断するためにも使用されます。

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

注意

この更新プログラムでは、現在のパイプラインと関連付けられているパイプライン リソースから使用可能なすべての成果物が、ライフサイクル フック deploy でのみダウンロードされます。 ただし、 [パイプライン成果物のダウンロード] タスク を指定して 、ダウンロードを選択できます。 この機能にはいくつかの既知のギャップがあります。 たとえば、ステージを再試行すると、失敗したターゲットではなく、すべての VM でデプロイが再び実行されます。 今後の更新でこれらのギャップを解消するために取り組み中です。

デプロイの追加の制御

Azure Pipelines、手動による承認によって制御されるデプロイがサポートされています。 最新の機能強化により、デプロイを追加で制御できます。 承認に加えて、リソース所有者は、セキュリティポリシーと品質ポリシーを検証 checks するために自動化された を追加できます。 これらのチェックを使用して操作をトリガーし、完了するまで待機できます。 追加のチェックを使用して、複数のソースに基づいて正常性基準を定義し、デプロイを実行する YAML パイプラインに関係なく、リソースをターゲットにしているすべてのデプロイが安全である保証を得られる状態にできます。 各チェックの評価は、指定されたチェックの再試行間隔に基づいて 定期的に繰 り返し実行できます。 次の追加のチェックが使用できるようになりました。

  • 任意の REST API を呼び出し、応答本文または外部サービスからのコールバックに基づいて検証を実行します。
  • Azure 関数を呼び出し、応答または関数からのコールバックに基づいて検証を実行する
  • アクティブなアラートのクエリ Azure Monitor ルール
  • パイプラインによって1つ以上の YAML テンプレートが拡張されることを確認する

[チェックの追加] ダイアログボックスのスクリーンショット。

承認通知

環境またはサービス接続に承認を追加すると、そのリソースを使用するすべてのマルチステージパイプラインが、ステージの開始時に自動的に承認を待機します。 指定された承認者は、パイプラインを続行する前に承認を完了する必要があります。

この更新プログラムを使用すると、承認待ちの電子メール通知が送信者に送信されます。 ユーザーおよびチームの所有者は、 通知設定を使用してカスタムサブスクリプションをオプトアウトまたは構成することができます。

承認通知のスクリーンショット。

Azure portal から展開戦略を構成する

この機能により、 ローリングカナリア青緑 など、選択したデプロイ方法を使用するパイプラインを簡単に構成できるようになりました。 これらの既定の方法を使用すると、更新プログラムを安全な方法でロールアウトし、関連する展開のリスクを軽減できます。 これにアクセスするには、Azure 仮想マシンの [継続的デリバリー] 設定をクリックします。 [構成] ウィンドウで、パイプラインを作成する Azure DevOps プロジェクトの詳細、配置グループ、デプロイするパッケージを発行するビルドパイプライン、および選択した配置方法を選択するように求められます。 先に進むと、選択したパッケージをこの仮想マシンにデプロイする完全機能パイプラインが構成されます。

詳細については、 デプロイ方法の構成に関するドキュメントを参照してください。

[継続的配信] ダイアログボックスを表示するスクリーンショット。

ランタイム パラメーター

ランタイム パラメーターを使用すると、パイプラインに渡す値を詳細に制御できます。 変数とは異なり、ランタイム パラメーターにはデータ型が含まれており、自動的には環境変数にはなされません。 ランタイム パラメーターを使用すると、次の処理を実行できます。

  • 実行時にスクリプトとタスクに異なる値を指定する
  • 制御パラメーターの型、許可される範囲、および既定値
  • テンプレート式を使用してジョブとステージを動的に選択する

ランタイム パラメーターの詳細については、 のドキュメントを参照 してください

パイプラインで extends キーワードを使用する

現在、パイプラインをテンプレートに組み込み、再利用を促進し、定型を減らします。 パイプラインの全体的な構造は、ルート YAML ファイルによってまだ定義されています。 この更新プログラムでは、パイプライン テンプレートを使用するためのより構造化された方法が追加されました。 ルート YAML ファイルで キーワード extends を使用して、メイン パイプライン構造が別のファイルで見つかる可能性を示することができるようになりました。 これにより、拡張または変更できるセグメントと固定されるセグメントを制御できます。 また、指定できるフックを明確にするために、データ型を使用したパイプライン パラメーターも強化されています。

この例では、パイプライン作成者が使用する簡単なフックを提供する方法を示します。 テンプレートは常にビルドを実行し、必要に応じてパイプラインによって提供される追加の手順を実行してから、オプションのテスト 手順を実行します。


# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

キューの時刻にオーバーライドできる制御変数

以前は、新しい実行を開始する前REST API変数の値を更新するために、UI またはコントロールを使用できます。 パイプラインの作成者は、特定の変数を としてマークすることができますが、システムはこれを強制しなかったか、他の変数が _settable at queue time_ 設定されるのを妨げるものでもありません。 つまり、この設定は、新しい実行を開始するときに追加の入力を求める場合にのみ使用されます。

パラメーターを適用する新しいコレクション設定が追加されました _settable at queue time_ 。 これにより、新しい実行を開始するときにどの変数を変更できるかを制御できるようになります。 今後、著者によってマークされていない変数をとして変更することはできません _settable at queue time_

注意

この設定は、既存のコレクションでは既定でオフになっていますが、新しい Azure DevOps collection を作成すると、既定でオンになります。

YAML パイプラインでの新しい定義済み変数

変数を使用すると、パイプラインのさまざまな部分に重要なデータを簡単に取り込むことができます。 この更新プログラムでは、いくつかの定義済みの変数をデプロイジョブに追加しました。 これらの変数は、システムによって自動的に設定され、特定のデプロイジョブにスコープが設定され、読み取り専用になります。

  • Environment.Id-環境の ID。
  • Environment.Name-デプロイジョブの対象となる環境の名前。
  • Environment. ResourceId-デプロイジョブの対象となる環境内のリソースの ID。
  • Environment-配置ジョブの対象となる環境内のリソースの名前。

複数のリポジトリのチェックアウト

パイプラインは多くの場合、複数のリポジトリに依存します。 ソース、ツール、スクリプト、またはコードをビルドするために必要なその他の項目と異なるリポジトリを使用できます。 以前は、これらのリポジトリをサブモジュールとして追加するか、 git チェックアウト を実行する手動スクリプトとして追加する必要がありました。 これで、YAML パイプラインを格納するために使用するリポジトリに加えて、他のリポジトリをフェッチして確認することができます。

たとえば、YAML パイプラインを持つ Mycode という名前のリポジトリと、 ツール という2つ目のリポジトリがある場合、yaml パイプラインは次のようになります。

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

3番目の手順では、ソースディレクトリに MycodeTools という2つのディレクトリが表示されます。

Azure Repos Git、GitHub、Bitbucket の各クラウドリポジトリがサポートされています。 詳細については、「マルチレポの チェックアウト」を参照してください

実行時に複数のリポジトリに関する詳細を取得する

パイプラインが実行されている場合、Azure Pipelinesをトリガーしたリポジトリ、ブランチ、コミットに関する情報が追加されます。 YAML パイプラインで複数のリポジトリのチェックアウトがサポートされたので、他のリポジトリに対してチェックアウトされたリポジトリ、ブランチ、コミットも知りたい場合があります。 このデータはランタイム式を使用して使用できます。これで、変数にマップできます。 次に例を示します。

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

他のコレクションへのリポジトリ参照Azure Repos許可する

以前は、YAML パイプラインでリポジトリを参照した場合、すべての Azure Repos リポジトリがパイプラインと同じコレクション内に含む必要があります。 これで、サービス接続を使用して、他のコレクション内のリポジトリをポイントできます。 次に例を示します。

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection は別のAzure DevOpsを参照し、別のプロジェクトのリポジトリにアクセスできる資格情報を持っています。 リポジトリと の self 両方 otherrepo がチェックアウトされます。

重要

MyServiceConnection は、Azure Repos/Team Foundation Server接続である必要があります。次の図を参照してください。

[プロジェクトの設定] ページのスクリーンショット。[Azure Repos/Team Foundation Server] オプションが強調表示されています。

定義済み変数としてのパイプライン リソースのメタデータ

パイプラインに YAML パイプライン リソースの定義済み変数を追加しました。 使用可能なパイプライン リソース変数の一覧を次に示します。

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

KubernetesManifest タスクのベイク オプションとしての kustomize と kompose

kustomize (Kubernetes sig-cli の一部) を使用すると、テンプレートを使用しない未加工の YAML ファイルを複数の目的でカスタマイズし、元の YAML はそのまま残します。 KubernetesManifestタスクのベイク アクションの下に kustomize のオプションが追加され、kustomization.yaml ファイルを含む任意のフォルダーを使用して、KubernetesManifest タスクの配置アクションで使用されるマニフェスト ファイルを生成できます。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose は 、ファイルDocker Compose Kubernetes リソースに変換します。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

HelmDeploy タスクでのクラスター管理者資格情報のサポート

以前は、 このタスクでは、 デプロイ用のクラスターユーザー資格情報が使用されていました。 これにより、Azure Active Directory ベースの RBAC が有効になっているクラスターで、対話型ログインプロンプトと失敗したパイプラインが生成されました。 この問題に対処するために、クラスターのユーザー資格情報ではなく、クラスター管理者の資格情報を使用できるチェックボックスを追加しました。

[クラスター管理者の資格情報を使用する] チェックボックスを表示する、パッケージと展開のヘルムグラフのスクリーンショット。

Docker Compose タスクでの引数の入力

などの引数を追加できるように、Docker Compose タスクに新しいフィールドが導入されました --no-cache 。 ビルドなどのコマンドを実行すると、タスクによって引数が渡されます。

[新しい引数] テキストボックスを表示している Docker Compose タスクのスクリーンショット。

GitHub リリースタスクの機能強化

GitHub リリースタスクにはいくつかの機能強化が行われています。 タグの正規表現を指定することで、タグパターンフィールドを使用したリリース作成をより適切に制御できるようになりました。リリースは、トリガーされたコミットに一致する文字列がタグ付けされている場合にのみ作成されます。

[タスクバージョン] セクションと [タグパターン] セクションが表示された GitHub リリースタスクを示すスクリーンショット。

また、changelog の作成と書式設定をカスタマイズする機能も追加しました。 Changelog 構成の新しいセクションでは、現在のリリースを比較するリリースを指定できるようになりました。 リリースとの 比較 は、最後の完全リリース (プレリリースを除く)、最後の非ドラフトリリース、または提供されたリリースタグに一致する以前のリリースのいずれかになります。 さらに、このタスクは changelog の種類のフィールドを提供して、changelog をフォーマットします。 選択内容に基づいて、changelog は、コミットの一覧、またはラベルに基づいて分類された問題/Pr の一覧を表示します。

[比較対象] と [Changelog の種類] セクションが強調表示されている GitHub リリースタスクを示すスクリーンショット。

ポリシーエージェントインストーラータスクを開く

オープン ポリシー エージェントは、コンテキストに対応した統合ポリシーの適用を可能にするオープン ソースの汎用ポリシー エンジンです。 Open Policy Agent インストーラー タスクを追加しました。 これは、コードとしてのインフラストラクチャ プロバイダーに関してパイプライン内ポリシーを適用する場合に特に便利です。

たとえば、Open Policy Agent では、パイプラインで Rego ポリシー ファイルと Terraform プランを評価できます。

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

このタスクでの PowerShell スクリプトAzure CLIサポート

以前は、バッチ スクリプトと bash スクリプトをバッチ 処理タスクの一部としてAzure CLIしました。 この更新プログラムでは、PowerShell と PowerShell のコア スクリプトのサポートがタスクに追加されました。

KubernetesManifest タスクでのサービス メッシュ インターフェイス ベースのカナリア デプロイ

以前は、KubernetesManifest タスクでカナリア戦略が指定されている場合、タスクはベースラインワークロードとカナリア ワークロードを作成し、そのレプリカは安定したワークロードに使用されるレプリカの割合に等しくなります。 これは、要求レベルでトラフィックを目的の割合まで分割するのとまったく同じで "ではありません"。 この問題に取り組むために 、Service Mesh Interface ベースのカナリア デプロイのサポートが KubernetesManifest タスクに追加されました。

サービス メッシュ インターフェイスの抽象化により、Linkerd や Istio などのサービス メッシュ プロバイダーを使用したプラグ アンド プレイ構成が可能になります。 これで、KubernetesManifest タスクは、デプロイ戦略のライフサイクル中に SMI の TrafficSplit オブジェクトを安定したベースラインおよびカナリア サービスにマッピングするハードワークを取り上げ、 安定したベースラインとカナリア間のトラフィックの望ましい割合の分割は、サービス メッシュ プレーン内の要求でトラフィック分割の割合が制御されるほど正確です。

次に示すのは、ローリングな方法で SMI ベースのカナリア デプロイを実行するサンプルです。

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Azure ファイル コピー タスクで AzCopy V10 がサポートされる

Azure ファイルコピータスクは、ビルドまたはリリースパイプラインで、Microsoft ストレージ blob または仮想マシン (Vm) にファイルをコピーするために使用できます。 このタスクでは、Azure ストレージアカウントとの間でデータを高速にコピーするためのコマンドラインユーティリティビルドである Azcopy を使用します。 この更新プログラムでは、azcopy の最新バージョンである Azcopy V10 のサポートが追加されました。

コマンドは、 azcopy copy 関連付けられている 引数 のみをサポートします。 AzCopy の構文が変更されたため、既存の機能の一部は AzCopy V10 では使用できません。 次の設定があります。

  • ログの場所の指定
  • コピー後のログファイルとプランファイルのクリーンアップ
  • ジョブが失敗した場合にコピーを再開する

このバージョンのタスクでサポートされている追加機能は次のとおりです。

  • ソースのファイル名/パスに含まれるワイルドカード記号
  • 引数が指定されていない場合に、ファイル拡張子に基づいてコンテンツタイプを推論する
  • 引数を渡してログファイルのログの詳細度を定義する

アクセストークンのスコープを制限して、パイプラインのセキュリティを強化する

Azure Pipelines で実行されるすべてのジョブは、アクセストークンを取得します。 このアクセストークンは、Azure DevOps にコールバックするために、タスクおよびスクリプトによって使用されます。 たとえば、アクセストークンを使用して、ソースコードの取得、ログのアップロード、テスト結果、アーティファクトの取得、または Azure DevOps への REST 呼び出しを行います。 ジョブごとに新しいアクセストークンが生成され、ジョブが完了すると期限切れになります。 この更新プログラムでは、次の機能強化が追加されました。

  • トークンがチームプロジェクト外のリソースにアクセスできないようにする

    これまでは、すべてのパイプラインの既定のスコープはチームプロジェクトコレクションでした。 スコープをクラシック ビルド パイプラインのチーム プロジェクトに変更できます。 ただし、クラシック リリースまたは YAML パイプラインに対してその制御を行う必要はなかった。 この更新プログラムでは、パイプラインで何が構成されている場合でも、すべてのジョブがプロジェクト スコープのトークンを取得するように強制するコレクション設定を導入しています。 また、プロジェクト レベルで 設定を追加しました。 これで、作成する新しいプロジェクトとコレクションごとに、この設定が自動的に有効になります。

    注意

    コレクション設定は、プロジェクト設定をオーバーライドします。

    既存のプロジェクトとコレクションでこの設定を有効にすると、アクセス トークンを使用してチーム プロジェクトの外部にあるリソースにパイプラインがアクセスすると、特定のパイプラインが失敗する可能性があります。 パイプラインの障害を軽減するために、プロジェクト ビルド サービス アカウントに目的のリソース への アクセス権を明示的に付与できます。 これらのセキュリティ設定を有効にすることを強く推奨します。

  • ビルド サービス リポジトリ スコープのアクセスを制限する

    アクセス トークンのスコープを制限することでパイプラインのセキュリティを向上させる上で、Azure Pipelines では 、YAML ベースのパイプライン に必要なリポジトリへのアクセスのスコープを限定できます。 つまり、パイプラインのアクセス トークンがリークした場合、パイプラインで使用されているレポポのみを表示できます。 以前は、アクセス トークンは、プロジェクト内Azure Reposリポジトリ、またはコレクション全体に対して有効でした。

    この機能は、新しいプロジェクトとコレクションに対して既定でオンになります。 既存のコレクションの場合は、 [コレクションの設定] [パイプライン の設定] > で有効にする必要 > があります。 この機能を使用する場合は、ビルドに必要なすべてのリポジトリ (スクリプトを使用して複製するリポジトリも含む) をパイプラインのリポジトリ リソースに含 める必要があります。

  • アクセス トークンの特定のアクセス許可を削除する

    既定では、アクセス トークンに対して多数のアクセス許可が付与されます。このアクセス許可の 1 つは Queue builds です。 この更新プログラムでは、アクセス トークンに対するこのアクセス許可を削除しました。 パイプラインにこのアクセス許可が必要な場合は、使用するトークンに応じて、 プロジェクトビルドサービスアカウント または プロジェクトコレクションビルドサービスアカウント に明示的に付与できます。

サービス接続のプロジェクトレベルのセキュリティ

サービス接続のハブレベルセキュリティが追加されました。 これで、すべてのサービス接続の一元化された場所で、ユーザーの追加/削除、ロールの割り当て、アクセスの管理を行うことができます。

セキュリティオプションが [サービス接続] ページのスクリーンショット。

ターゲットとコマンドの分離のステップ

Azure Pipelines では、コンテナーまたはエージェントホストでのジョブの実行がサポートされています。 以前は、ジョブ全体がこれら2つのターゲットのいずれかに設定されていました。 これで、選択したターゲットで個別の手順 (タスクまたはスクリプト) を実行できるようになりました。 手順は、他のコンテナーを対象にすることもできます。したがって、パイプラインは、専用の専用のコンテナーで各ステップを実行できます。

コンテナーは分離境界として機能し、コードがホストコンピューターで予期しない変更を行うことを防止できます。 手順と エージェントの間の通信 方法は、コンテナー内のステップを分離することによる影響を受けません。 このため、ステップターゲットで使用できるコマンド制限モードも導入しています。 これをオンにすると、ステップがエージェントから要求できるサービスが制限されます。 ログを添付したり、アーティファクトをアップロードしたり、その他の操作を実行したりすることはできなくなります。

次に、ジョブコンテナー内のホスト上の実行中のステップと、別のコンテナー内の手順を示します。

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

読み取り専用変数

システム変数は変更不可として文書化されていますが、実際にはタスクによって上書きされる可能性があり、下流のタスクは新しい値を取得します。 この更新により、システムおよびキュー時間変数を読み取り専用にするために、パイプライン変数に関するセキュリティが強化されます。 さらに、次のようにして、YAML 変数を読み取り専用にすることもできます。

variables:
- name: myVar
  value: myValue
  readonly: true

サービス接続のロールベースのアクセス

サービス接続のロールベースのアクセスが追加されました。 以前は、サービス接続のセキュリティは、エンドポイント管理者やエンドポイント作成者などのAzure DevOpsグループを使用してのみ管理できます。

この作業の一環として、閲覧者、ユーザー、作成者、管理者の新しいロールが導入されました。 これらのロールは、プロジェクトのサービス接続ページを使用して設定できます。これらは個々の接続によって継承されます。 また、各サービス接続には、継承を有効または無効にし、サービス接続のスコープ内のロールをオーバーライドするオプションがあります。

サービス接続のロールベースのアクセスを示すスクリーンショット。

サービス接続のセキュリティの詳細については、こちらを 参照してください

サービス接続のプロジェクト間共有

プロジェクト間でのサービス接続共有のサポートを有効にしました。 これで、サービス接続をプロジェクトと安全かつ安全に共有できます。

サービス接続のプロジェクト間共有を示すスクリーンショット。

サービス接続の共有の詳細については、こちらを 参照してください

パイプラインと ACR リソースの追跡可能性

パイプラインと ACR コンテナー リソースがパイプラインで使用される場合は、完全な E2E 追跡可能性が確保されます。 YAML パイプラインによって使用されるリソースごとに、コミット、作業項目、成果物までトレースできます。

パイプライン実行の概要ビューには、次の情報が表示されます。

  • 実行 をトリガーしたリソース のバージョン。 これで、別の Azure パイプラインの実行が完了するか、コンテナー イメージが ACR にプッシュされると、パイプラインをトリガーできます。

    パイプラインが自動的にトリガーされた状態を示すスクリーンショット。

  • パイプライン によって 使用されるコミット。 また、パイプラインによって使用される各リソースごとにコミットの内訳を調べることもできます。

    現在のパイプラインセクションのコミットを示すスクリーンショット。

  • パイプラインによって使用される各リソースに関連付けられている 作業項目

  • 実行によって使用可能な 成果物

    パイプラインの [成果物] ページを示すスクリーンショット。

環境の [配置] ビューでは、環境にデプロイされた各リソースのコミットと作業項目を確認できます。

[作業項目] タブが表示されている [配置] セクションのスクリーンショット。

大規模なテスト添付ファイルのサポート

Azure Pipelines の [テスト結果の発行] タスクを使用すると、テストを実行したときにテスト結果を発行して、包括的なテストレポートと分析エクスペリエンスを提供できます。 これまでは、テストの実行とテスト結果の両方について、テストの添付ファイルに 100 MB の制限がありました。 これにより、クラッシュダンプやビデオなどのビッグファイルのアップロードが制限されます。 この更新により、大規模なテスト添付ファイルのサポートが追加され、失敗したテストのトラブルシューティングに使用できるすべてのデータを取得できるようになりました。

ログで403または407エラーを返す、Vstest.console.exe タスクまたはテスト結果の発行タスクが表示される場合があります。 送信要求をフィルター処理するファイアウォールの内側で自己ホスト型のビルドまたはリリースエージェントを使用している場合は、この機能を使用できるように構成を変更する必要があります。

ログで403エラーが返されたことを示すスクリーンショット。

この問題を解決するには、への 送信要求 に対してファイアウォールを更新することをお勧め https://*.vstmrblob.vsassets.io します。 トラブルシューティング情報については、 こちらのドキュメントを参照してください。

注意

これは、自己ホスト型 Azure Pipelines エージェントを使用していて、送信トラフィックをフィルター処理しているファイアウォールの内側にいる場合にのみ必要です。 クラウドで Microsoft がホストするエージェントを使用している場合、または送信ネットワークトラフィックをフィルター処理していない場合は、何もする必要はありません。

各ジョブで正しいプール情報を表示する

以前は、マトリックスを使用してジョブまたは変数を展開してプールを識別した場合、ログ ページで不適切なプール情報が解決される場合があります。 これらの問題は解決されました。

新しいブランチの CI トリガー

新しいブランチが作成され、そのブランチに変更が存在しない場合に CI ビルドをトリガーしないという長い保留中の要求でした。 次に例を示します。

  • Web インターフェイスを使用して、既存のブランチに基づいて新しいブランチを作成します。 これにより、ブランチ フィルターが新しいブランチの名前と一致する場合、新しい CI ビルドが直ちにトリガーされます。 既存のブランチと比較して、新しいブランチの内容が同じなので、これは不要です。
  • app と docs という 2 つのフォルダーを持つリポジトリがあります。"app" と一致する CI のパス フィルターを設定します。 つまり、変更がドキュメントにプッシュされている場合は、新しいビルドを作成したくないと思います。新しいブランチをローカルで作成し、ドキュメントにいくつかの変更を加えた後、そのブランチをサーバーにプッシュします。 以前は、新しい CI ビルドをトリガーしました。 これは、docs フォルダー内の変更を明示的に検索しないという要求を行ったので不要です。 ただし、新しいブランチ イベントを処理する方法のため、アプリ フォルダーにも変更が行われたように見えるでしょう。

これで、新しいブランチでこれらの問題に対処するための CI を処理する方法が改善されています。 新しいブランチを発行するときに、そのブランチで新しいコミットを明示的に検索し、パス フィルターと一致するかどうかを確認します。

ジョブは、前のステージの出力変数にアクセスできます

YAML ベースのパイプラインのステージ間で出力変数を使用できます。 これは、go/no-go の決定や、生成された出力の ID などの有用な情報を、あるステージから次のステージに渡すのに役立ちます。 前のステージとそのジョブの結果 (状態) も使用できます。

出力変数は、ジョブ内のステップによって引き続き生成されます。 を参照する代わりに、 dependencies.jobName.outputs['stepName.variableName'] ステージは を参照します stageDependencies.stageName.jobName.outputs['stepName.variableName']

注意

既定では、パイプラインの各ステージは、YAML ファイルの直前のステージに依存しています。 したがって、各ステージでは、前の段階の出力変数を使用できます。 依存関係グラフを変更して、使用可能な出力変数を変更することもできます。 たとえば、ステージ3でステージ1の変数が必要な場合は、ステージ1に対して明示的な依存関係を宣言する必要があります。

プールレベルでのエージェントの自動アップグレードを無効にする

現在、パイプラインエージェントは必要に応じて自動的に最新バージョンに更新されます。 これは通常、新しい機能またはタスクがあるときに、新しいバージョンのエージェントを正常に機能させる必要がある場合に発生します。 この更新プログラムでは、プールレベルで自動アップグレードを無効にする機能が追加されています。 このモードでは、正しいバージョンのエージェントがプールに接続されていない場合、エージェントの更新を要求する代わりに、パイプラインが明確なエラーメッセージで失敗します。 この機能は、自己ホスト型プールと非常に厳格な変更制御要件を持つお客様にとって最も重要です。 既定では自動更新が有効になっているため、ほとんどのお客様は無効にすることをお勧めします。

[エージェントの更新設定] オプションがオンになっていて、呼び出された既定の設定ページの Sceenshot。

エージェント診断

多くのネットワークの問題やアップグレードエラーの一般的な原因など、エージェントに関連する多くの一般的な問題に対する診断を追加しました。 診断の使用を開始するには、Windows で run.sh--diagnostics または run .cmd--diagnostics を使用します。

YAML パイプラインのサービスフック

サービスと YAML パイプラインの統合が簡単になりました。 YAML パイプラインのサービスフックイベントを使用して、パイプラインの実行の進行状況に基づいて、カスタムアプリまたはサービスでアクティビティを処理できるようになりました。 たとえば、承認が必要なときにヘルプデスクチケットを作成したり、ステージの完了後に監視ワークフローを開始したり、ステージが失敗したときにチームのモバイルデバイスにプッシュ通知を送信したりできます。

パイプライン名とステージ名のフィルター処理は、すべてのイベントでサポートされています。 承認イベントは、特定の環境に対してフィルター処理することもできます。 同様に、状態変更イベントは、パイプラインの実行またはステージの新しい状態でフィルター処理できます。

[実行ステージ] オプションが選択された [この種類のイベントのトリガー] ドロップダウン リストを示す新しい SERVICE HOOKS サブスクリプション ウィザードのスクリーンショット。

最適化された統合

Optimizely は、製品チーム向け強力な A/B テストおよび機能フラグ付けプラットフォームです。 Azure Pipelines と Optimizely 実験プラットフォームの統合により、製品チームは、開発からすべての DevOps の利点を得ながら、迅速なペースでテスト、学習、デプロイAzure Pipelines。

Azure DevOps の Optimizely 拡張機能では、実験と機能フラグのロールアウト手順がビルドパイプラインとリリース パイプラインに追加されます。そのため、Azure Pipelines を使用して機能を継続的に反復処理、ロールアウト、ロールバックすることができます。

Optimizely 拡張機能の詳細についてはAzure DevOpsを参照 してください

Optimizely

GitHub リリースを成果物ソースとして追加する

これで、GitHub リリースを成果物ソースとして、リリース パイプラインAzure DevOpsリンクできます。 これにより、デプロイの一部として GitHub リリースを使用できます。

リリース パイプライン定義で [成果物の 追加] をクリックすると、新しい GitHub リリース ソースの 種類が 表示されます。 サービス接続と GitHub リポジトリを指定して、GitHub リリースを使用できます。 GitHub リリースの既定のバージョンを選択して、最新の特定のタグ バージョンとして使用したり、リリース作成時に選択したりすることもできます。 GitHub リリースがリンクされると、自動的にダウンロードされ、リリース ジョブで使用できます。

[GitHub リリース] オプションが選択され、コールアウトされた [成果物の追加] ダイアログ ボックスのスクリーンショット。

Terraform と Azure Pipelines

Terraform は、インフラストラクチャを安全かつ効率的に開発、変更、バージョン管理するためのオープンソース ツールです。 Terraform は、高度な構成言語を使用してインフラストラクチャを定義およびプロビジョニングできるように、宣言型の構成ファイルに体系化 Api を提供します。 Terraform 拡張機能を使用して、すべての主要なインフラストラクチャプロバイダー (Azure、アマゾンウェブサービス (AWS)、Google Cloud Platform (GCP)) 間でリソースを作成できます。

Terraform 拡張機能の詳細については、 こちらのドキュメントを参照してください。

Terraform と Azure Pipelines の統合のスクリーンショット。

Google アナリティクスとの統合

Google アナリティクス実験フレームワークを使用すると、web サイトまたはアプリのほぼすべての変更やバリエーションをテストして、特定の目的への影響を測定できます。 たとえば、ユーザーが実行したいアクティビティ (購入、ニュースレターへのサインアップなど) や、改善する必要のあるメトリック (収益、セッション継続時間、バウンス率など) がある場合が考えられます。 これらのアクティビティを使用すると、機能のパフォーマンスに対する直接の影響に基づいて、実装する価値のある変更を特定できます。

Azure DevOps 向けの Google アナリティクス実験拡張機能により、実験手順がビルドパイプラインとリリースパイプラインに追加されるため、継続的に実験を管理しながら、継続的に実験を行い、学習し、デプロイすることができます。これにより、Azure Pipelines のすべての DevOps メリットを得ることができます。

Google アナリティクス実験拡張機能は、Marketplace からダウンロードできます。

Google アナリティクス実験タスクを示すスクリーンショット。

ServiceNow と Azure Pipelines の統合が更新されました

Servicenow 用の Azure Pipelines アプリは、Azure Pipelines と Servicenow の変更管理を統合するのに役立ちます。 この更新プログラムを使用すると、新しいニューヨークバージョンの ServiceNow と統合できます。 これで、2つのサービス間の認証を OAuth と基本認証を使用して行うことができます。 さらに、任意の変更プロパティを使用してゲートの結果を決定できるように、高度な成功条件を構成できるようになりました。

VSCode から Azure Pipelines を作成する

VSCode の拡張機能の新しい機能Azure Pipelines追加しました。 これで、IDE を離れることなく VSCode Azure Pipelines直接作成できます。

右下隅VS Codeアラートが表示されている状態のスクリーンショット: パイプラインが正常に設定されました。

フラグの高いバグの管理と解決

検出、レポート、解決を使用してエンドツーエンドのライフサイクルをサポートする、フラグの高いテスト管理を導入しました。 さらに強化するために、フラグの高いテスト バグの管理と解決を追加します。

フラグの高いテストを調査している間に、バグ アクションを使用してバグを作成できます。バグアクションを開発者に割り当て、フラグの高いテストの根本原因をさらに調査できます。 バグ レポートには、エラー メッセージ、スタック トレース、テストに関連付けられているその他の情報など、パイプラインに関する情報が含まれています。

バグ レポートが解決または終了すると、テストのマークが自動的に unflaky として解除されます。

最小数のテストが実行されていない場合に失敗する VSTest タスクを設定する

VSTest タスクは、ユーザー入力 (テスト ファイル、フィルター条件など) と、使用されているテスト フレームワークに固有のテスト アダプターを使用して、テストを検出して実行します。 ユーザー入力またはテスト アダプターに変更を加えた場合、テストが検出されない場合や、予想されるテストのサブセットのみが実行される可能性があります。 これにより、コードの品質が十分に高いという理由ではなく、テストがスキップされたため、パイプラインが成功する状況が発生する可能性があります。 この状況を回避するために、VSTest タスクに新しいオプションが追加されました。これにより、タスクが合格するために実行する必要があるテストの最小数を指定できます。

[テストの最小数が実行されない場合にタスクを失敗する] オプションを示すスクリーンショット。

タスク UI で VSTest TestResultsDirectory オプションを使用できます

VSTest タスクは、テスト結果と関連ファイルを フォルダーに格納 $(Agent.TempDirectory)\TestResults します。 テスト結果を格納する別のフォルダーを構成するためのオプションをタスク UI に追加しました。 これで、特定の場所にあるファイルを必要とする後続のタスクでそれらを使用できるようになりました。

[テスト結果フォルダー] テキストボックスを示すスクリーンショット。

自動テストエラーメッセージでの Markdown のサポート

自動テストのエラーメッセージに markdown サポートを追加しました。 これで、テストの実行とテスト結果の両方のエラーメッセージを簡単に書式設定できるようになりました。これにより、読みやすさが向上し、Azure Pipelines のテスト失敗のトラブルシューティングエクスペリエンスが容易になります。 サポートされている markdown 構文については、 こちらを参照してください。

自動テストエラーメッセージの markdown サポートを示すスクリーンショット。

パイプラインデコレーターを使用して、展開ジョブにステップを自動的に挿入する

デプロイジョブに パイプラインデコレーター を追加できるようになりました。 すべてのデプロイジョブのすべての ライフサイクル の実行に、任意のカスタムステップ (脆弱性スキャナーなど) を自動的に挿入することができます。 パイプラインデコレーターはコレクション内のすべてのパイプラインに適用できるため、安全なデプロイプラクティスの適用の一環として活用できます。

また、デプロイジョブは、定義されている場合、サービスサイドカーと共にコンテナージョブとして実行できます。

Test Plans

[新しいテスト計画] ページ

新しい Test Plans ページ (Test Plans *) は、すべての Azure DevOps collection で使用できます。 新しいページには、手動によるテストの計画、作成、または実行の作業に集中するのに役立つ、合理化されたビューが用意されています。 また、Azure DevOps オファリングの残りの部分との間でも、使いやすいものになります。

バックエンドストアを共有するテスト計画という名前の2つの識別子を示すスクリーンショット。

新しいページを理解できるようにする

テスト計画の概要ページ

新しい Test Plans ページには合計6つのセクションがあり、最初の4つは新しいものですが、グラフ & の拡張セクションは既存の機能です。

  1. テスト 計画ヘッダー: これを使用して、テスト 計画を検索、お気に入り、編集、コピー、または複製します。
  2. テスト スイート ツリー: これを使用して、テスト スイートの追加、管理、エクスポート、または注文を行います。 これを利用して、構成を割り当て、ユーザー受け入れテストを実行します。
  3. [定義] タブ: このタブを使用して、選択したテスト スイートでテスト ケースを照合、追加、管理します。
  4. [実行] タブ: このタブを使用してテストを割り当て、実行するか、テスト結果を探してドリルインします。
  5. [グラフ] タブ: ダッシュボードにピン留めできるグラフを使用してテストの実行と状態を追跡します。
  6. 機能拡張: 製品 内の 現在の拡張ポイント をサポートします。

以下の新しいセクションを大まかに見ることができます。

1.テスト 計画ヘッダー

テスト 計画ヘッダー ページ

タスク

Test Plan ヘッダーを使用すると、次のタスクを実行できます。

  • テスト 計画をお気に入りとしてマークする
  • お気に入りのテスト 計画のマークを解除する
  • お気に入りのテスト 計画間を簡単に移動する
  • テスト 計画のイテレーション パスを表示します。これは、テスト 計画が [現在] または [過去] かどうかを明確に示します
  • レポートに移動するリンクを含むテストの進行状況レポートの簡単な概要を表示する
  • [All/Mine] ページに戻Test Plansします

コンテキスト メニューのオプション

テスト計画ヘッダーのコンテキスト メニューには、次のオプションがあります。

  • テスト 計画のコピー: これは、現在のテスト 計画をすばやくコピーできる新しいオプションです。 詳しくは、以下をご覧ください。
  • テスト 計画の編集: このオプションを使用すると、作業項目フィールドを管理するために [テスト 計画] 作業項目フォームを編集できます。
  • テスト計画の設定: このオプションを使用すると、テストの実行設定 (ビルドまたはリリースパイプラインを関連付ける) とテスト結果の設定を構成できます。

テスト計画のコピー (新機能)

[テスト計画のコピー] ページ

スプリント/リリースごとに新しいテスト計画を作成することをお勧めします。 これを行うと、通常、前のサイクルのテスト計画がコピーされ、いくつかの変更を加えることができます。コピーしたテスト計画は新しいサイクルの準備ができています。 このプロセスを簡単にするために、新しいページで "テスト計画のコピー" 機能を有効にしました。 これを活用することで、テスト計画をコピーまたは複製することができます。 ここでは、そのバッキング REST API について説明します。また、API を使用して、プロジェクト間でテスト計画をコピー/複製することもできます。
Test Plans の使用方法のガイドラインについては、 こちらを参照してください。

2. テストスイートツリー

テストスイートツリーページ

タスク

テストスイートヘッダーを使用すると、次のタスクを実行できます。

  • 展開/折りたたみ: このツールバーオプションを使用すると、スイート階層ツリーを展開または折りたたむことができます。
  • 子スイートからのテストポイントの表示: このツールバーオプションは、[実行] タブが表示されている場合にのみ表示されます。これにより、特定のスイートとその子のすべてのテストポイントを1つのビューで表示して、一度に個別のスイートに移動することなく、テストポイントの管理を容易にすることができます。
  • 注文スイート: ドラッグアンドドロップによってスイートの階層の順序を変更するか、またはテスト計画内のあるスイート階層から別のスイート階層に移動することができます。

コンテキスト メニューのオプション

テストスイートツリーのコンテキストメニューには、次のオプションがあります。

  • 新しいスイートを作成 する: 次のように、3種類のスイートを作成できます。
    • 静的なスイートまたはフォルダースイートを使用して、テストを整理します。
    • 要件ベースのスイートを使用して、シームレスな追跡可能性のある要件/ユーザーストーリーに直接リンクします。
    • クエリベースのを使用して、クエリ条件を満たすテストケースを動的に整理します。
  • 構成 の割り当て: スイートの構成 (Chrome、Firefox、Edge Chromeium など) を割り当て、既存のすべてのテスト ケースまたはこのスイートに後で追加する新しいテスト ケースに適用できます。
  • pdf/email としてエクスポート: テスト プランのプロパティ、テスト スイートのプロパティ、テスト ケースの詳細、テスト ポイントを "email" または "print to pdf" としてエクスポートします。
  • [テスト スイートの作業項目 を開く]: このオプションを使用すると、テスト スイートの作業項目フォームを編集して作業項目フィールドを管理できます。
  • すべてのテストを 実行するテスト担当者を割り当てる: このオプションは、同じテストを複数のテスト担当者が実行/実行する必要があるユーザー受け入れテスト (UAT) シナリオで非常に便利です。通常は異なる部門に属しています。
  • 名前の変更/ 削除: これらのオプションを使用すると、スイート名を管理したり、スイートとそのコンテンツをテスト 計画から削除することができます。

3.[定義] タブ

タブ ページを定義する

[定義] タブを使用すると、テスト スイートのテスト ケースを照合、追加、管理できます。 一方、[実行] タブはテスト ポイントを割り当て、それらを実行します。

[定義] タブと特定の操作は、Basic + Test Plans同等のユーザーだけが使用できます。 それ以外はすべて、"Basic" アクセス レベルのユーザーが実行できる必要があります。

タスク

[定義] タブでは、次のタスクを実行できます。

  • 作業項目フォームを使用して新 しいテスト ケースを追加する: このオプションを使用すると、作業項目フォームを使用して新しいテスト ケースを作成できます。 作成されたテスト ケースがスイートに自動的に追加されます。
  • グリッドを使用して新しい テスト ケースを追加する: このオプションを使用すると、テスト ケースグリッド ビューを使用して 1 つ以上のテスト ケースを作成できます。 作成されたテスト ケースは、スイートに自動的に追加されます。
  • クエリを使用して既存の テスト ケースを追加する: このオプションを使用すると、クエリを指定することで、既存のテスト ケースをスイートに追加できます。
  • ドラッグ アンド ドロップでテスト ケースを 並べ替える : 特定のスイート内の 1 つ以上のテスト ケースをドラッグ アンド ドロップすることで、テスト ケースの順序を変更できます。 テストケースの順序は、自動テストではなく、手動テストケースにのみ適用されます。
  • テストケースを1つのスイートから別のスイートに移動 する: ドラッグアンドドロップを使用して、テストケースを1つのテストスイートから別のスイートに移動できます。
  • [グリッドの表示]: テストケースとテストステップを表示または編集するために、グリッドモードを使用できます。
  • 全画面表示: このオプションを使用すると、全画面表示モードで [定義] タブ全体の内容を表示できます。
  • フィルター 処理: フィルターバーを使用すると、"テストケースのタイトル"、"担当者"、"状態" の各フィールドを使用して、テストケースの一覧をフィルター処理できます。 列ヘッダーをクリックして、一覧を並べ替えることもできます。
  • 列のオプション: [列のオプション] を使用して、[定義] タブに表示される列の一覧を管理できます。 選択できる列の一覧は、主にテストケースの作業項目フォームのフィールドです。

コンテキスト メニューのオプション

[定義] タブのコンテキストメニューページ

[定義] タブ内のテストケースノードのコンテキストメニューには、次のオプションがあります。

  • テストケースの作業項目フォームを開く/編集 する: このオプションを使用すると、テストステップを含む作業項目フィールドを編集するときに、作業項目フォームを使用してテストケースを編集できます。
  • [テストケースの編集]: このオプションを使用すると、テストケースの作業項目フィールドを一括編集できます。 ただし、このオプションを使用してテストステップを一括編集することはできません。
  • グリッドでのテストケースの編集: このオプションを使用すると、選択したテストケースをグリッドビューを使用してテストステップを含めて一括編集できます。
  • [テストケースの削除]: このオプションを使用すると、特定のスイートからテストケースを削除できます。 ただし、基になるテストケース作業項目は変更されません。
  • [テストケースのコピー/複製を作成 する]: このオプションでは、選択したテストケースのコピー/複製を作成できます。 詳細については、以下を参照してください。
  • [リンクされた 項目の表示]: このオプションを使用すると、特定のテストケースのリンクされた項目を確認できます。 詳細については、以下を参照してください。

テストケースのコピー/複製 (新機能)

[define tab copy test cases]/(タブ コピー テスト ケースの定義)ページ

テスト ケースをコピーまたは複製するシナリオでは、[テスト ケースのコピー] オプションを使用できます。 コピー/複製されたテスト ケースを作成するコピー先プロジェクト、宛先テスト 計画、および宛先テスト スイートを指定できます。 また、複製されたコピーにフローする既存のリンク/添付ファイルを含めるかどうかを指定することもできます。

リンクされた項目の表示 (新機能)

[タブ ビューのリンクされた項目の定義] ページ

テスト成果物、要件、バグの追跡可能性は、製品の重要な価値提案Test Plansです。 [リンクされた項目の表示] オプションを使用すると、このテスト ケースがリンクされているリンクされているすべての要件、このテスト ケースが使用されているすべてのテスト スイート/テスト 計画、およびテスト実行の一部として報告されたバグを簡単に確認できます。

4.[実行] タブ

タブ ページの実行

[定義] タブを使用すると、テスト スイートのテスト ケースを照合、追加、管理できます。 一方、[実行] タブはテスト ポイントを割り当て、それらを実行します。

テスト ポイントとは テスト ケース自体は実行可能ではありません。 テスト ケースをテスト スイートに追加すると、テスト ポイントが生成されます。 テスト ポイントは、テスト ケース、テスト スイート、構成、およびテスト担当者の一意の組み合わせです。 例: テスト ケースが "テスト ログイン機能" で、Edge と Chrome として 2 つの構成を追加すると、2 つのテスト ポイントが得られます。 これで、これらのテスト ポイントを実行できます。 実行すると、テスト結果が生成されます。 テスト結果ビュー (実行履歴) を使用すると、テスト ポイントのすべての実行を確認できます。 テストポイントの最新の実行は、[実行] タブに表示されます。
そのため、テストケースは再利用可能なエンティティです。 テスト計画またはスイートにこれらを含めることにより、テストポイントが生成されます。 テストポイントを実行すると、開発中の製品またはサービスの品質が決まります。

新しいページの主な利点の1つは、主にテストの実行/追跡を行うユーザー ("基本" アクセスレベルのみが必要) です。 suite 管理の複雑さには圧倒されません ([定義] タブはそのようなユーザーに対して非表示になります)。

[定義] タブおよび特定の操作は、 Basic + Test Plans アクセスレベルまたは同等の権限を持つユーザーのみが使用できます。 [実行] タブを含む他のすべてのものは、"Basic" アクセスレベルのユーザーによって exercisable される必要があります。

タスク

[実行] タブでは、次のタスクを実行できます。

  • バルクマークテストポイント: このオプションを使用すると、テストランナーを通じてテストケースを実行しなくても、成功、失敗、ブロック、または適用されていないテストポイントの結果をすばやくマークできます。 1回の実行で、1つまたは複数のテストポイントに対して結果をマークできます。
  • テストポイントの実行: このオプションを使用すると、各テストステップを個別に実行し、テストランナーを使用して成功/失敗をマークすることで、テストケースを実行できます。 テストするアプリケーションに応じて、"web アプリケーション" または "デスクトップランナー" をテストするための "Web ランナー" を使用して、デスクトップや Web アプリケーションをテストできます。 [オプションを指定して実行] を呼び出して、テストを実行するビルドを指定することもできます。
  • 列のオプション: [列のオプション] を使用して、[実行] タブに表示される列の一覧を管理できます。 選択できる列の一覧は、[実行者]、[割り当てられたテスト担当者]、[構成] などのテストポイントに関連付けられています。
  • 全画面表示: このオプションを使用すると、全画面表示モードで [実行] タブ全体の内容を表示できます。
  • フィルター 処理: フィルター バーを使用して、"テスト ケースのタイトル"、"割り当て先"、"状態"、"テスト結果"、"Tester"、および "Configuration" のフィールドを使用して、テスト ポイントの一覧をフィルター処理できます。 列ヘッダーをクリックして一覧を並べ替えすることもできます。

コンテキスト メニューのオプション

[タブの実行] コンテキスト メニュー ページ

[実行] タブ内の [テスト ポイント] ノードのコンテキスト メニューには、次のオプションがあります。

  • テスト結果を マークする: 上記と同じで、テスト ポイントの結果 (合格、失敗、ブロック、または適用不可) をすばやくマークできます。
  • テスト ポイントの実行: 上記と同じで、テスト ランナーを介してテスト ケースを実行できます。
  • [テストをアクティブ にリセットする] : このオプションを使用すると、テスト結果をアクティブにリセットできます。これにより、テスト ポイントの最後の結果は無視されます。
  • [テスト ケースの 作業項目フォームを開く/編集する] : このオプションを使用すると、作業項目フォームを使用してテスト ケースを編集できます。このフォームでは、テスト ステップを含む作業項目フィールドを編集できます。
  • テスト担当者の 割り当て: このオプションを使用すると、テスト実行のためにテスト ポイントをテスト担当者に割り当てできます。
  • テスト結果の表示: このオプションを使用すると、各テスト ステップの結果、追加されたコメント、またはファイルされたバグなど、最新のテスト結果の詳細を表示できます。
  • 実行履歴の 表示: このオプションを使用すると、選択したテスト ポイントの実行履歴全体を表示できます。 新しいページが開き、選択したテスト ポイントだけでなく、テスト ケース全体の実行履歴を表示するフィルターを調整できます。

Test Plans進行状況レポート

このレポートは、プロジェクト内の 1 つ以上のレポートの実行と状態Test Plans追跡するのに役立ちます。 [進行状況Test Plans >* にアクセスして、レポートの使用を開始します。

[進行状況レポート] Test Plans強調表示されている [レポート] セクションのスクリーンショット。

レポートの 3 つのセクションには、次のものが含まれます。

  1. 概要: 選択したテスト 計画の統合ビューが表示されます。
  2. 結果の傾向: 毎日のスナップショットをレンダリングして、実行と状態の傾向を示します。 14日間 (既定)、30日間、またはカスタム範囲のデータを表示できます。
  3. 詳細: このセクションでは、各テスト計画をドリルダウンし、各テストスイートの重要な分析を提供します。

進行状況レポートのスクリーンショット。

Artifacts

注意

Azure DevOps Server 2020 では、データのインポート中にごみ箱にあるフィードはインポートされません。 ごみ箱にあるフィードをインポートする場合は、データのインポートを開始する前にごみ箱から復元してください。

ライセンス式と embedded ライセンス

Visual Studio でパッケージを参照するときに Azure Artifacts に格納されている NuGet パッケージのライセンス情報の詳細を確認できるようになりました。 これは、ライセンス式または埋め込みライセンスを使用して表されるライセンスに適用されます。 これで、Visual Studio パッケージの詳細ページ (下の図の赤い矢印) にライセンス情報へのリンクが表示されます。

パッケージのライセンスを指す赤い矢印が付いた NuGet パッケージの Newtonsoft.Jsのスクリーンショット。

リンクをクリックすると、ライセンスの詳細を表示できる web ページに移動します。 このエクスペリエンスはライセンス式と埋め込みライセンスの両方で同じであるため、Azure Artifacts に格納されているパッケージのライセンスの詳細を1か所に表示できます (ライセンス情報を指定し、Visual Studio でサポートされているパッケージの場合)。

MIT ライセンステキストを表示するブラウザーウィンドウのスクリーンショット

簡易認証タスク

軽量の認証タスクを使用して Azure Pipelines から、人気のあるパッケージマネージャーで認証できるようになりました。 これには、NuGet、npm、PIP、Twine、Maven が含まれます。 以前は、パッケージを発行してダウンロードする機能など、大量の機能を提供するタスクを使用して、これらのパッケージマネージャーで認証することができました。 ただし、これは、パッケージマネージャーと対話するすべてのアクティビティに対して、これらのタスクを使用する必要があります。 パッケージの発行やダウンロードなどのタスクを実行する独自のスクリプトがある場合は、パイプラインで使用することはできません。 これで、独自の設計のスクリプトをパイプライン YAML で使用し、これらの新しい軽量タスクで認証を実行できます。 npm を使用した例:

軽量認証タスクの例のスクリーンショット。

この図の "ci" コマンドと "publish" コマンドは任意に使用できます。YAML でサポートされている任意のコマンドAzure Pipelinesできます。 これにより、コマンド呼び出しを完全に制御し、パイプライン構成で共有スクリプトを簡単に使用できます。 詳細については、NuGet、npm、PIP、Twine、および Maven認証タスクのドキュメントを参照してください。

フィード ページの読み込み時間の改善

フィード ページの読み込み時間が改善されました。 フィード ページの読み込み時間は平均で 10% 減少しています。 最大のフィードでは、99 番目の割合のフィード ページの読み込み時間 (すべてのフィードの最大 99% の読み込み時間) が 75% 減少して最も改善されています。

パブリック フィードを使用してパッケージをパブリックに共有する

これで、パブリック フィード内にパッケージを作成して格納できます。 パブリック フィード内に格納されているパッケージは、認証を受けなくても、コレクション内にあるか、または Azure DevOps コレクションにログインしている場合でも、認証なしでインターネット上のすべてのユーザーが使用できます。 パブリック フィードの詳細については、フィードのドキュメントを参照するか、パッケージをパブリックに共有するチュートリアルに移動してください

パッケージの PublicFeed ページを示すスクリーンショット。

AAD テナント内の異なるコレクションでアップストリームを構成する

これで、アーティファクト フィードにアップストリーム ソースとして Azure Active Directory (AAD) テナントに関連付けられている別のコレクションにフィードを追加できます。 フィードでは、アップストリーム ソースとして構成されているフィードからパッケージを検索して使用でき、AAD テナントに関連付けられているコレクション間でパッケージを簡単に共有できます。 これを設定する 方法については、ドキュメント を参照してください

Python Credential Providerを使用して pip と twine を認証し、Azure Artifactsします

Python 資格情報プロバイダー (アーティファクトキーリング)をインストールして使用できるようになりました。これにより、Azure Artifacts フィードとの間で python パッケージを公開または使用するための認証が自動的に設定されます。 資格情報プロバイダーを使用すると、構成ファイル (pip.ini/pip.conf/.pypirc) を設定する必要はありません。 pip または twine を初めて呼び出すときに、web ブラウザーで認証フローを使用するだけです。 詳細について は、ドキュメントを参照してください。

Visual Studio パッケージマネージャーでのフィードの Azure Artifacts

Azure Artifacts フィードから提供されるパッケージについて、Visual Studio NuGet パッケージマネージャーにパッケージアイコン、説明、および作成者が表示されるようになりました。 以前は、このメタデータの大部分は VS に提供されていませんでした。

フィードへの接続が更新されました

[フィードに接続] ダイアログは、Azure Artifacts を使用するための入り口です。このファイルには、Azure DevOps のフィードからパッケージをプッシュおよびプルするようにクライアントとリポジトリを構成する方法についての情報が含まれています。 詳細なセットアップ情報を追加し、指示するツールを拡張するために、ダイアログを更新しました。

パブリックフィードは、アップストリームサポートで一般公開されました

パブリックフィードのパブリックプレビューは、優れた導入とフィードバックを受けています。 このリリースでは、一般公開されている機能が追加されています。 これで、プライベートフィードから、パブリックフィードをアップストリームソースとして設定できます。 プライベートとプロジェクトスコープの両方のフィードにアップストリームできるようにすることで、構成ファイルを簡単に維持できます。

ポータルからプロジェクトスコープフィードを作成する

パブリックフィードをリリースしたときに、 プロジェクトスコープのフィードもリリースしました。 これまでは、プロジェクトスコープのフィードは、REST Api を使用して作成することも、パブリックフィードを作成してプロジェクトをプライベートにすることによって作成することもできます。 必要なアクセス許可がある場合は、プロジェクトスコープのフィードを任意のプロジェクトから直接ポータルに作成できます。 また、フィードピッカーでは、どのフィードがプロジェクトであり、コレクションスコープになっているかを確認することもできます。

npm のパフォーマンスの向上

コア設計に変更を加え、npm パッケージを格納してフィードに配信する方法Azure Artifactsしました。 これにより、npm で最も使用されている API の一部について、待機時間が最大 10 倍短縮されました。

アクセシビリティの機能強化

フィード ページでアクセシビリティの問題に対処する修正プログラムをデプロイしました。 修正プログラムには次のものが含まれます。

  • フィード エクスペリエンスを作成する
  • グローバル フィード設定エクスペリエンス
  • フィード エクスペリエンスに接続する

Wiki

コード Wiki ページの豊富な編集

以前は、コード Wiki ページを編集するときに、編集のために Azure Reposハブにリダイレクトされました。 現時点では、Repo ハブはマークダウン編集用に最適化されません。

これで、wiki 内の side-by-side エディターでコード wiki ページを編集できます。 これにより、リッチ マークダウン ツール バーを使用してコンテンツを作成し、編集エクスペリエンスをプロジェクト Wiki と同じにします。 コンテキスト メニューの [リポジトリで編集] オプションを選択することで、リポジトリで編集することもできます。

[Edit in Repos]/(リポジトリで編集する)オプションが選択されている [編集] メニューを示すスクリーンショット。

Wiki ページから作業項目を作成して埋め込む

ご意見をお聞きして、Wiki を使用して、ブレーンストーミング ドキュメント、ドキュメントの計画、機能に関するアイデア、仕様ドキュメント、会議の数分をキャプチャすると聞いたことがありました。 Wiki ページを離れることなく、計画ドキュメントから機能とユーザー ストーリーを直接簡単に作成できます。

作業項目を作成するには、作業項目を埋め込む Wiki ページのテキストを選択し、[新しい作業項目 ] を選択します。 作業項目を最初に作成し、編集に移動し、埋め込む作業項目を見つける必要がなさそうで、時間を節約できます。 また、Wiki のスコープから外に出ないので、コンテキストの切り替えも減らされます。

Wiki ページから作業項目を作成して埋め込む方法を示す短いビデオです。

Wiki からの作業項目の作成と埋め込みの詳細については、 こちらのドキュメントを参照してください。

Wiki ページのコメント

以前は、wiki 内の他の wiki ユーザーと対話する方法がありませんでした。 これにより、メッセージ交換がメールまたはチャットチャネル経由で行われる必要があるため、コンテンツに対する共同作業が行われ、質問に回答することができました。 コメントを使用すると、wiki 内の他のユーザーと直接共同作業できるようになります。 コメント内のユーザー機能を活用して、 @mention 他のチームメンバーの注意を引くことができます。 この機能は、 この提案チケットに基づいて優先順位が付けられました。 コメントの詳細について は、こちらのドキュメントを参照してください。

Wiki ページにコメントを追加する方法を示すスクリーンショット。

"." で始まるフォルダーとファイルを非表示にする wiki ツリー内

これまで、wiki ツリーには、wiki ツリー内のドット (.) で始まるすべてのフォルダーとファイルが示されていました。 コード wiki のシナリオでは、これにより、非表示にすることを意図した、vscode などのフォルダーが wiki ツリーに表示されます。 これで、ドットで始まるすべてのファイルとフォルダーが wiki ツリーで非表示のままになるため、不要な乱雑さが減少します。

この機能は、 この提案チケットに基づいて優先順位が付けられました。

短い Wiki と読み取り可能な Wiki ページの Url

Wiki ページリンクを共有するために複数行の URL を使用する必要がなくなりました。 URL のページ Id を利用してパラメーターを削除することで、URL を短くして読みやすくしています。

Url の新しい構造は次のようになります。

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Wiki ページのウェルカム ページの新しい URL のAzure DevOpsを次に示 します。

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

これは、この機能提案チケットに づいて優先順位が付けDeveloper Community。

Wiki ページを編集する同期スクロール

編集ウィンドウとプレビュー ウィンドウの間の同期スクロールを使用すると、Wiki ページの編集が簡単になりました。 一方の側をスクロールすると、対応するセクションをマップするためにもう一方の側が自動的にスクロールされます。 トグル ボタンを使用して、同期スクロールを無効にできます。

同期スクロール アイコンが呼び出され、その上に [同期されたスクロールを無効にする] トグル ボタンが表示されている Wiki ツール バーのスクリーンショット。

注意

同期スクロール トグルの状態は、ユーザーとアカウントごとに保存されます。

Wiki ページのページ アクセス

Wiki ページのページ アクセスに関する分析情報を取得できます。 このREST API過去 30 日間の情報にアクセスできます。 このデータを使用して、Wiki ページのレポートを作成できます。 さらに、このデータをデータ ソースに格納し、ダッシュボードを作成して、最も多く表示されるページの上位 n ページなど、特定の分析 情報を取得できます

また、すべてのページで過去 30 日間の集計されたページ アクセス数も表示されます。

Wiki ページの以前のアクセスを示すスクリーンショット。

注意

ページ アクセスは、15 分間隔で特定のユーザーによってページ ビューとして定義されます。

レポート

パイプラインの失敗と期間のレポート

メトリックと分析情報は、パイプラインのスループットと安定性を継続的に向上させるのに役立ちます。 パイプラインに関する分析情報を提供するために、2 つの新しいレポートが追加されました。

  1. パイプラインの失敗レポートには、ビルド パスレートと失敗の傾向が表示されます。 また、エラーの最大数に寄与しているパイプライン内のタスクについての洞察を得るために、タスクの失敗の傾向も表示されます。

パイプラインパスレートバッジ、テスト成功率バッジ、およびパイプライン期間バッジを表示する [分析] タブを示すスクリーンショット。

パイプラインエラーレポートを示すスクリーンショット。

  1. パイプライン期間レポートは、パイプラインの実行にかかった時間の傾向を示します。 また、パイプライン内のどのタスクに最も時間がかかっているかも示しています。

クエリ結果ウィジェットの機能強化

[クエリ結果] ウィジェット は、最も人気のあるウィジェットの1つであり、適切な理由があります。 ウィジェットには、クエリの結果がダッシュボードに直接表示され、多くの状況で役立ちます。

この更新プログラムを使用すると、多数の長い待機が加えられました。

  • これで、ウィジェットに表示する列をいくつでも選択できるようになりました。 5列の制限はありません。
  • ウィジェットは、1x1 から10x10 までの すべてのサイズをサポート しています。
  • 列のサイズを変更すると、 列の幅が保存 されます。
  • ウィジェットを全画面表示に拡張 することができます。 展開すると、クエリによって返されるすべての列が表示されます。

潜在顧客とサイクルのタイムウィジェットの高度なフィルター処理

チームはリードタイムとサイクル時間を使用して、開発パイプラインを通じて作業にかかる時間を確認し、最終的に顧客に価値を提供します。

これまで、 潜在顧客とサイクルの時間ウィジェット では、"チームが優先度の高い項目を終了するのにどれくらいの時間がかかっているか" という質問をするための高度なフィルター条件がサポートされていませんでした。

このような更新に関する質問は、ボードスイムレーンにフィルターを適用することによって回答できます。

[スイムレーン] セクションが [構成] ダイアログボックスに表示されているスクリーンショット。

また、グラフに表示される作業項目を制限するために、作業項目フィルターも含まれています。

[フィールド条件] セクションが呼び出された [構成] ダイアログ ボックスを示すスクリーンショット。

ストーリー ポイントを使用したインライン スプリント のバーンダウン

スプリント バーンダウンをストーリー別にバーンダウンできる。 これにより、 からフィードバックが送信Developer Community。

スプリント ハブから [分析] タブを選択します。次に、次のようにレポートを構成します。

  1. ストーリーのバックログを選択する
  2. ストーリー ポイントの合計に対 するバーンダウンを選択する

ストーリー ポイントを使用したインライン スプリント のバーンダウンを示すスクリーンショット。

求めだったすべてのものを含むスプリント バーンダウン ウィジェット

新しいスプリント バーンダウン ウィジェットでは、ストーリー ポイント、タスク数、またはカスタム フィールドの合計によるダウンダウンがサポートされています。 機能またはエピックのスプリント バーンダウンを作成できます。 ウィジェットには、平均バーンダウン、完了率、スコープの増加が表示されます。 チームを構成して、同じダッシュボードに複数のチームのスプリント バーンダウンを表示できます。 このすべての情報を表示するために、ダッシュボードで最大 10x10 のサイズを変更できます。

新しいスプリント バーンダウン ウィジェットを示すショット。

試してみるには、ウィジェット カタログから追加するか、既存のスプリント バーンダウン ウィジェットの構成を編集し、[今すぐ新しいバージョンを試す] ボックスを オンにします。

注意

新しいウィジェットでは Analytics が使用されます。 Analytics にアクセスできない場合は、従来のスプリント バーンダウンを維持しました。

インライン スプリント のバーンダウン サムネイル

スプリントバーンダウンは元に戻ります。 いくつかのスプリントの前に、スプリントバーンダウンと Taskboard ヘッダーからコンテキスト内スプリントバーンダウンを削除しました。 フィードバックに基づいて、スプリントバーンダウンサムネイルが改善され、再導入されました。

インラインスプリントバーンダウンサムネイルを示すスクリーンショット。

サムネイルをクリックすると、より大きなバージョンのグラフがすぐに表示され、[分析] タブで完全なレポートを表示することができます。完全なレポートに加えられた変更は、ヘッダーに表示されるグラフに反映されます。 これで、残りの作業量だけではなく、ストーリー、ストーリーポイント、またはタスクの数に基づいて、バーンダウンに構成できるようになりました。

チームを使用せずにダッシュボードを作成する

これで、チームに関連付けずにダッシュボードを作成できるようになりました。 ダッシュボードを作成するときに、 プロジェクトのダッシュボード の種類を選択します。

[ダッシュボードの作成] ダイアログボックスが表示され、[プロジェクトダッシュボード] オプションが選択および呼び出されたスクリーンショット。

プロジェクトダッシュボードはチームダッシュボードに似ていますが、チームに関連付けられていない点が異なります。また、ダッシュボードを編集または管理できるユーザーを決定することもできます。 チームダッシュボードと同様に、プロジェクト内のすべてのユーザーが表示できます。

チームコンテキストを必要とするすべての Azure DevOps ウィジェットが更新され、構成でチームを選択できるようになりました。 これらのウィジェットをプロジェクトダッシュボードに追加し、必要な特定のチームを選択できます。

チームのドロップダウンのスクリーンショット。

注意

カスタムウィジェットまたはサードパーティウィジェットの場合、プロジェクトダッシュボードは、既定のチームのコンテキストをそれらのウィジェットに渡します。 チームコンテキストに依存するカスタムウィジェットがある場合は、チームを選択できるように構成を更新する必要があります。


フィードバック

皆様のご意見をお待ちしております。 問題を報告したり、アイデアを提供したり、 開発者コミュニティ から追跡したり、 Stack Overflowに関するアドバイスを受けたりすることができます。


ページのトップへ