次の方法で共有

Azure Pipelines - Sprint 230 Update

  • [アーティクル]

機能

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 日に廃止されます。 非推奨のタスクを使用しているパイプラインを特定するために、そのようなタスクが使用されている場合、パイプラインに警告が表示されます。 廃止の 状態と提供終了日を明確に伝えるために、タスク参照 を更新しました。

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

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

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

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

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

承認 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 チェックの呼び出しをバイパスできます。

承認をバイパスします。

Screenshot of Bypass an Approval.

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

Screenshot of Bypass Business Hours check.

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

Screenshot of Bypass Invoke Azure Function check.

チェックがバイパスされると、チェックパネルに表示されます。

Screenshot of check bypassed.

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

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

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

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

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

Screenshot of required YAML template.

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

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

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

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

Screenshot of dynamic check.

Note

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

次のステップ

Note

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

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

Azure DevOps に移動する

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

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

Make a suggestion

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