Azure DevOps Server 2022 Update 1 リリースノート

[アーティクル]
03/12/2024

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

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

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

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

Azure DevOps Server 2022 Update 1 Patch 3 リリース日: 2024 年 3 月 12 日

ファイル	Sha-256 ハッシュ
devops2022.1patch3.exe	E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Azure DevOps Server 2022 Update 1 用パッチ 3 をリリースしました。これには、次の修正プログラムが含まれています。

パッチ 2 のインストール後にプロキシサーバーが動作を停止する問題を解決しました。
拡張機能の詳細ページで、英語以外の言語に影響するレンダリングの問題を修正しました。

Azure DevOps Server 2022 Update 1 Patch 2 リリース日: 2024 年 2 月 13 日

ファイル	Sha-256 ハッシュ
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

Azure DevOps Server 2022 Update 1 の修正プログラム 2 をリリースしました。これには、次の修正プログラムが含まれています。

検索拡張機能での詳細ページレンダリングの問題を修正しました。
プロキシキャッシュフォルダーで使用されているディスク領域が正しく計算されず、フォルダーが正しくクリーンアップされないバグを修正しました。
CVE-2024-20667: リモートコード実行の脆弱性Azure DevOps Server。

Azure DevOps Server 2022 Update 1 Patch 1 リリース日: 2023 年 12 月 12 日

ファイル	Sha-256 ハッシュ
devops2022.1patch1.exe	9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

Azure DevOps Server 2022 Update 1 の修正プログラム 1 をリリースしました。これには、次の修正プログラムが含まれています。

パイプラインの実行をキューに入れたときの設定 requested for を禁止します。

Azure DevOps Server 2022 Update 1 リリース日: 2023 年 11 月 28 日

注意

このリリースには、次の 2 つの既知の問題があります。

エージェントのバージョンは、Azure DevOps Server 2022.1 にアップグレードし、エージェントプール構成で Update Agent を使用した後は更新されません。現在、この問題を解決するための修正プログラムに取り組んでおり、進行中のDeveloper Communityで更新プログラムを共有します。それまでの間、この問題の回避策については、このDeveloper Community チケットを参照してください。
Maven 3.9.x の互換性。 Maven 3.9.x では、既定の Maven リゾルバートランスポートを Wagon からネイティブ HTTP に更新することで、Azure Artifacts で破壊的変更が導入されました。これにより、https ではなく http を使用しているお客様に対して 401 認証の問題が発生します。この問題の詳細については、こちらを参照してください。回避策として、プロパティ -Dmaven.resolver.transport=wagonで Maven 3.9.x を引き続き使用できます。この変更により、Maven は Wagon Resolver Transport を使用するように強制されます。詳細については、こちらのドキュメントを参照してください。

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

注意

Maven 3.9.x の互換性には既知の問題があります。 Maven 3.9.x では、既定の Maven リゾルバートランスポートを Wagon からネイティブ HTTP に更新することで、Azure Artifacts で破壊的変更が導入されました。これにより、https ではなく http を使用しているお客様に対して 401 認証の問題が発生します。この問題の詳細については、こちらを参照してください。

回避策として、プロパティ -Dmaven.resolver.transport=wagonで Maven 3.9.x を引き続き使用できます。この変更により、Maven は Wagon Resolver Transport を使用するように強制されます。詳細については、こちらのドキュメントを参照してください。

Azure DevOps Server 2022 Update 1 RC2 リリース日: 2023 年 10 月 31 日

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

注意

このリリースでは、次の修正が行われています。

アップストリームエントリで表示名の変更が解決されないローカルフィードの問題を修正しました。
[検索] ページの [コード] から別のタブにタブを切り替えたときに、予期しないエラーが発生しました。
中国語、日本語、韓国語 (CJK) 統合 Ideograph を使用して新しい作業項目の種類を作成中にエラーが発生しました。チームプロジェクト名またはファイルに CJK が含まれている場合、ゲートチェックインの RAW ログに疑問符が表示されました。
Java 仮想マシン (JVM) が Elastic Search プロセスに十分なメモリを割り当てることができない検索のインストール中の問題を修正しました。検索構成ウィジェットでは、Elastic Search にバンドルされている Java Development Kit (JDK) が使用されるようになりました。そのため、ターゲットサーバーにプレインストールされている Java ランタイム環境 (JRE) への依存関係が削除されます。

Azure DevOps Server 2022 Update 1 RC1 リリース日: 2023 年 9 月 19 日

Azure DevOps Server 2022.1 RC1 には、多くの新機能が含まれています。主な特徴:

すべてのパブリック REST API で詳細な PAT スコープがサポートされます
[配信プラン] ページの [最後にアクセスされた列]
配信計画に対するすべての依存関係を視覚化する
配信計画の@CurrentIteration マクロ
クラシックパイプラインでのビルドアクセストークンの既定のスコープとして設定されている現在のプロジェクト
クエリ結果ウィジェットに親を表示する
ダッシュボードのコピー
Wiki ページでの追加の図の種類のサポート
Container Registry サービス接続で Azure マネージド ID を使用できるようになりました

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

全般
Boards
Repos
パイプライン
アイテム
レポート
Wiki

全般

すべてのパブリック REST API で詳細な PAT スコープがサポートされます

以前は、パブリックに文書化された Azure DevOps REST API の数がスコープ (作業項目の読み取りなど) に関連付けられていないことが原因で、お客様は完全なスコープを使用して、個人用アクセストークン (PAT) などの非対話型認証メカニズムを通じてこれらの API を使用していました。完全な範囲の個人用アクセストークンを使用すると、悪意のあるユーザーの手に到達する可能性がある場合のリスクが高まります。これは、多くのお客様が PAT の使用と動作を制限するためにコントロールプレーンポリシーを最大限に活用しなかったメイン理由の 1 つです。

これで、すべてのパブリック Azure DevOps REST API がに関連付けられ、詳細な PAT スコープがサポートされるようになりました。現在、フルスコープの PAT を使用してパブリック Azure DevOps REST API のいずれかに対して認証を行っている場合は、不要なアクセスを回避するために、API によって受け入れられる特定のスコープを持つ PAT に移行することを検討してください。特定の REST API でサポートされている詳細な PAT スコープについては、ドキュメントページの「セキュリティ」セクションを参照してください。さらに、ここにスコープのテーブルがあります。

拡張機能にはスコープが表示されます

Azure DevOps コレクションに拡張機能をインストールする場合は、インストールの一部として拡張機能に必要なアクセス許可を確認できます。ただし、インストールされると、拡張機能のアクセス許可は拡張機能の設定に表示されません。これは、インストールされている拡張機能の定期的なレビューを実行する必要がある管理者にとって課題となっています。これで、拡張機能の設定に拡張機能のアクセス許可が追加されました。これは、拡張機能を保持するかどうかを確認し、情報に基づいた決定を行うのに役立ちます。

Marketplace にデプロイする個人用アクセストークンを作成する

Boards

[配信プラン] ページの [最終アクセス] 列

[配信プラン] ディレクトリページには、プロジェクトに定義されているプランの一覧が表示されます。 [名前]、[作成者]、[説明]、[最終構成済み]、または [お気に入り] で並べ替えることができます。この更新プログラムでは、ディレクトリページに [最後にアクセスした列] が追加されました。これにより、配信プランが最後に開かれて確認された日時が表示されます。その結果、使用されなくなり、削除できるプランを簡単に特定できます。

[配信プラン] ページの [最終アクセス] フィールドをデモする GIF。

配信プランに対するすべての依存関係を視覚化する

配信プランでは、作業項目間の依存関係を常に表示する機能が提供されています。依存関係線は 1 つずつ視覚化できます。このリリースでは、画面上のすべての作業項目のすべての依存関係行を表示できるようにすることで、エクスペリエンスが向上しました。配信プランの右上にある [依存関係の切り替え] ボタンをクリックするだけです。もう一度クリックして線をオフにします。

配信プランページですべての依存関係を視覚化する Gif をデモします。する

新しい作業項目リビジョンの制限

ここ数年、自動化されたツールを使用したプロジェクトコレクションでは、何万もの作業項目のリビジョンが生成されるのを見てきました。これにより、作業項目フォームとレポート REST API のパフォーマンスと使いやすさに関する問題が発生します。この問題を軽減するために、Azure DevOps Service に 10,000 の作業項目リビジョン制限を実装しました。制限は REST API を使用した更新にのみ影響し、作業項目フォームには影響しません。

リビジョンの制限と自動ツールでの対処方法の詳細については、ここをクリックしてください。

配信計画チームの制限を 15 から 20 に引き上げる

配信プランを使用すると、プロジェクトコレクション全体で複数のバックログと複数のチームを表示できます。以前は、さまざまなプロジェクトのバックログとチームの組み合わせを含む 15 個のチームバックログを表示できました。このリリースでは、上限を 15 から 20 に増やしました。

Reporting Work Item Links Get API のバグを修正しました

リンクの種類に対して正しい remoteUrl 値を返すように、Reporting Work Item Links Get API のバグを System.LinkTypes.Remote.Related 修正しました。この修正の前に、間違ったプロジェクトコレクション名と不足しているプロジェクト ID を返していました。

一時的なクエリ REST エンドポイントを作成する

拡張機能の作成者が、クエリ文字列を介して作業項目クエリ言語 (WIQL) ステートメントを渡すことで、未保存のクエリを実行しようとするインスタンスがいくつか見られます。これは、クエリ文字列の長さに関するブラウザーの制限に達する大きな WIQL ステートメントがない限り、正常に動作します。これを解決するために、ツール作成者が一時的なクエリを生成できるように、新しい REST エンドポイントを作成しました。応答の ID を使用して querystring を介して渡すと、この問題は解消されます。

詳細については、一時クエリ REST API のドキュメントページを参照してください。

バッチ削除 API

現在、ごみ箱から作業項目を削除する唯一の方法は、この REST API を使用して一度に 1 つずつ削除することです。これは遅いプロセスである可能性があり、何らかの質量クリーンを実行しようとするとレート制限の対象になります。これに対して、作業項目をバッチで削除または破棄するための新しい REST API エンドポイントを追加しました。

@CurrentIteration 配信プランのマクロ

この更新プログラムでは、配信プランのスタイルの @CurrentIteration マクロのサポートが追加されました。このマクロを使用すると、プランの各行のチームコンテキストから現在のイテレーションを取得できます。

配信プランで CurrentIteration マクロをデモする Gif。

配信プランのカードサイズ変更ロジック

フィーチャーやエピックを追跡するときに、誰もがターゲットの日付や開始日を使用するわけではありません。日付と反復パスの組み合わせを使用することを選択する人もいます。このリリースでは、イテレーションパスと日付フィールドの組み合わせを使用する方法に応じて適切に設定するロジックを改善しました。

たとえば、ターゲット日付が使用されておらず、カードのサイズを変更すると、ターゲット日付を更新する代わりに新しいイテレーションパスが設定されます。

コメントのコピーリンクをデモする GIF。

バッチ更新の機能強化

作業項目バッチ更新 API の 7.1 バージョンにいくつかの変更を加えた。これには、パフォーマンスの軽微な改善と部分的な障害の処理が含まれます。つまり、1 つのパッチが失敗しても、他のパッチが失敗した場合、他のパッチは正常に完了します。

バッチ更新 REST API の詳細については、ここをクリックしてください。

バッチ削除 API

バッチ内の作業項目を削除または破棄するこの新しい REST API エンドポイントが一般公開されました。詳しくは、こちらをクリックしてください。

共有可能な候補リストフィールドの編集を禁止する

ユーザー設定フィールドはプロセス間で共有されます。プロセス管理者がフィールドに値を追加または削除できるため、選択リストフィールドに問題が発生する可能性があります。その場合、変更は、それを使用するすべてのプロセスでそのフィールドに影響します。

この問題を解決するために、コレクション管理者がフィールドの編集を "ロック" する機能が追加されました。選択リストフィールドがロックされている場合、ローカルプロセス管理者はその選択リストの値を変更できません。フィールドは、プロセスからのみ追加または削除できます。

Gif を使用して、共有可能な選択リストフィールドの編集をデモします。します

新しいコメントの保存アクセス許可

作業項目のコメントのみを保存する機能は、開発者コミュニティの上位の要求でした。この機能が実装されたことをお知らせします。まず、最も一般的なシナリオを確認しましょう。

「一部のユーザーが作業項目フィールドを編集できないようにしたいが、ディスカッションに投稿できるようにしたい」

これを行うには、[プロジェクトの設定] [プロジェクト構成>>] 領域のパスに移動する必要があります。次に、選択した領域パスを選択し、[セキュリティ] をクリックします。

エリアパス

新しいアクセス許可 "このノードの作業項目コメントの編集" に注目してください。既定では、アクセス許可は [未設定] に設定されています。つまり、作業項目は以前とまったく同じように動作します。グループまたはユーザーにコメントの保存を許可するには、そのグループまたはユーザーを選択し、アクセス許可を [許可] に変更します。

新しいアクセス許可

ユーザーがこの領域パスで作業項目フォームを開くと、コメントを追加できますが、他のどのフィールドも更新できません。

共有可能な候補リストフィールドのデモ編集。

私たちは、あなたが私たちのと同じくらいこの機能を愛することを願っています。ご意見やご提案がある場合は、お知らせください。

対話型ボードレポート

Boards ハブにある対話型レポートは、ホストされているバージョンの製品で数年間アクセスできます。古い累積フローダイアグラム、ベロシティ、スプリントバーンダウンチャートを置き換えます。このリリースでは、それらを利用可能にしています。

これらのグラフを表示するには、[かんばんボード]、[バックログ]、[スプリント] ページの [ 分析 ] タブの場所をクリックします。

Repos

ブランチ作成者に対する "ポリシーの編集" アクセス許可の削除

以前は、新しいブランチを作成したときに、そのブランチのポリシーを編集するアクセス許可が付与されました。この更新プログラムでは、リポジトリに対して "アクセス許可の管理" 設定がオンになっている場合でも、このアクセス許可を付与しないように既定の動作を変更しています。

アクセス許可管理イメージ。

セキュリティアクセス許可の継承またはグループメンバーシップによって明示的に (手動または REST API を使用して) 付与された "ポリシーの編集" アクセス許可が必要です。

Pipelines

クラシックパイプラインでのビルドアクセストークンの既定のスコープとして設定されている現在のプロジェクト

Azure Pipelines では、ジョブアクセストークンを使用して、実行時に Azure DevOps 内の他のリソースにアクセスします。ジョブアクセストークンは、実行時に各ジョブについて Azure Pipelines によって動的に生成されるセキュリティトークンです。以前は、新しいクラシックパイプラインを作成するときに、アクセストークンの既定値が Project Collection に設定されていました。この更新プログラムでは、新しいクラシックパイプラインを作成するときに、ジョブ承認スコープを 既定のプロジェクト として設定します。

ジョブアクセストークンの詳細については、 Access リポジトリ、成果物、およびその他のリソースに関するドキュメントを参照してください。

クラシックビルドパイプラインでのアクセストークンの既定のスコープの変更

クラシックビルドパイプラインのセキュリティを向上させるために、新しいビルドパイプラインを作成する場合、 ビルドジョブの承認スコープ は既定で Project になります。これまでは、 以前はプロジェクトコレクションでした。詳細については、「ジョブアクセストークン」を参照してください。この変更は、既存のパイプラインには影響しません。この時点から作成した新しいクラシックビルドパイプラインにのみ影響します。

ServiceNow の San Diego、Tokyo & ユタ州のリリースに対する Azure Pipelines のサポート

Azure Pipelines には、ServiceNow との既存の統合があります。統合は、ServiceNow のアプリと Azure DevOps の拡張機能に依存しています。これで、ServiceNow の San Diego、Tokyo & ユタバージョンで動作するようにアプリが更新されました。この統合が確実に機能するように、 ServiceNow ストアから新しいバージョンのアプリ (4.215.2) にアップグレードします。

詳細については、 ServiceNow Change Management との統合に関するドキュメントを参照してください。

GitHub Enterprise 統合にプロキシ URL を使用する

Azure Pipelines は、オンプレミスの GitHub Enterprise Servers と統合され、継続的インテグレーションと PR ビルドを実行します。場合によっては、GitHub Enterprise Server はファイアウォールの内側にあり、トラフィックをプロキシサーバー経由でルーティングする必要があります。このシナリオをサポートするために、Azure DevOps の GitHub Enterprise Server サービス接続でプロキシ URL を構成できます。以前は、Azure DevOps からのすべてのトラフィックがこのプロキシ URL を介してルーティングされていたわけではありませんでした。この更新プログラムでは、次のトラフィックを Azure Pipelines からルーティングしてプロキシ URL を経由するようにしています。

ブランチを取得する
pull request 情報を取得する
ビルド状態を報告する

Container Registry サービス接続で Azure マネージド ID を使用できるようになりました

Azure Container Registryの Docker Registry サービス接続を作成するときに、システム割り当てマネージド ID を使用できます。これにより、セルフホステッド Azure Pipelines エージェントに関連付けられているマネージド ID を使用してAzure Container Registryにアクセスできるため、資格情報を管理する必要がなくなります。

承認に対する変更のための新しい Docker レジストリサービス接続

注意

Azure Container Registryへのアクセスに使用されるマネージド ID には、AcrPull ロールや AcrPush ロールなど、適切な Azure ロールベースのAccess Control (RBAC) の割り当てが必要です。

Kubernetes Service Connection 用に作成された自動トークン

Kubernetes 1.24 以降、新しい Kubernetes サービス接続を作成するときにトークンが自動的に作成されなくなりました。この機能を再度追加しました。ただし、AKS にアクセスするときは Azure サービス接続を使用することをお勧めします。詳細については、 Kubernetes タスクを使用している AKS のお客様向けのサービス接続ガイダンスに関するブログ記事を参照してください。

Kubernetes タスクで kubelogin がサポートされるようになりました

kubelogin をサポートするために、KuberentesManifest@1、HelmDeploy@0、Kubernetes@1、AzureFunctionOnKubernetes@1タスクを更新しました。これにより、Azure Active Directory 統合で構成された Azure Kubernetes Service (AKS) をターゲットにできます。

Kubelogin は、ホストされているイメージにプレインストールされていません。上記のタスクで kubelogin が使用されていることを確認するには、それに依存するタスクの前に KubeloginInstaller@0 タスクを挿入してインストールします。

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

パイプラインのアクセス許可の改善を体験する

パイプラインのアクセス許可の管理に関するエクスペリエンスが改善され、パイプラインで以前にサービス接続などの保護されたリソースが使用されていたかどうかを、アクセス許可システムが記憶するようにしました。

以前は、保護されたリソースを作成したときに [すべてのパイプラインにアクセス許可を付与する] をオフにした後、リソースへのアクセスを制限した場合、パイプラインにはリソースを使用するための新しい承認が必要でした。この動作は、新しい承認が必要ないリソースへの後続の開始および終了アクセスと矛盾していました。これが修正されました。

パイプラインの承認と承認とチェックを管理するための新しい PAT スコープ

PAT トークンのリークによる損害を制限するために、という名前 Pipeline Resourcesの新しい PAT スコープを追加しました。この PAT スコープは、サービス接続などの保護されたリソースを使用してパイプライン承認を管理する場合や、そのリソースの承認とチェックを管理する場合に使用できます。

Pipelines REST API 更新

次の REST API 呼び出しでは、次のように新しい PAT スコープがサポートされます。

承認の更新ではスコープがサポートされます Pipeline Resources Use
チェックの管理ではスコープがサポートされます Pipeline Resources Use and Manage
リソースのパイプラインのアクセス許可を更新すると、スコープがサポートされます Pipeline Resources Use and Manage
定義リソースがスコープをサポートすることを承認する Pipeline Resources Use and Manage
プロジェクトリソースがスコープをサポートすることを承認する Pipeline Resources Use and Manage

保護されたリソースをリソース管理者に対して開く制限

アプリケーションを安全にビルドしてデプロイする機能に不可欠なリソースのセキュリティを強化するために、Azure Pipelines では、すべてのパイプラインへのリソースへのアクセスを開くときに、リソースの種類の管理者ロールが必要になりました。

たとえば、パイプラインでサービス接続を使用できるようにするには、一般的なサービス Connections管理者ロールが必要です。この制限は、保護されたリソースを作成するとき、またはセキュリティ構成を編集するときに適用されます。

さらに、サービス接続を作成するときに、十分な権限がない場合は、[ すべてのパイプラインにアクセス許可を付与する] オプションが無効になります。

サービス Connections また、既存のリソースへのアクセスを開こうとしたときに、十分な権限がない場合は、このリソースのアクセスを開く権限がありませんというメッセージが表示されます。

パイプラインのアクセス許可

パイプライン REST API セキュリティの強化

Azure DevOps の REST API の大部分は、スコープ付き PAT トークンを使用します。ただし、その一部には、完全なスコープの PAT トークンが必要です。つまり、これらの API の一部を使用するには、[フルアクセス] を選択して PAT トークンを作成する必要があります。このようなトークンは、REST API の呼び出しに使用できるため、セキュリティ上のリスクがあります。各 REST API を特定のスコープに組み込むことで、完全にスコープが設定されたトークンの必要性を取り除くために、Azure DevOps 全体で改善が行われています。この作業の一環として、リソースのパイプラインアクセス許可を更新する REST API には、特定のスコープが必要になりました。スコープは、使用が承認されているリソースの種類によって異なります。

Code (read, write, and manage) 型のリソースの場合 repository
Agent Pools (read, manage)型と型queueのリソースの場合はまたはEnvironment (read, manage)agentpool
Secure Files (read, create, and manage) 型のリソースの場合 securefile
Variable Groups (read, create and manage) 型のリソースの場合 variablegroup
Service Endpoints (read, query and manage) 型のリソースの場合 endpoint
Environment (read, manage) 型のリソースの場合 environment

パイプラインのアクセス許可を一括編集するには、引き続き完全スコープの PAT トークンが必要です。リソースのパイプラインアクセス許可の更新の詳細については、パイプラインのアクセス許可 - リソースのパイプラインのアクセス許可の更新に関するドキュメントを参照してください。

エージェントプールのきめ細かいアクセス管理

エージェントプールを使用すると、パイプラインを実行するマシンを指定および管理できます。

以前は、カスタムエージェントプールを使用していた場合、アクセスできるパイプラインを管理することは粗い粒度でした。すべてのパイプラインで使用を許可することも、各パイプラインにアクセス許可の要求を要求することもできます。残念ながら、エージェントプールへのパイプラインアクセス許可を付与した後は、パイプライン UI を使用して取り消すことができませんでした。

Azure Pipelines では、エージェントプールに対してきめ細かいアクセス管理が提供されるようになりました。このエクスペリエンスは、Service Connections のパイプラインアクセス許可を管理するエクスペリエンスと似ています。

承認に対する変更のための FabrikamFiber エージェントプール

すべてのパイプラインに保護されたリソースへのアクセスを許可しないようにする

サービス接続や環境などの保護されたリソースを作成する場合は、[ すべてのパイプラインにアクセス許可を付与 する] チェックボックスをオンにするオプションがあります。これまで、このオプションは既定でオンになっています。

これにより、パイプラインで新しい保護されたリソースを簡単に使用できるようになりますが、逆に、リソースにアクセスする権限を誤って多くのパイプラインに付与することが優先されます。

既定でセキュリティで保護された選択肢を昇格するために、Azure DevOps はチェックボックスをオフのままにします。

すべてのパイプラインへのアクセス許可の付与は、既定でオフに切り替えられます

短いシークレットのマスクを無効にする機能

Azure Pipelines は、ログ内のシークレットをマスクします。シークレットには、シークレットとしてマークされた変数、Azure Key Vaultにリンクされている変数グループの変数、またはサービス接続プロバイダーによってシークレットとしてマークされたサービス接続の要素を指定できます。

シークレット値の出現はすべてマスクされます。短いシークレット (例: '1'、'2'、'' など) をDevマスクすると、日付内の値を簡単に推測できます: 'Jan 3, 202***'
'3' がシークレットであることは明らかです。このような場合は、シークレットを完全にマスクしないことをお勧めします。値をシークレットとしてマークできない場合 (たとえば、値がKey Vaultから取得されます)、ノブをAZP_IGNORE_SECRETS_SHORTER_THAN最大 4 の値に設定できます。

ノードランナーのダウンロードタスク

Node 6 タスクランナーを除外するエージェントリリースを採用する場合、新しい Node ランナーを使用するために更新されていないタスクを実行する必要がある場合があります。このシナリオでは、Node End-of-Life ランナーに依存するタスクを引き続き使用する方法を提供します。ノードランナーのガイダンスに関するブログ投稿を参照してください。

次のタスクは、Node 6 ランナーを Just-In-Time でインストールする方法であるため、古いタスクを引き続き実行できます。

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

TFX ノードランナーの検証が更新されました

タスク作成者は、拡張機能パッケージ化ツール (TFX) を使用して拡張機能を発行します。ノードランナーバージョンで検証を実行するように TFX が更新されました。ノードランナーガイダンスのブログ投稿を参照してください。

ノード 6 ランナーを使用するタスクを含む拡張機能には、次の警告が表示されます。

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

パイプラインエージェントに Node 6 を手動でプレインストールする手順

エージェントフィードを使用するpipeline-場合は、エージェントに Node 6 が含まれていません。 Marketplace タスクがまだ Node 6 に依存していて、エージェントが NodeTaskRunnerInstaller タスクを使用できない場合 (接続の制限など)、Node 6 を個別にプレインストールする必要がある場合があります。これを実現するには、Node 6 ランナーを手動でインストールする方法に関する手順をチェックします。

パイプラインタスクの変更ログ

パイプラインタスクに対する変更をこの変更ログに発行するようになりました。これには、組み込みのパイプラインタスクに加えられた変更の完全な一覧が含まれます。以前の変更はさかのぼって公開されているため、変更ログにはタスクの更新履歴が表示されます。

リリースタスクで Microsoft Graph APIを使用する

Microsoft Graph APIを使用するようにリリースタスクを更新しました。これにより、タスクから AAD Graph APIの使用が削除されます。

タスクのパフォーマンス向上Windows PowerShell

タスクを使用して、パイプラインで自動化を定義できます。これらのタスク PowerShell@2 の 1 つは、パイプラインで PowerShell スクリプトを実行できるユーティリティタスクです。 PowerShell スクリプトを使用して Azure 環境をターゲットにするには、タスクを AzurePowerShell@5 使用できます。などの Invoke-WebRequest進行状況の更新を出力できる一部の PowerShell コマンドの実行速度が向上しました。これらのコマンドの多くがスクリプトに含まれている場合、または実行時間が長い場合は、この改善がより重要になります。この更新プログラムでは、 progressPreference タスクと AzurePowerShell@5 タスクの PowerShell@2 プロパティが既定でにSilentlyContinue設定されるようになりました。

.NET 6 上のパイプラインエージェント v3

パイプラインエージェントは、ランタイムとして .NET 3.1 Core を .NET 6 に使用するようにアップグレードされました。これにより、Apple シリコンと Windows Arm64 のネイティブサポートが導入されます。

.NET 6 を使用すると、エージェントのシステム要件に影響します。具体的には、次のオペレーティングシステムのサポートを削除します。CentOS 6、Fedora 29-33、Linux Mint 17-18、Red Hat Enterprise Linux 6。エージェントソフトウェアバージョン 3 のドキュメントを参照してください。

このスクリプトを使用して、サポートされていないオペレーティングシステムでエージェントを使用するパイプラインを識別できます。

重要

上記のいずれかのオペレーティングシステムで実行されているエージェントは、.NET 6 ベースのエージェントをロールアウトすると、更新または失敗しなくなることに注意してください。

エージェント VM 拡張機能でエージェントのバージョンを指定する

Azure VM は、 VM 拡張機能を使用してデプロイグループに含めることができます。 VM 拡張機能が更新され、必要に応じてインストールするエージェントのバージョンを指定できます。

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

クラシックパイプラインの作成を制御するための新しいトグル

Azure DevOps では、クラシックビルドパイプライン、クラシックリリースパイプライン、タスクグループ、デプロイグループの作成を無効にすることで、プロジェクトコレクションで YAML パイプラインのみを使用できるようになりました。既存のクラシックパイプラインは引き続き実行され、編集することはできますが、新しいパイプラインを作成することはできません。

Azure DevOps では、クラシックビルドパイプライン、クラシックリリースパイプライン、タスクグループ、デプロイグループの作成を無効にすることで、organizationで YAML パイプラインのみを使用できるようになりました。既存のクラシックパイプラインは引き続き実行され、編集することはできますが、新しいパイプラインを作成することはできません。

対応するトグルをオンにすると、プロジェクトコレクションレベルまたはプロジェクトレベルでクラシックパイプラインの作成を無効にすることができます。トグルは、「プロジェクト/プロジェクトの設定 - パイプライン ->> 設定」で確認できます。 2 つのトグルがあります。1 つはクラシック ビルド パイプライン用、もう 1 つはクラシック リリース パイプライン、デプロイグループ、タスクグループ用です。

クラシックパイプラインの作成を無効にする

トグルの状態は既定ではオフになっています。状態を変更するには管理者権限が必要です。トグルが organization レベルでオンになっている場合は、すべてのプロジェクトに対して無効化が適用されます。それ以外の場合、各プロジェクトは無効化を適用するかどうかを自由に選択できます。

クラシックパイプラインの作成を無効にすると、クラシックパイプライン、タスクグループ、およびデプロイグループの作成に関連する REST API が失敗します。 YAML パイプラインを作成する REST API は機能します。

"ステージの状態が変更されました" サービスフックイベントの実行に更新

サービスフックを使用すると、Azure DevOps のプロジェクトでイベントが発生したときに、他のサービスでタスクを実行できます。 [Run stage state changed]\(変更された実行ステージの状態 \) は、これらのイベントの 1 つです。 Run stage state changed イベントには、パイプラインの名前を含む実行に関する情報が含まれている必要があります。以前は、実行の ID と名前に関する情報のみが含まれていました。この更新プログラムでは、不足している情報を含むようにイベントを変更しました。

パイプライン実行の最後のコミットメッセージの表示を無効にする

以前は、パイプラインの実行を表示するときに最後のコミットメッセージを表示するために使用されたパイプライン UI。

最後のコミットメッセージの例

このメッセージは、たとえば、YAML パイプラインのコードがビルドされているコードを保持するリポジトリとは異なるリポジトリに存在する場合に、混乱を招く可能性があります。 Developer Communityから、すべてのパイプライン実行のタイトルに最新のコミットメッセージを追加することを有効または無効にする方法を求めるフィードバックが寄せされました。

この更新プログラムでは、という名前 appendCommitMessageToRunNameの新しい YAML プロパティを追加しました。これを正確に行うことができます。既定では、プロパティはに true設定されています。に false設定すると、パイプラインの実行にはのみが表示 BuildNumberされます。

ビルド番号を使用したパイプライン実行の例

最後のコミットメッセージを使用したパイプライン実行の例

Azure Resource Manager (ARM) テンプレートの最大サイズ 4 MB に合わせて Azure Pipeline の制限を引き上げた。

Azure Resource Manager テンプレートのデプロイタスクを使用して、Azure インフラストラクチャを作成できます。お客様からのフィードバックに応じて、Azure Pipelines 統合の制限を 2 MB から 4 MB に増やしました。これは、大規模なテンプレートの統合中にサイズ制約を解決する ARM テンプレートの最大サイズ 4 MB に合わせて調整されます。

パイプラインの実行状態の概要アイコン

このリリースでは、パイプライン実行の全体的な状態を簡単に把握できるようになりました。

多くのステージを持つ YAML パイプラインの場合、以前はパイプライン実行の状態を把握するのが困難でした。つまり、まだ実行されているか、完了しているかです。また、完了した場合の全体的な状態は、成功、失敗、または取り消しになります。実行状態の概要アイコンを追加することで、この問題を修正しました。

パイプラインステージのサイドパネル

YAML パイプラインには数十個のステージを含めることができますが、すべてのステージが画面に収まるわけではありません。パイプライン実行の概要アイコンは実行の全体的な状態を示しますが、失敗したステージや、たとえば、まだ実行されているステージを知ることは困難です。

このリリースでは、パイプラインステージのサイドパネルを追加しました。これにより、すべてのステージの状態をすばやく確認できます。その後、ステージをクリックして、そのログに直接移動できます。

パイプラインの更新

パイプライン UI の更新

サイドパネルでステージを検索する

ステージサイドパネルで探しているステージを見つけやすくなりました。ステージの状態 (実行中のステージや手動介入が必要なステージなど) に基づいて、ステージをすばやくフィルター処理できるようになりました。ステージの名前でステージを検索することもできます。

AZ Pipelines の更新

クイックアクションをステージする

パイプラインの [実行] 画面では、すべての実行ステージにすばやくアクセスできます。このリリースでは、ステージごとにアクションを実行できるステージパネルを追加しました。たとえば、失敗したジョブを簡単に再実行したり、ステージ全体を再実行したりできます。パネルは、次のスクリーンショットに示すように、すべてのステージがユーザーインターフェイスに収まらない場合に使用できます。

ステージが多すぎるパイプラインのスクリーンショット。ステージ列で [+] 記号をクリックすると、ステージパネルが表示され、ステージアクションを実行できます。

ステージパネルのスクリーンショット。

ユーザーエクスペリエンスの向上を確認します

チェックログの読み取りを容易にしています。チェックログは、デプロイの成功に不可欠な情報を提供します。作業項目のチケットを閉じるのを忘れた場合や、ServiceNow でチケットを更新する必要があるかどうかが通知されます。以前は、このような重要な情報を提供チェックを知ることは困難でした。

次に、パイプライン実行の詳細ページに最新のチェックログが表示されます。これは、推奨される使用方法に従ったチェックに対してのみ行われます。

最新のチェックログを示す画像。誤って承認されないようにするために、Azure DevOps には、パイプライン実行の詳細ページの [承認とチェック] サイドパネルに [承認者への指示] が表示されます。

パイプラインレビューイメージを待機しています。

チェックを無効にする

デバッグチェックの手間を軽減しました。場合によっては、Azure 関数の呼び出しまたは REST API の呼び出しチェックが正しく機能せず、修正する必要があります。以前は、このようなチェックを削除して、誤ってデプロイをブロックしないようにする必要がありました。チェックを修正したら、それを再度追加して正しく構成し、必要なすべてのヘッダーが設定されているか、クエリパラメーターが正しいことを確認する必要がありました。これは面倒です。

これで、チェックを無効にすることができます。無効になっているチェックは、後続のチェックスイート評価では実行されません。

チェックイメージを無効にします。誤ったチェックを修正したら、それを有効にすることができます。

チェックイメージを有効にします。

Pipelines Runs Rest API で使用されるリソースとテンプレートパラメーター

拡張 Pipelines Runs REST API は、パイプライン実行で使用されるより多くの種類の成果物と、その実行をトリガーするために使用されるパラメーターを返すようになりました。パイプラインの実行で使用されるとのリソースとテンプレートパラメーターを返すように containerpipeline API を拡張しました。たとえば、パイプラインで使用されるリポジトリ、コンテナー、およびその他のパイプラインの実行を評価するコンプライアンスチェックを記述できるようになりました。

新しい応答本文の例を次に示します。

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

YAML エディターでの一般提供テンプレートのサポート

テンプレートは YAML パイプラインで一般的に使用される機能です。これらは、パイプラインスニペットを簡単に共有する方法です。また、パイプラインを通じてセキュリティとガバナンスを検証または適用するための強力なメカニズムでもあります。

Azure Pipelines では YAML エディターがサポートされています。これは、パイプラインを編集するときに役立ちます。しかし、エディターは今までテンプレートをサポートしていませんでした。テンプレートを使用する場合、YAML パイプラインの作成者は IntelliSense を通じて支援を受けることができませんでした。テンプレート作成者は YAML エディターを使用できませんでした。このリリースでは、YAML エディターでテンプレートのサポートを追加しています。

メインの Azure Pipelines YAML ファイルの編集時には、テンプレートを含める、または拡張することができます。テンプレートの名前を入力すると、テンプレートを検証するように求められます。検証されると、YAML エディターは、入力パラメーターを含むテンプレートのスキーマを理解します。

Pipelines REST API 更新

検証後、テンプレートに移動することを選択できます。 YAML エディターのすべての機能を使用して、テンプレートを変更できます。

既知の制限事項があります。

テンプレートに、メイン YAML ファイルの入力として指定されていない必須パラメーターがある場合、検証は失敗し、それらの入力を指定するように求められます。理想的なエクスペリエンスでは、検証をブロックしないでください。また、intellisense を使用して入力パラメーターを入力できる必要があります。
エディターから新しいテンプレートを作成することはできません。既存のテンプレートの使用または編集のみ可能です。

新しい定義済みシステム変数

という名前 Build.DefinitionFolderPathの新しい定義済みシステム変数が導入されました。その値はビルドパイプライン定義のフォルダーパスです。変数は、YAML とクラシックビルドパイプラインの両方で使用できます。

たとえば、パイプラインが Azure Pipelines のフォルダーの下 FabrikamFiber\Chat に格納されている場合、の Build.DefinitionFolderPath 値はです FabrikamFiber\Chat。

YAML テンプレート式で文字列分割関数のサポートを追加する

YAML パイプラインを使用すると、オブジェクトのリストまたはプロパティの値を each ループ処理するなど、コードの重複を減らす便利な方法が提供されます。

反復処理する項目のセットが文字列として表される場合があります。たとえば、デプロイする環境の一覧が文字列 integration1, integration2で定義されている場合です。

Developer Communityからのフィードバックを聞くと、YAML テンプレート式に文字列split関数が必要と聞きました。

これで、文字列を作成し、その部分文字列を反復処理eachできるようになりましたsplit。

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

リポジトリリソース定義のテンプレート式

YAML パイプラインでリソースのプロパティを定義するときに ref 、 repository テンプレート式のサポートが追加されました。これは、Developer Communityによって高く要求された機能でした。

パイプラインで同じリポジトリリソースのさまざまなブランチをチェックするユースケースが存在します。

たとえば、独自のリポジトリを構築するパイプラインがあるとします。そのためには、リソースリポジトリからライブラリをチェックする必要があります。さらに、パイプラインで、それ自体が使用しているのと同じライブラリブランチをチェックしたいとします。たとえば、パイプラインがブランチでmain実行されている場合は、ライブラリリポジトリのブランチをmainチェックする必要があります。パイプラインがブランチでdev実行されている場合は、ライブラリブランチをチェックするdev必要があります。

今日まで、ブランチを明示的に指定してチェックし、ブランチが変更されるたびにパイプラインコードを変更する必要がありました。

これで、テンプレート式を使用して、リポジトリリソースのブランチを選択できるようになりました。パイプラインのメイン以外のブランチに使用する YAML コードの次の例を参照してください。

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

パイプラインを実行するときに、リポジトリに対してチェックするブランチをlibrary指定できます。

ビルドキュー時に拡張するテンプレートのバージョンを指定する

テンプレートは、コードの重複を減らし、パイプラインのセキュリティを向上させる優れた方法を表します。

一般的なユースケースの 1 つは、独自のリポジトリにテンプレートを格納することです。これにより、テンプレートとそれを拡張するパイプライン間の結合が減り、テンプレートとパイプラインを個別に簡単に進化させることができます。

次の例では、ステップの一覧の実行を監視するためにテンプレートを使用します。テンプレートコードはリポジトリにあります Templates 。

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

リポジトリ FabrikamFiberにあるこのテンプレートを拡張する YAML パイプラインがあるとします。今日まで、リポジトリをテンプレートソースとして使用する場合、templatesリポジトリリソースのプロパティを動的に指定refすることはできませんでした。つまり、パイプラインを実行したブランチに関係なく、パイプラインのコードを変更する必要がありました。別のブランチからテンプレートを拡張すると、パイプラインと同じブランチ名からテンプレートが拡張されます。

リポジトリリソース定義でのテンプレート式の導入により、パイプラインを次のように記述できます。

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

これにより、パイプラインは、パイプラインが実行されるブランチと同じブランチでテンプレートを拡張するため、パイプラインとテンプレートのブランチが常に一致することを確認できます。つまり、ブランチでパイプラインを実行すると、リポジトリのブランチdev内のファイルでtemplate.ymldev指定されたテンプレートがtemplates拡張されます。

または、次の YAML コードを記述することで、ビルドキュー時に、使用するテンプレートリポジトリブランチを選択することもできます。

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

これで、パイプラインのコードを変更せずに、ブランチ main 上のパイプラインで 1 回の実行でブランチ dev からテンプレートを拡張し、別の実行でブランチ main からテンプレートを拡張できるようになりました。

リポジトリリソースのプロパティにテンプレート式を ref 指定する場合は、とシステムの定義済み変数を使用 parameters できますが、YAML または Pipelines UI で定義された変数は使用できません。

コンテナーリソース定義のテンプレート式

YAML パイプラインでリソースの、、、および options プロパティをendpoint定義するときに、テンプレート式のcontainerサポートが追加portsvolumesされました。これは、Developer Communityによって高く要求された機能でした。

これで、次のような YAML パイプラインを記述できます。

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

テンプレート式では、と variables. を使用parameters.できます。変数の場合、YAML ファイルで定義されているもののみを使用できますが、Pipelines UI で定義されているものは使用できません。たとえば、エージェントログコマンドを使用して変数を再定義した場合、影響はありません。

スケジュールされたビルドの機能強化

パイプラインのスケジュール情報が破損し、パイプラインが読み込まれなくなる問題を修正しました。これは、たとえば、ブランチの名前が特定の文字数を超えた場合に発生しました。

パイプラインの読み込みに失敗したときのエラーメッセージが改善されました

Azure Pipelines には、パイプラインの開始方法を構成するために、いくつかの種類のトリガーが用意されています。パイプラインを実行する方法の 1 つは、スケジュールされたトリガーを使用することです。パイプラインのスケジュールされた実行情報が破損し、読み込みが失敗することがあります。以前は、パイプラインが見つからないという誤解を招くエラーメッセージが表示されていました。この更新プログラムでは、この問題を解決し、有益なエラーメッセージを返しています。今後、次のようなメッセージが表示されます。パイプラインの読み込みに失敗すると、 ビルドスケジュールデータが破損します 。

Git リポジトリをフェッチするときにタグを同期しない

チェックアウトタスクでは、Git リポジトリの内容をフェッチする際にオプションが使用--tagsされます。これにより、サーバーはすべてのタグと、それらのタグが指すすべてのオブジェクトをフェッチします。これにより、パイプラインでタスクを実行する時間が長くなります。特に、多数のタグを持つ大規模なリポジトリがある場合です。さらに、シャローフェッチオプションを有効にした場合でも、チェックアウトタスクはタグを同期するため、その目的を打ち負かす可能性があります。 Git リポジトリからフェッチまたはプルされるデータの量を減らすために、タグの同期動作を制御するための新しいオプションがタスクに追加されました。このオプションは、クラシックパイプラインと YAML パイプラインの両方で使用できます。

YAML
クラシック

この動作は、YAML ファイルまたは UI から制御できます。

YAML ファイルを介したタグの同期をオプトアウトするには、チェックアウトステップにを fetchTags: false 追加します。オプションが fetchTags 指定されていない場合は、が使用されている場合 fetchTags: true と同じです。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

既存の YAML パイプラインの動作を変更する場合は、YAML ファイルを更新するのではなく、UI でこのオプションを設定する方が便利な場合があります。 UI に移動するには、パイプラインの YAML エディターを開き、[トリガー]、[プロセス]、[チェックアウト] の順に選択します。

この設定を YAML ファイルと UI の両方で指定すると、YAML ファイルで指定された値が優先されます。

作成したすべての新しいパイプライン (YAML またはクラシック) では、タグは既定で同期されます。このオプションでは、既存のパイプラインの動作は変更されません。上記のようにオプションを明示的に変更しない限り、これらのパイプラインでタグは同期されます。

Artifacts

既定のフィードのアクセス許可を更新しました

Project Collection Build Service アカウントには、現在の 共同作成者 ロールではなく、新しいプロジェクトコレクションスコープの Azure Artifacts フィードが作成されるときに、既定で コラボレーター ロールが割り当てられます。

アップストリームパッケージ検索用の新しいユーザーインターフェイス

以前は、フィードのコピーがある場合は、アップストリームパッケージが表示されていました。問題点は、アップストリームで使用可能で、まだフィードに保存されていないパッケージを検索できないことでした。新しいフィードユーザーインターフェイスを使用して、使用可能なアップストリームパッケージを検索できるようになりました。

Azure Artifacts には、アップストリームソース内のパッケージを検索し、パッケージのバージョンをフィードに保存できるユーザーインターフェイスが用意されました。これは、Microsoft の製品とサービスを改善するという Microsoft の目標に沿っています。

レポート

クエリ結果ウィジェットで、親の名前とその親への直接リンクがサポートされるようになりました。

Marketplace にデプロイするための個人用アクセストークンを作成する

ダッシュボードのコピー

このリリースでは、コピーダッシュボードが含まれています。

ダッシュボードの最終アクセス日と変更者

チームが複数のダッシュボードを作成できるようにする課題の 1 つは、古いダッシュボードと未使用の管理とクリーンアップです。ダッシュボードが最後にアクセスまたは変更された日時を把握することは、削除できるダッシュボードを理解するための重要な部分です。このリリースでは、Dashboards ディレクトリページに 2 つの新しい列が含まれています。 [最終アクセス日] は、ダッシュボードが最後にアクセスされた日時を追跡します。 [変更者] は、ダッシュボードが最後に編集されたときと、誰が編集したかを追跡します。

[変更者] 情報は、ダッシュボードページ自体にも表示されます。

これらの新しいフィールドが、プロジェクト管理者がダッシュボードのアクティビティレベルを理解し、削除する必要があるかどうかを判断するのに役立つことを願っています。

分析ビューが利用可能になりました

Analytics ビュー機能は、ホストされている製品のバージョンで長期間プレビュー状態になっています。このリリースでは、この機能がすべてのプロジェクトコレクションで使用できるようになったことをお知らせします。

ナビゲーションで、 Analytics ビューが [ 概要 ] タブから [ ボード ] タブに移動しました。

分析ビューでは、Analytics データに基づいて Power BI レポートのフィルター条件を簡単に指定できます。 Analytics ビューに慣れていない場合は、次のドキュメントを参照してください。

複数のリポジトリの Pull Request ウィジェットが 2022.1 Azure DevOps Server利用可能であることをお知らせします。この新しいウィジェットを使用すると、1 つの合理化されたリストで最大 10 個の異なるリポジトリからの pull request を簡単に表示できるため、pull request を常に把握しやすくなります。

コミュニティ提案チケット

バーンダウンチャートとバーンアップチャートで完了として解決済みのご紹介

グラフで完了した解決済みアイテムを含め、チームの進捗状況を正確に反映することの重要性を理解しています。簡単なトグルオプションを使用すると、解決済みのアイテムを完了済みとして表示し、チームのバーンダウン状態を真に反映できます。この機能強化により、より正確な追跡と計画が可能になり、チームは実際の進捗状況に基づいて情報に基づいて意思決定を行うことができます。 Reporting で更新されたバーンダウングラフとバーンアップチャートを使用して、透明性の向上と分析情報の向上を体験してください。

デモする GIF は、バーンダウンチャートとバーンアップチャートで完了として解決しました。

Wiki

Wiki ページでの追加のダイアグラムの種類のサポート

Wiki ページで使用される人魚チャートのバージョンを 8.13.9 にアップグレードしました。このアップグレードにより、Azure DevOps Wiki ページに次の図と視覚化を含めることができるようになりました。

フローチャート
シーケンス図
ガントチャート
円グラフ
要件図
状態図
ユーザー体験

Entity Relationship や Git Graph などの実験モードの図は含まれません。新機能の詳細については、マーメイドのリリースノートを参照してください。

フィードバック

皆様のご意見をお待ちしております。問題を報告したり、アイデアを提供したり、Developer Communityを通じて追跡したり、Stack Overflow に関するアドバイスを得ることができます。

ページの先頭へ

Azure DevOps Server 2022 Update 1 リリース ノート

Azure DevOps Server 2022 Update 1 Patch 3 リリース日: 2024 年 3 月 12 日

Azure DevOps Server 2022 Update 1 Patch 2 リリース日: 2024 年 2 月 13 日

Azure DevOps Server 2022 Update 1 Patch 1 リリース日: 2023 年 12 月 12 日

Azure DevOps Server 2022 Update 1 リリース日: 2023 年 11 月 28 日

Azure DevOps Server 2022 Update 1 RC2 リリース日: 2023 年 10 月 31 日

Azure DevOps Server 2022 Update 1 RC1 リリース日: 2023 年 9 月 19 日

全般

すべてのパブリック REST API で詳細な PAT スコープがサポートされます

拡張機能にはスコープが表示されます

Boards

[配信プラン] ページの [最終アクセス] 列

配信プランに対するすべての依存関係を視覚化する

新しい作業項目リビジョンの制限

配信計画チームの制限を 15 から 20 に引き上げる

Reporting Work Item Links Get API のバグを修正しました

一時的なクエリ REST エンドポイントを作成する

バッチ削除 API

@CurrentIteration 配信プランのマクロ

配信プランのカードサイズ変更ロジック

バッチ更新の機能強化

バッチ削除 API

共有可能な候補リスト フィールドの編集を禁止する

新しいコメントの保存アクセス許可

対話型ボード レポート

Repos

ブランチ作成者に対する "ポリシーの編集" アクセス許可の削除

Pipelines

クラシック パイプラインでのビルド アクセス トークンの既定のスコープとして設定されている現在のプロジェクト

クラシック ビルド パイプラインでのアクセス トークンの既定のスコープの変更

ServiceNow の San Diego、Tokyo & ユタ州のリリースに対する Azure Pipelines のサポート

GitHub Enterprise 統合にプロキシ URL を使用する

Container Registry サービス接続で Azure マネージド ID を使用できるようになりました

Kubernetes Service Connection 用に作成された自動トークン

Kubernetes タスクで kubelogin がサポートされるようになりました

パイプラインのアクセス許可の改善を体験する

パイプラインの承認と承認とチェックを管理するための新しい PAT スコープ

保護されたリソースをリソース管理者に対して開く制限

パイプライン REST API セキュリティの強化

エージェント プールのきめ細かいアクセス管理

すべてのパイプラインに保護されたリソースへのアクセスを許可しないようにする

短いシークレットのマスクを無効にする機能

ノード ランナーのダウンロード タスク

TFX ノード ランナーの検証が更新されました

パイプライン エージェントに Node 6 を手動でプレインストールする手順

パイプライン タスクの変更ログ

リリース タスクで Microsoft Graph APIを使用する

タスクのパフォーマンス向上Windows PowerShell

.NET 6 上のパイプライン エージェント v3

エージェント VM 拡張機能でエージェントのバージョンを指定する

クラシック パイプラインの作成を制御するための新しいトグル

"ステージの状態が変更されました" サービス フック イベントの実行に更新

パイプライン実行の最後のコミット メッセージの表示を無効にする

Azure Resource Manager (ARM) テンプレートの最大サイズ 4 MB に合わせて Azure Pipeline の制限を引き上げた。

パイプラインの実行状態の概要アイコン

パイプライン ステージのサイド パネル

サイド パネルでステージを検索する

クイック アクションをステージする

ユーザー エクスペリエンスの向上を確認します

チェックを無効にする

Pipelines Runs Rest API で使用されるリソースとテンプレート パラメーター

YAML エディターでの一般提供テンプレートのサポート

新しい定義済みシステム変数

YAML テンプレート式で文字列分割関数のサポートを追加する

リポジトリ リソース定義のテンプレート式

ビルド キュー時に拡張するテンプレートのバージョンを指定する

コンテナー リソース定義のテンプレート式

スケジュールされたビルドの機能強化

パイプラインの読み込みに失敗したときのエラー メッセージが改善されました

Git リポジトリをフェッチするときにタグを同期しない

Artifacts

既定のフィードのアクセス許可を更新しました

アップストリーム パッケージ検索用の新しいユーザー インターフェイス

レポート

クエリ結果ウィジェットに親を表示する

ダッシュボードのコピー

ダッシュボードの最終アクセス日と変更者

分析ビューが利用可能になりました

複数のリポジトリの Pull Request ウィジェットが利用可能になりました

バーンダウンチャートとバーンアップチャートで完了として解決済みのご紹介

Azure DevOps Server 2022 Update 1 リリースノート

共有可能な候補リストフィールドの編集を禁止する

対話型ボードレポート

クラシックパイプラインでのビルドアクセストークンの既定のスコープとして設定されている現在のプロジェクト

クラシックビルドパイプラインでのアクセストークンの既定のスコープの変更

エージェントプールのきめ細かいアクセス管理

ノードランナーのダウンロードタスク

TFX ノードランナーの検証が更新されました

パイプラインエージェントに Node 6 を手動でプレインストールする手順

パイプラインタスクの変更ログ

リリースタスクで Microsoft Graph APIを使用する

.NET 6 上のパイプラインエージェント v3

クラシックパイプラインの作成を制御するための新しいトグル

"ステージの状態が変更されました" サービスフックイベントの実行に更新

パイプライン実行の最後のコミットメッセージの表示を無効にする

パイプラインステージのサイドパネル

サイドパネルでステージを検索する

クイックアクションをステージする

ユーザーエクスペリエンスの向上を確認します

Pipelines Runs Rest API で使用されるリソースとテンプレートパラメーター

リポジトリリソース定義のテンプレート式

ビルドキュー時に拡張するテンプレートのバージョンを指定する

コンテナーリソース定義のテンプレート式

パイプラインの読み込みに失敗したときのエラーメッセージが改善されました

アップストリームパッケージ検索用の新しいユーザーインターフェイス