YAML パイプライン ファイルでのワイルドカードと条件式のサポート

このスプリントでは、YAML パイプライン ファイルに対するワイルドカードと条件式のサポートを含めていました。 さらに、Azure Pipelines でホストされるイメージに対して複数の更新を行いました。

詳細については、次の機能の説明をご覧ください。

Azure Pipelines

• 新しい YAML 条件式
• パス フィルターでのワイルドカードのサポート
• Bitbucket での複数の状態のサポート
• ビルド検証の前に、共同作成者が PR コメントの検索をスキップできるようにする
• Windows Server 2022 with Visual Studio 2022 が Microsoft ホステッド エージェントで利用可能に (プレビュー)
• Microsoft がホストするエージェントでの macOS 11 Big Sur の一般提供
• Microsoft でホストされているエージェントでの Ubuntu 16.04 イメージの削除

Azure Repos

• 新しい TFVC ページの一般提供開始
• ブランチ作成者が自分のブランチの「管理アクセス許可」を取得しないように構成する
• フォーク ユーザーが上流 PR に投票できないようにする

Azure Pipelines

新しい YAML 条件式

${{ else }}式と${{ elseif }}式を使用することで、YAML ファイルでの条件式の記述が簡単になりました。 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 つの状態しか表示されませんでした。 Developer Community から、Bitbucket で各パイプラインの状態を個別に表示するように求めるフィードバックが寄せられます。 この更新プログラムでは、Bitbucket への API 呼び出しを更新し、パイプラインの名前に関する追加情報を渡しました。

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

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

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

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

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)

Azure Repos

新しい TFVC ページの一般提供開始

さまざまなサービスでエクスペリエンスの一貫性とアクセシビリティを高めるという目的で、新しい Web プラットフォームを使用するように、Azure DevOps のさまざまなページを更新しています。 新しい Web プラットフォームを使用するように TFVC ページが更新され、それらの変更は数か月間プレビュー段階にあります。 この更新プログラムでは、新しい TFVC ページを一般公開しています。 この更新プログラムでは、ユーザー設定に "新しい TFVC ページ" というプレビュー機能が表示されなくなります。

ブランチ作成者が自分のブランチの「管理アクセス許可」を取得しないように構成する

新しいブランチを作成すると、そのブランチに対する "アクセス許可の管理" が取得されます。 このアクセス許可を使用すると、他のユーザーのアクセス許可を変更したり、そのブランチに投稿する追加のユーザーを許可したりできます。 たとえば、ブランチ作成者は、このアクセス許可を使用して、別の外部ユーザーがコードに変更を加えることを許可できます。 または、パイプライン (ビルド サービス ID) がそのブランチのコードを変更できるようにする場合もあります。 コンプライアンス要件が高い特定の組織では、ユーザーはそのような変更を行うことができません。

この更新プログラムでは、チーム プロジェクト内のすべてのリポジトリを構成し、ブランチ作成者が "アクセス許可の管理" アクセス許可を取得できないように制限できます。 これを行うには、プロジェクト設定に移動し、[リポジトリ] を選択し、すべてのリポジトリまたは特定のリポジトリの [設定] を選択します。

この設定は、既存の動作を模倣するために既定でオンになっています。 ただし、この新しいセキュリティ機能を利用する場合は、オフにすることができます。

フォーク ユーザーが上流 PR に投票できないようにする

Azure Repos では、リポジトリに対する "読み取り" アクセス許可を持つユーザーは、リポジトリをフォークし、フォークを変更できます。 アップストリームに変更を加えた pull request を送信するには、アップストリームに対する "pull requests に貢献する" アクセス許可が必要です。 ただし、このアクセス許可は、アップストリーム リポジトリ内のプル要求に投票できるユーザーも管理します。 その結果、リポジトリの共同作成者ではないユーザーがプル要求を送信し、ブランチ ポリシーの設定方法に応じてマージされる場合があります。

内部ソース モデルを昇格させる組織では、フォークアンド貢献が一般的なパターンです。 このパターンをさらにセキュリティで保護して昇格させるために、pull request に投票するアクセス許可を "pull request に投稿する" から "投稿" に変更しています。 ただし、この変更はすべての組織で既定で行われるわけではありません。 このアクセス許可を切り替えるには、リポジトリでオプトインし、"Strict Vote Mode" という名前の新しいポリシーを選択する必要があります。 Azure Repos のフォークに依存する場合は、これを行うことをお勧めします。

次のステップ

Note

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

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

Azure DevOps に移動する

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

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

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

よろしくお願いします。

アーロン・ハルベルク