NuGet、npm、およびその他の成果物タスクでプロキシがサポートされる - Sprint 147 Update

  • [アーティクル]

Azure DevOps の Sprint 147 Update では、プロキシをサポートするために、成果物に関連するさまざまなパイプライン タスクを更新しました。 この更新プログラムでは、プロキシは npm、NuGet、.NET Core、ユニバーサル パッケージの各タスクで機能するようになりました。

詳細については、以下の 機能 の一覧を参照してください。

機能

全般:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Artifacts:

レポート:

Wiki:

全般

すべてのユーザーが新しいナビゲーションにアクセスするようになりました

このスプリントを使用すると、すべてのユーザーが新しいナビゲーションに移動されました。 ユーザーが前のナビゲーション モデルに戻ることを許可したプレビュー機能のトグルが削除されました。 Web ポータルでのナビゲーションの詳細については、「 Azure DevOps での Web ポータルのナビゲーション」を参照してください。

Azure Boards

作業項目の状態を#IDメンションに表示する

作業項目のメンション エクスペリエンスを強化するために、#IDを使用して作業項目をリンクするときに、より多くの情報が追加されました。 これで、ディスカッション セクションに、ID、タイトル、作業項目の種類に加えて、リンクした作業項目の状態が表示されます。

作業項目の状態を表示します。

このエクスペリエンスは、 ここで説明するように Wiki ページや pull request コメントでも使用できます。 詳細については、#IDを使用して作業項目にリンクする方法に関するドキュメント を参照してください。

Azure Repos

pull request で左または右のファイルのみを表示する

現在、pull request でファイルの変更を表示する場合は、サイド バイ サイド diffモードまたはインライン diff モードを使用できます。 多くのユーザーが、元のファイルまたは変更されたファイルを比較せずに表示したいだけのフィードバックを受け取っています。 そのため、左側のファイルまたは右のファイルを個別に表示できる新しいオプションが追加されました。

pull request で左または右のファイルのみを表示します。

Azure Pipelines

削除されたリリース パイプラインを復元する

未使用のリリース パイプラインを削除すると、リリース パイプラインの一覧をクリーン維持するのに役立ちますが、誤って何かを削除する場合があります。 この更新プログラムでは、過去 30 日以内に削除されたリリース パイプラインを復元できるようになりました。 [リリース] ページの左側のパネルに新しいタブが追加され、削除されたリリース パイプラインの一覧が表示されます。 このビューから削除されたリリース パイプラインを復元するには、一覧からパイプラインを選択し、[ 復元 ] ボタンをクリックします。

削除されたリリース パイプラインを復元します。

新しいパイプラインの YAML ファイルは、ボットではなく ID によってコミットされます

パイプラインの作成時に、Azure Pipelines は必要に応じて YAML ファイルをリポジトリにコミットし、パイプラインの pull request を作成します。 以前は、リポジトリが GitHub 上にあり、 Azure Pipelines GitHub アプリ がインストールされている場合、コミットとプル要求は GitHub アプリによって作成されたように見えました: "Azure Pipelines [bot]"。 この更新プログラムでは、GitHub アプリではなく、パイプラインの作成者として GitHub ID が表示されます。

任意のブランチまたはパス内の既存の YAML ファイルからパイプラインを作成する

現在、Azure Pipelines は、新しいパイプラインを作成するときに、既定のブランチ内のリポジトリのルートにある または .azure-pipelines.yml という名前azure-pipelines.ymlの既存の YAML ファイルを検出して自動的に使用します。 この更新プログラムでは、別の名前またはパスを持つ既存の Azure Pipelines YAML ファイル、または既定のブランチ以外のファイルを選択できます。

既存のファイルを選択するには、[ 新しいビルド パイプライン ウィザードの構成] ページで [ 既存の Azure Pipelines YAML ファイル] を選択します。 次に、ブランチを選択し、参照して YAML ファイル パスを選択します。

任意のブランチまたはパス内の既存の YAML ファイルからパイプラインを作成します。

GitHub pull request コメントを使用してパイプラインを実行する

この更新プログラムでは、パイプラインまたはテスト スイートを実行して、その PR のコメント セクションから GitHub pull request を検証できます。 すべての所有者またはコラボレーターは、ビルドをトリガーするために または /AzurePipelines run <pipeline_name> を使用/AzurePipelines runして pull request にコメントできます。

モニカ/azpーを /AzurePipelines と省略することもできます。 この機能の種類の詳細については、コメントを参照 /azp help してください。

GitHub pull request コメントを使用してパイプラインを実行します。

pull request 検証ビルドを承認されたチーム メンバーに制限する

pull request 検証ビルドを実装してブランチの品質を保護することをお勧めします。 これまで、これらの検証ビルドは GitHub pull request によって自動的にトリガーされていました。これは、レビューなしでビルドが開始されるため、リスクが高い可能性があります。

この更新プログラムでは、pull request 検証ビルドがチームによって承認されるように要求できます。 これを行うには、パイプラインの設定で [トリガー] タブを選択します。 次に、[Pull request validation]\(Pull request の検証\) で、[ コラボレーターの pull request コメントのビルドのみをトリガー する] を有効にし、パイプラインを保存します。

これで、pull request 検証ビルドは自動的にはトリガーされません。 リポジトリの所有者または共同作成者は、 または /AzurePipelines run <pipeline_name>を使用して pull request にコメントを付けることで、検証ビルドを/AzurePipelines runトリガーできます。

pull request 検証ビルドを承認されたチーム メンバーに制限します。

長いファイル パスを使用してビルド成果物を発行する

これまでは、パスが 233 文字を超えるビルド成果物をアップロードできなくなるという制限がありました。 これにより、ファイル パスが制限より長い Linux ビルドと macOS ビルドからコード カバレッジの結果をアップロードできなくなる可能性があります。 この更新プログラムでは、長いパスをサポートするように制限を拡張しました。

[パイプライン テスト] タブの新しい拡張機能コントリビューション ポイント

このスプリントでは、パイプラインの [テスト結果] タブに 2 つの新しいコントリビューション ポイントを追加することで、拡張機能フレームワークをより強力なものにし続けました。 これにより、 Marketplace 拡張機能 を使用して、よりカスタマイズされたレポート エクスペリエンスを提供し、さらに対話機能を追加できます。

2 つのコントリビューション ポイントは次のとおりです。

  1. ツール バーの [カスタム アクション] ボタン

    API のデータの更新や、テスト結果のメタデータを使用したカスタム ツールの実行などのアクションを実行したい場合があります。 このコントリビューション ポイントを使用すると、選択したテスト結果の即時コンテキストを使用してカスタム アクションを [カスタム アクション] ボタンに追加する拡張機能を作成できます。

    ツール バーの [カスタム アクション] ボタン。

  2. 詳細ウィンドウの [カスタム詳細] タブ

    さまざまなテスト レポート消費ワークフローがあり、デバッグと分析のために失敗したテストに対して異なるデータ ポイントを表示したい場合があります。 このコントリビューション ポイントを使用すると、データ グリッドでテスト結果行を選択したときに表示される新しいタブを詳細ウィンドウに追加できます。 この新しいタブでは、静的コンテンツまたは内部 API または外部 API を使用してフェッチされた動的データを含むビューを表示できます。

Azure Artifacts

これまで、成果物関連のビルド タスクの多くは Azure Pipelines のプロキシ インフラストラクチャを完全にサポートしていなかったため、オンプレミス エージェントからのタスクを使用する際の課題が発生しました。 この更新プログラムでは、次のタスクにプロキシのサポートが追加されました。

フィードを管理できる代理人

Azure Artifacts では、プロジェクト コレクション管理者 (PCA) は常に Azure DevOps organization内のすべてのフィードを管理できました。 この更新プログラムを使用すると、PCA は他のユーザーやグループにもこの機能を提供できるため、フィードを管理する機能を委任できます。

レポート

テスト結果の傾向 (詳細) ウィジェット

Azure DevOps organizationに Analytics 拡張機能をインストールしたユーザーは、テスト結果傾向 (詳細) ウィジェットを使用できるようになりました。 これは、複数のビルドとリリースのテスト データをほぼリアルタイムで可視化します。 [テスト結果の傾向 (詳細)] ウィジェットには、パイプラインまたはパイプライン全体のテスト結果の傾向が表示されます。 これを使用して、テスト、合格率、テスト期間の 1 日あたりのカウントを追跡できます。 テスト品質を経時的に追跡し、テスト関連情報を改善することは、正常な DevOps パイプラインを維持する上で不可欠です。

テスト結果の傾向 (詳細) ウィジェット。

テスト結果の傾向 (詳細) ウィジェットは、テスト結果の外れ値を見つけ、次のような質問に答えるのに役立ちます。テストの実行に通常よりも時間がかかっていますか? 全体的な合格率に影響を与えるテスト ファイルまたはパイプラインは何ですか? 実行時間の長いテストは何ですか?

これらの質問に答えるために、ウィジェットには次の機能があります。

  • 合格率の傾向とテスト結果またはテスト期間の数を表示します
  • 複数のビルド パイプラインまたはリリース パイプラインに基づいてテスト結果を表示します
  • 結合されたグラフ作成オプションを使用して、同じ傾向に対して 2 つのメトリックを表示します
  • テスト結果によって時間の経過に伴うテスト数をフィルター処理する
  • ブランチまたはテストですべてのテスト結果をフィルター処理する
  • 優先度や環境などのテスト属性によってメトリックをスタックする
  • テスト ファイル、所有者、またはパイプラインでデータをグループ化する

ウィジェットは高度に構成可能であり、さまざまなシナリオで使用できます。

Wiki

これまで、リンクされたページの名前が変更または移動された場合、共有 Wiki ページのリンクが壊れていました。 この更新プログラムでは、ページ ID を URL に追加することで、永続的なリンクを導入しました。 これにより、Wiki が時間の経過と同時に変化しても、共有するリンクはそのまま残ります。

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

Wiki ページで作業項目の状態を表示する

この更新では、作業項目の状態をページに追加し、その ID とタイトルを追加することで、Wiki ページの作業項目のメンションを強化しました。

Wiki ページで作業項目の状態を表示します。

Pull Request コメントと Boards ディスカッションの作業項目参照にも、状態が表示されます。

この機能は提案に基づいて優先されました。

次の手順

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告したり、提案を提供したりします。

ご提案の送信

Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。

よろしくお願いします。

Alex Mullans