Azure Pipelines - Sprint 192 Update

  • [アーティクル]

機能

新しい YAML 条件式

YAML ファイルに条件式を記述する方が、式と${{ elseif }}使用${{ else }}が簡単になりました。 YAML パイプライン ファイルでこれらの式を使用する方法の例を次に示します。

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux') }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

パス フィルターでのワイルドカードのサポート

パイプライン YAML ファイルで CI トリガーまたは PR トリガーの包含ブランチと除外ブランチを指定するときに、ワイルド カードを使用できます。 ただし、パス フィルターを指定するときに使用することはできません。 たとえば、一致 src/app/**/myapp*するすべてのパスを含めることはできません。 これは、複数の顧客によって不便として指摘されています。 この更新プログラムは、このギャップを埋めます。 パス フィルターを指定するときに、野生のカード文字 (**、*または?) を使用できるようになりました。

Bitbucket での複数の状態のサポート

Azure Pipelines は Bitbucket リポジトリと統合され、CI トリガーと PR トリガーをサポートします。 1 つの Bitbucket リポジトリから複数のパイプラインを設定できます。 ただし、これらのパイプラインが完了すると、Bitbucket には 1 つの状態しか表示されませんでした。 開発者コミュニティから、Bitbucket で各パイプラインの状態を個別に表示するよう求めるフィードバックが寄せられます。 この更新プログラムでは、Bitbucket への API 呼び出しを更新し、パイプラインの名前に関する追加情報を渡しました。

Build status

ビルド検証の前に、共同作成者が PR コメントの検索をスキップできるようにする

GitHub リポジトリで Azure Pipelines を使用する場合は、フォークされたリポジトリから受信したコントリビューションの PR 検証パイプラインを自動的に実行しないことをお勧めします。 ここでのベスト プラクティスは、最初にリポジトリのコラボレーターの 1 人が変更を確認してから、PR にコメントを追加してパイプラインをトリガーすることです。 これらの設定を構成するには、パイプライン Web エディターで [トリガー] メニュー (YAML パイプラインの場合) または [トリガー] タブ (クラシック ビルド パイプラインの場合) を選択します。 フォークのすべての PR をチーム メンバーが最初にレビューするように要求する代わりに、このポリシーを適用できるのは、チーム メンバー以外のメンバーからのコントリビューションに対してのみ行うこともできます。

この更新プログラムでは、任意の共同作成者が受け取ったコントリビューションからの PR コメントの検索をスキップできます。 チームメンバー以外のメンバーは、フォークを作成してアップストリームに PR を作成する場合、PR がマージされるまでアップストリーム リポジトリへの共同作成者とは見なされません。 PR がマージされると、共同作成者と見なされます。 次に示す新しいオプションを選択すると、チーム以外のメンバーが初めてフォークから PR を送信するときに、チームの誰かが PR を確認し、コメントを追加してパイプラインをトリガーする必要があります。 ただし、PR がマージされると、そのチーム以外のメンバーによって行われたそれ以上のコントリビューションは、PR コメントを待たずにパイプラインを直接トリガーします。

Require a team member's comment before building a pull request

Windows Server 2022 with Visual Studio 2022 が Microsoft ホステッド エージェントで利用可能に (プレビュー)

Windows Server 2022 および Visual Studio Enterprise 2022 Preview は、Microsoft がホストするエージェントでプレビューで利用できるようになりました。 これを使用するには、パイプラインでイメージとして参照 windows-2022 します。

pool:
  vmImage: 'windows-2022'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '**/*.sln'
- task: VSBuild@1 # Visual Studio 2022 build
  inputs:
    solution: '**/*.sln'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: 'Any CPU'
    configuration: 'Release'

YAML パイプラインで Windows 最新のプールを参照する場合でも、windows-2022 ではなく windows-2019 を意味し、後者はプレビュー段階です。

Windows Server 2022 パイプライン イメージには、Windows Server 2019 と比較して、ツールとツールのバージョンが異なります。 詳細については、ソフトウェアのお知らせの問題と、仮想環境リポジトリのドキュメントを参照してください。

Microsoft がホストするエージェントでの macOS 11 の一般提供

macOS 11 は、Microsoft がホストするエージェントで一般提供されるようになりました。 これを使用するには、パイプラインでイメージとして参照 macos-11 します。

pool:
  vmImage: macos-11

macOS 11 パイプライン イメージにはさまざまなツールとツールがあり、このバージョンの詳細については、こちらの完全なドキュメントを参照してください。

Microsoft でホストされているエージェントでの Ubuntu 16.04 イメージの削除

前に発表したように、2021 年 9 月 20 日に Microsoft がホストするエージェントから Ubuntu 16.04 イメージを削除します。 Canonical による Ubuntu 16.04 の従来の 5 年間のサポートは、2021 年 4 月に終了しました。 Ubuntu-16.04 パイプラインを ubuntu-18.04 または ubuntu-latest に移行する必要があります。Ubuntu 20.04 LTS で実行されます。

Ubuntu-16.04 を使用するビルドには、既に警告がログに記録されています。 誰もがこの変更を認識していることを確認するために、2 つの短い "ブラウンアウト" をスケジュールしました。 Ubuntu 16.04 ビルドは、ブラウンアウト期間中に失敗します。 そのため、2021 年 9 月 6 日より前にワークフローを移行することをお勧めします。

ブラウンアウトは、次の日時にスケジュールされています (以前に発表された時刻から 1 時間延長されていることに注意してください)。 2021 年 9 月 6 日午後 4 時 (UTC) - 午後 10:00 UTC (2021 年 9 月 14 日午後 4:00 UTC – 午後 10:00 UTC)

次のステップ

Note

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

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

Azure DevOps に移動する

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

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

Make a suggestion

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