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

[アーティクル]
06/11/2024

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

Azure DevOps Server デプロイのインストールまたはアップグレードの詳細については、「Azure 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 4 リリース日: 2024 年 6 月 11 日

ファイル	Sha-256 ハッシュ
devops2022.1patch4.exe	3A17B4F973A6FA4DE5D0B30C6C87B3C18C885620C683FA1032EC4F6BDB2DA4FB

次の修正プログラムを含む、Azure DevOps Server 2022 Update 1 用のパッチ 4 がリリースされました。

トルコ語ロケールの名前にトルコ語の "I" が含まれるプロジェクトで検索結果が利用できない Wiki および作業項目の問題を修正しました。

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 日

Note

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

エージェントのバージョンは、Azure DevOps Server 2022.1 にアップグレードし、エージェントプール構成で Update Agent を使用した後は更新されません。現在、この問題を解決するための修正プログラムに取り組んでおり、進捗に応じて開発者コミュニティで更新プログラムを共有します。それまでの間、この問題の回避策については、この開発者コミュニティチケットを参照してください。
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 はワゴンリゾルバートランスポートを使用するように強制されます。詳細については、こちらのドキュメントを参照してください。

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

Note

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 はワゴンリゾルバートランスポートを使用するように強制されます。詳細については、こちらのドキュメントを参照してください。

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

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

Note

このリリースでは、次の問題が修正されました。

アップストリームエントリで表示名の変更が解決されないローカルフィードの問題を修正しました。
[検索] ページでタブをコードから別のタブに切り替えると、予期しないエラーが発生しました。
中国語、日本語、韓国語 (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 のバグを修正しました

Reporting Work Item Links Get API のバグを修正し、リンクの種類に対して正しい remoteUrl 値を 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 のサンディエゴ、東京、ユタ州のバージョンで動作するようにアプリが更新されました。この統合が確実に機能するように、ServiceNow ストアから新しいバージョンのアプリ (4.215.2) にアップグレードします。

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

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

Azure Pipelines は、継続的インテグレーションと PR ビルドを実行するために、オンプレミスの GitHub Enterprise Servers と統合されます。場合によっては、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 レジストリサービス接続

Note

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

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 では、すべてのパイプラインへのリソースへのアクセスを開始するときに、リソースの種類の管理者ロールが必要になりました。

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

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

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

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

Pipelines 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) または Environment (read, manage) 、種類と種類 queue のリソース 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 では、エージェントプールに対してきめ細かいアクセス管理が提供されるようになりました。このエクスペリエンスは、サービス接続のパイプラインアクセス許可を管理するためのエクスペリエンスと似ています。

承認に対する変更のための 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 は、ノードランナーバージョンで検証を実行するように更新されました。ノードランナーガイダンスのブログ投稿を参照してください。

Node 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 コマンドの一部が、より高速に実行されるようになりました。スクリプトにこれらのコマンドの多くがある場合、または実行時間が長い場合は、改善がより重要になります。この更新プログラムでは、progressPreferencePowerShell@2プロパティとAzurePowerShell@5タスクが既定で設定SilentlyContinueされるようになりました。

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

パイプラインエージェントは、.NET 3.1 Core をランタイムとして .NET 6 に使用するようにアップグレードされました。これにより、Apple Silicon と 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 では、クラシックビルドパイプライン、クラシックリリースパイプライン、タスクグループ、デプロイグループの作成を無効にすることで、組織で YAML パイプラインのみを使用できるようになりました。既存のクラシックパイプラインは引き続き実行され、編集することはできますが、新しいパイプラインを作成することはできません。

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

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

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

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

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

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

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

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

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

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

この更新プログラムでは、正確に実行できる新しい YAML プロパティ (名前 appendCommitMessageToRunName) を追加しました。既定では、プロパティは 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 で使用されるリソースとテンプレートパラメーター

拡張パイプライン実行 REST API は、パイプライン実行で使用されるより多くの種類の成果物と、その実行をトリガーするために使用されるパラメーターを返すようになりました。パイプラインの実行で使用されるリソースとpipelineテンプレートパラメーターをcontainer返すように 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によって定義されている場合です。

開発者コミュニティからのフィードバックを聞くと、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 サポートが追加されました。これは、開発者コミュニティから非常に要求された機能でした。

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

たとえば、独自のリポジトリを構築するパイプラインがあるとします。そのためには、リソースリポジトリからライブラリをチェックアウトする必要があります。さらに、パイプラインで、それ自体が使用しているのと同じライブラリブランチをチェックアウトするとします。たとえば、パイプラインがブランチで 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内devのファイルでtemplate.yml指定されたテンプレートが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 パイプラインでリソースの、、、およびプロパティを定義するときにendpoint、テンプレート式のcontainerサポートを追加しました。optionsportsvolumes これは、開発者コミュニティから非常に要求された機能でした。

これで、次のような 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'

テンプレート式を使用parameters.variables.して使用できます。変数の場合、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

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

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

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

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

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

レポート

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

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

ダッシュボードのコピー

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

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

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

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

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

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

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

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

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

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

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

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

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

デモ版の GIF は、バーンダウンおよびバーンアップグラフで完了として解決されました。

Wiki

Wiki ページでの追加の図の種類のサポート

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

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

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

フィードバック

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

ページの先頭へ

次の方法で共有

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

Azure DevOps Server 2022 Update 1 Patch 4 リリース日: 2024 年 6 月 11 日

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 スコープ

保護されたリソースをリソース管理者に開放することを制限する

Pipelines 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

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

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

レポート

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

ダッシュボードのコピー

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

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

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

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

対話型ボードレポート

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

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

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

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

TFX ノードランナーの検証を更新しました

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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