今回のスプリントでは、YAMLパイプラインファイルへのワイルドカードや条件式のサポートを追加しました。また、Azure PipelinesのMicrosoft hostedイメージに対して複数の更新を行いました。
詳細は、以下の機能説明をご覧ください。
- YAMLで新しい条件式をサポートします
- パスフィルターでワイルドカードをサポートします
- Bitbucketで複数のステータスをサポートします
- コントリビューターに対してPRコメントがなくてもビルド検証が起動できるようになりました
- Microsoft-hosted エージェントでWindows Server 2022とVisual Studio 2022をプレビュー提供します
- Microsoft-hostedエージェントでmacOS 11 Big Surの一般提供を開始します
- Ubuntu 16.04イメージをMicrosoft-hostedエージェントから削除します
- 新しいTFVCページを一般提供開始します
- ブランチ作成者が自身の"Manage permissions"権限を取得できないようになりました
- フォークしたユーザーが自分のupstreamのPRへの投票を不可能とできるようになりました
${{ 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: _dbgvariables:
${{ if eq(parameters.os, 'win') }}:
testsFolder: windows
${{ elseif eq(parameters.os, 'linux' }}:
testsFolder: linux
${{ else }}:
testsFolder: macワイルドカードは、パイプラインのYAMLファイルでCIやPRのトリガーにおいて、ブランチを含む、ブランチを除外するという指定が可能になっています。しかし、src/app/**/myapp*というようなパスフィルターは指定できません。これは、何人かのお客様から不便だと指摘されていました。今回のアップデートは、このギャップが埋まります。パスフィルターを指定する際に、ワイルドカード文字(**, *, ?)を使用できるようになりました。
Azure Pipelinesは、Bitbucketリポジトリと統合し、CIとPRのトリガーをサポートしています。1つのBitbucketリポジトリから複数のパイプラインをセットアップできます。しかし、これらのパイプラインが完成すると、Bitbucketでは1つのステータスしか見ることができませんでした。Developer Communityから、各パイプラインのステータスをBitbucketで個別に確認したいという声が寄せられていました。今回のアップデートでは、Bitbucketへパイプラインの名前に関する追加情報を渡すようにAPI呼び出しを変更しました。
Azure PipelinesをGitHubリポジトリで使用する場合、フォークしたリポジトリから受け取ったコントリビューションに対して、自動的にPR検証パイプラインを実行しないことをお勧めします。ここでのベストプラクティスは、まずリポジトリの共同作業者（collaborators）の1人に変更内容を確認してもらい、PRにコメントを追加してパイプラインを起動することです。これらの設定は、パイプラインのWebエディターのTriggersメニュー（YAML パイプラインの場合）またはTriggersタブ（クラシックビルドパイプラインの場合）から設定可能です。フォークからのすべてのPRにチームメンバーによる最初のレビューを要求する代わりに、チームメンバー以外からのコントリビューションにのみこのポリシーを適用することもできます。
今回のアップデートでは、どのコントリビューターから受け取ったコントリビューションでも、PRコメントを求めないことができるようになりました。非チームメンバーとして、フォークを作成してupstreamへのPRを作成しても、そのPRがマージされるまではupstreamのリポジトリへのコントリビューターとはみなされません。あなたのPRがマージされると、あなたはコントリビューターとみなされます。下図の新しいオプションを選択すると、チームメンバーではない人が初めてフォークからPRを提出した場合、チームの誰かがPRをレビューしてコメントを追加し、パイプラインを起動する必要があります。しかし、いったんPRがマージされると、その非チームメンバーがさらに貢献すると、PRのコメントを待たずに直接パイプラインが起動します。
Microsoft HostedエージェントでWindows Server 2022とVisual Studio Enterprise 2022がプレビューとして利用可能になりました。パイプラインでwindows-2022をimageとして指定すると、使用できます。
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-latest poolを参照しても、プレビューである現時点においては、windows-2022ではなく、windows-2019を意味しています。
Windows Server 2022のパイプラインイメージは、Windows Server 2019と比較すると、ツールやツールのバージョンが異なります。詳細は、ソフトウェアの更新をお知らせしたissueやドキュメントのvirtual-environmentsリポジトリで確認できます。
Windows Server 2022を使用した際にパイプラインに問題があった場合は、virtual-environmentsリポジトリにissueを作成してお知らせください。
macOS 11は、Microsoft hostedエージェントで正式版として利用できるようになりました。パイプラインでmacos-11 as imageを参照することで使用できます。
pool:
vmImage: macos-11macOS 11のパイプラインイメージには、異なるツールが用意されています。このバージョンについての詳細は、こちらの完全なドキュメントをご覧ください。
macOS 11を使用した際にパイプラインに問題が発生した場合は、virtual-environmentsリポジトリにissueを作成してお知らせください。
先にお知らせした通り、2021年9月20日にMicrosoft HostedエージェントからUbuntu 16.04のイメージを削除します。また、Canonical社によるUbuntu 16.04の従来の5年間のサポートも2021年4月に終了しています。ubuntu-16.04のパイプラインをUbuntu-18.04またはUbuntu 20.04 LTS上で動作するubuntu-latestに移行する必要があります。
Ubuntu-16.04を使用するビルドには、すでに警告が記録されています。この変更を周知徹底するために、短い「ブラウンアウト」(訳註：意図的にシステムから失敗させること)を2回予定しています。ブラウンアウト期間中、Ubuntu 16.04のビルドは失敗します。そのため、2021年9月6日より前にワークフローを移行することをお勧めします。
ブラウンアウトは、以下の日時に予定されています（なお、これらは先に発表された時間から1時間延長されています）。2021年9月6日 4:00pm UTC - 10:00pm UTC 2021年9月14日 4:00pm UTC - 10:00pm UTC
Azure DevOpsでは、様々なサービスでより一貫した体験を提供し、よりアクセスしやすくすることを目的として、新しいWebプラットフォームを使用するために様々なページを更新してきました。TFVCページも新しいWebプラットフォームを使用するために更新されており、これらの変更は数ヶ月前からプレビュー提供されています。今回のアップデートでは、新しいTFVCページが正式版として公開されます。今回のアップデートにより、ユーザー設定に"New TFVC pages"というプレビュー機能が表示されなくなりました。
新しいブランチを作成すると、そのブランチの"Manage permissions"を取得します。この権限により、他のユーザーの権限を変更したり、そのブランチに貢献するユーザーを追加で許可したりできます。たとえば、ブランチの作成者は、この権限を使って、外部の別のユーザーがコードの変更を許可できます。あるいは、パイプライン（ビルドサービスのID）にそのブランチのコードの変更を許可できます。コンプライアンス要件の高い特定の組織では、ユーザーがこのような変更を行えないようにする必要があります。
今回のアップデートでは、チームプロジェクト内のあらゆるリポジトリを設定し、ブランチ作成者が"Manage permissions"権限を取得できないように制限することができます。これを行うには、project settingsを開き、Repositoriesを選択し、Settings for all repositories or a specific repositoryを選択します。
この設定は、既存の動作を引き継ぐするために、デフォルトではオンになっています。しかし、この新しいセキュリティ機能を利用したい場合は、この設定をオフにできます。
Azure Reposでは、リポジトリに対する"read"権限を持つユーザーは、レポをフォークして、そのフォークに変更を加えられます。自分の変更をpull requestとしてupstreamに提出するには、upstreamに"contribute to pull requests"権限が必要です。しかし、この権限は、upstreamのリポジトリでpull requestに投票できる人も管理しています。そのため、ブランチポリシーの設定次第では、リポジトリへのコントリビューターではないユーザーがpull requestを送信し、マージされてしまうという状況に陥ることがあります。
インナーソースモデルを推進する組織では、フォーク＆コントリビュートが一般的なパターンです。このパターンを確保し、さらに推進するために、pull requestへの投票権を"contribute to pull requests"から"contribute"に変更します。ただし、この変更はすべての組織でデフォルトで行われているわけではありません。この権限を切り替えるには、オプトインして"Strict Vote Mode"という新しいポリシーをリポジトリ上で選択する必要があります。Azure Reposでフォークに依存している場合は、そうすることをお勧めします。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Aaron Hallberg