次の方法で共有

GitHub 統合 - AB# 検証の改善

  • [アーティクル]

この更新プログラムにより、Azure Boards と GitHub の統合における最新の機能強化のプライベート プレビューが提供されます。

さらに、管理者が実行中の承認をバイパスし、Azure Pipelines で修正プログラムを完了することを確認できるようになりました。

詳細については、リリース ノートを参照してください。

全般

Azure Boards

Azure Pipelines

レポート

全般

Azure DevOps Web 拡張機能 SDK の新しいバージョン

この更新プログラムでは、Azure DevOps Web Extension SDK の新しいバージョンがリリースされます。 クライアント SDK を使用すると、Web 拡張機能がホスト フレームと通信できるようになります。 次の用途に使用できます。

  • 拡張機能が読み込まれているか、エラーが発生したことをホストに通知する
  • 現在のページに関する基本的なコンテキスト情報 (現在のユーザー、ホスト、拡張機能の情報) を取得する
  • テーマ情報を取得する
  • AZURE DevOps への REST 呼び出しで使用する承認トークンを取得する
  • ホスト フレームによって提供されるリモート サービスを取得する

完全な API リファレンスについては、 azure-devops-extension-sdk パッケージドキュメントを参照してください。 この新しいバージョンでは、次のモジュールがサポートされます。

  • ES モジュールのサポート: SDK では、既存の AMD (非同期モジュール定義) モジュールに加えて、ES (ECMAScript) モジュールもサポートされるようになりました。 ES モジュール構文を使用して SDK をインポートできるようになりました。これにより、パフォーマンスが向上し、アプリケーション のサイズが小さくなります。

  • AMD モジュールの下位互換性: AMD モジュールの既存のサポートはそのまま残ります。 プロジェクトで AMD モジュールを使用している場合は、変更を加えずに、以前と同様に引き続き使用できます。

使用方法:

ES モジュールの場合は、import ステートメントを使用してモジュールをインポートできます。

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

AMD モジュールを使用している場合は、 require 関数を使用して引き続き SDK をインポートできます。

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

Azure Boards

GitHub 統合 - AB# 検証の改善 (プライベート プレビュー)

重要

2024 年 8 月 6 日の時点で、GitHub の Azure Boards アプリでは AB# リンクが検証されなくなります。 この変更前と同様に、 AB# 構文を使用して GitHub の pull request、commit、および問題の作業項目をリンクできます。

AB# 構文を使用して作業項目にリンクするときのボットの応答に対処することで、Boards + GitHub 統合の改善の取り組みを開始します。 AB#{ID}構文を使用してプル要求にリンクする場合、リンクが成功したかどうかを確認する唯一の方法は、作業項目を確認するか、AB#{ID}がリンクに変わったことを認識することです。

現在、作業項目へのリンクが有効または無効であることを通知するために、Azure Boards GitHub アプリのいくつかの機能強化を備えたプライベート プレビューが開始されます。 これにより、無効なリンクを特定し、プル要求がマージされる前に修正できます。

チーム設定のスクリーンショット。

プライベート プレビューへの参加に関心がある場合は、メール 直接お問い合わせください。 組織名 (dev.azure.com/{organization}) を必ず含める

今後の Azure Boards + GitHub 統合機能の詳細については、パブリック ロードマップを参照してください。

Azure Pipelines

Azure Pipelines タスクで Node 16 を使用する

パイプライン内のタスクはランナーを使用して実行され、ほとんどの場合Node.js使用されます。 ノードをランナーとして使用する Azure Pipelines タスクでは、すべて Node 16 が使用されるようになりました。 Node 16 は Apple シリコンをネイティブにサポートする最初の Node バージョンであるため、Apple シリコンでの macOS の完全なタスク サポートも完了します。 Apple シリコンで実行されているエージェントは、Rosetta を実行する必要はありません。

ノード 16 の有効期間の終了日が 進んだのでノード 20 でタスクを実行する作業を開始しました。

非推奨のタスクの廃止の発表

Azure Pipelines には、非推奨のタスクが多数あります。 非推奨のタスクは、2024 年 1 月 31 日に廃止されます。 非推奨のタスクを使用しているパイプラインを特定するために、そのようなタスクが使用されている場合、パイプラインに警告が表示されます。 非推奨の状態と提供終了日を明確に伝えるために、 Task リファレンス を更新しました。

次のタスクは非推奨となり、警告の出力が開始されます。

  • AppCenterDistributeV1,
  • AppCenterDistributeV2
  • AzureMonitorV0
  • ChefKnifeV1
  • ChefV1
  • CondaEnvironmentV1
  • DeployVisualStudioTestAgentV2
  • DotNetCoreInstallerV1
  • IISWebAppDeployment
  • QuickPerfTestV1
  • RunJMeterLoadTestV1
  • RunLoadTestV1
  • SqlServerDacpacDeploymentV1
  • XamarinTestCloudV1

2024 年 1 月 31 日より前に、新しいタスク バージョンまたは代替バージョンを使用するようにパイプラインを更新します。

AzureRmWebAppDeployment タスクでは、Microsoft Entra ID 認証がサポートされます

AzureRmWebAppDeploymentV3 と AzureRmWebAppDeployment@4 タスクが更新され、 基本認証が無効になっている App Service がサポートされました。 App Service で基本認証が無効になっている場合、AzureRmWebAppDeploymentV3/4 タスクは Microsoft Entra ID 認証を使用して App Service Kudu エンドポイントへのデプロイを実行します。 これには、最新バージョンのmsdeploy.exeがエージェントにインストールされている必要があります。windows-2022/windows-latest Hosted エージェントの場合 ( task リファレンスを参照)。

承認 REST API の機能強化

ユーザーが属しているグループを検索結果に含めることで、ユーザーに割り当てられた承認の検索が改善されました。

承認には、所属するパイプライン実行に関する情報が含まれるようになりました。

たとえば、次の GET REST API 呼び出し https://dev.azure.com/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending 返されます。

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

承認とチェックをバイパスする

承認とチェック サービス接続、リポジトリ、エージェント プールなどの重要なリソースへのアクセスを保護するのに役立ちます。 一般的なユース ケースは、運用環境にデプロイするときに承認とチェックを使用し、ARM サービス接続を保護することです。

たとえば、サービス接続に次のチェックを追加したとします。承認、営業時間チェック、および Azure 関数の呼び出しチェック (異なるリージョン間で遅延を強制するため)。

ここで、修正プログラムの展開を行う必要があるとします。 パイプラインの実行を開始しますが、続行されません。ほとんどのチェックが完了するまで待機します。 承認とチェックが完了するまで待つことはできません。

このスプリントでは、修正プログラムを完了できるように、実行中の承認とチェックをバイパスできるようになりました。

実行中の承認、営業時間、Azure 関数の呼び出し、REST API チェックの呼び出しをバイパスできます。

承認をバイパスします。

[承認をバイパスする] のスクリーンショット。

営業時間チェックをバイパスします。

[営業時間のバイパス] チェックのスクリーンショット。

Azure 関数の呼び出しチェックをバイパスします。 営業時間チェックをバイパスします。

[Azure 関数の呼び出しのバイパス] チェックのスクリーンショット。

チェックがバイパスされると、チェック パネルで確認できます。

バイパスされたチェックのスクリーンショット。

チェックをバイパスできるのは、チェックが定義されたリソースの管理者である場合のみです。

必要なテンプレート チェックでの GitHub エンタープライズ サーバーのサポート

テンプレート は、組織内のパイプラインのステージ、ジョブ、およびステップを制御できるセキュリティ メカニズムです。

Require テンプレート チェックを使用すると、エージェント プールやサービス接続などの保護されたリソースにアクセスする前に、一連の承認済みテンプレートからパイプラインを拡張するように強制できます。

このスプリント以降、GitHub Enterprise Server リポジトリにあるテンプレートを指定できます。

必要な YAML テンプレートのスクリーンショット。

Azure 関数チェックの呼び出しを再実行する

システムを複数のステージでデプロイするとします。 2 番目のステージをデプロイする前に、システムの既にデプロイされている部分に対してサニティ チェックを実行する承認と Azure 関数の呼び出しチェックがあります。

承認要求を確認すると、サニティ チェックが 2 日前に実行されたことがわかります。 このシナリオでは、サニティ チェックの結果に影響を与えた別のデプロイを認識している可能性があります。

この更新プログラムでは、Azure 関数の呼び出しと REST API の呼び出しチェックを再実行できます。 この機能は、成功し、再試行がないチェックでのみ使用できます。

動的チェックのスクリーンショット。

Note

チェックを再実行できるのは、チェックが定義されたリソースの管理者である場合のみです。

レポート

作業項目のフィルター処理

作業項目グラフのフィルター処理 お知らせします。 この機能を使用すると、作業項目グラフの上にマウス ポインターを合わせて簡単な概要を確認し、特定のグラフ セグメントにドリルダウンして詳細な分析情報を得ることができます。 必要なデータの正確な部分にアクセスするためにカスタム クエリを作成する必要がなくなりました。 作業項目グラフの作業項目を数回クリックするだけで調べることができるようになりました。

Gif を使用して作業項目のフィルター処理をデモします。

この機能の将来を形成する上で、フィードバックは非常に貴重です。 今すぐお試しください。 Azure DevOps コミュニティで何を考え。

次のステップ

Note

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

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

Azure DevOps に移動する

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

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

スクリーンショット: 提案を行います。

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

シルヴィウ アンドリカ