今回のスプリントでは、Azure Pipelinesの排他的ロックチェックの機能を拡張し、シーケンシャルなデプロイメントをサポートしました。1つのenvironmentに対して複数のパイプライン実行をキューに投入すると、そのうちの1つだけが同時に実行されるようになりました。
詳細については、以下の機能説明をご覧ください。
- exclusive lock checks（排他的ロックチェック）使用時に最新モジュールで逐次デプロイを実行するか選択できるようになりました
- ServiceNowのQuebecバージョンのサポートを追加しました
- Microsoftが提供するWindowsとmacOSエージェントで.NET SDKのプリインストールポリシーを変更します。
- PublishBuildArtifactsとDownloadBuildArtifactsタスクからの移行を推奨します
作業項目のdevelopmentセクションには、関連するコミットやpull requestの一覧が表示されます。コミットやpull requestの作者を関連する時間経過と合わせて表示できます。今回の更新では、ビューの中で著者のアバターが正しく表示されない問題を修正しました。
YAML パイプラインでは、保護されたリソース上のステージの実行を制御するためにチェックが使用されます。使用できる一般的なチェックの1つに、排他的ロックチェック(exclusive lock check)があります。このチェックでは、パイプラインからの単一の投入のみを実行します。複数のパイプラインが同時にenvironmentにデプロイしようとすると、このチェックは古い処理をすべてキャンセルし、最新の処理のデプロイのみ許可します。
古い実行をキャンセルするという方針は、リリースが累積的で、以前の実行からのすべてのコード変更が含まれている場合には、良いアプローチです。しかし、コード変更が累積的ではないパイプラインもあります。この新機能では、すべての実行を許可して環境にシーケンシャルデプロイするか、古い投入をキャンセルして最新の投入だけを許可するという従来の動作を維持するかを選択できます。この動作は、パイプラインのYAMLファイルでlockBehaviorという新しいプロパティを指定することで動作します。sequentialを指定した場合は、すべての投入が保護されたリソースへのロックを順次取得することを意味します。runLatestを指定した場合は、最新の投入のみがリソースのロックを取得することを意味します。
デプロイの排他的ロックチェックにsequentialまたはrunLatestを指定するには、以下の手順に従います。
- environment（または別の保護されたリソース）で排他的ロックチェックを有効にします。
- パイプラインの YAML ファイルで、
lockBehaviorという新しいプロパティを指定します。これは、パイプライン全体または特定のstageに対して指定できます。
特定のstageだけに指定するには以下のようにします。
stages:
- stage: A
lockBehavior: sequential
jobs:
- job: Job
steps:
- script: Hey!パイプライン全体に設定するには以下のようにします。
lockBehavior: runLatest
stages:
- stage: A
jobs:
- job: Job
steps:
- script: Hey!lockBehaviorを指定しない場合は、runLatestであるとみなされます。
Azure Pipelinesは、ServiceNowと統合できます。この統合は、ServiceNowのアプリと、Azure DevOpsの拡張機能に依存しています。今回、ServiceNowのQuebecバージョンで動作するようにアプリを更新しました。クラシックパイプラインとYAMLパイプラインどちらもQuebecで動作するようになりました。この統合を確実に使用するためには、Service Nowストアからアプリの新バージョン（4.188.0）にアップグレードしてください。詳細については、ServiceNow変更管理との統合を参照してください。
先日、Microsoftが提供するUbuntuエージェントにおける.NET SDKのプリインストールポリシーの変更を発表しました。今回、Microsoftが提供するWindowsおよびmacOSのエージェントについても同様の変更を行います。
現在、Microsoftが提供するWindowsおよびmacOSエージェントには、利用可能でサポートされているすべてのバージョンの.NET SDK（2.1.x、3.1.x、5.0.x）をインストールしています。この方法は、機能バージョンごとに最新のパッチバージョンをインストールするように変更されます。この変更は、お客様により多くの空き容量を提供するためと、新しいツールのリクエストのために行われます。詳細については、software and image guidelinesをご覧ください。
SDKのバージョンは、x.y.znnというパーツで構成されています。zは機能バージョンで、nnはパッチバージョンです。例えば、2.1.302の場合、機能バージョンは3、02はパッチバージョンです。新しいアプローチでは、機能バージョンごとに最新のパッチバージョンのみをインストールします。つまり、2.1.3xには2.1.302のみ、2.1.4xには2.1.403のみ、といった具合です。最新のパッチバージョンではない.NET SDKのすべてのバージョンは、9月6日にWindowsおよびmacOSのイメージから削除されます。この変更は、マイクロソフトが提供するエージェント上のすべてのバージョンのWindowsおよびmacOSに影響します。
9月6日にアップデートされたイメージの配布を開始し、それから3～4日かかります。
global.jsonファイルを使用している場合、次のような場合にビルドに影響があります。
global.jsonファイルにrollForward: disableプロパティが含まれていて、SDKのバージョンが最新のパッチバージョンでない場合、ビルドに失敗します。例えば、以下のような場合です。
{
"sdk": {
"version": "3.1.100",
"rollForward": "disable"
}
}global.jsonファイルにrollForward: patchプロパティが含まれている場合、.NET SDKのバージョンは自動的に最新のパッチに変更されます。例えば、以下のようになります。
{
"sdk": {
"version": "3.1.100",
"rollForward": "patch"
}
}global.jsonファイルでrollForwardフィールドが指定されていない場合、変更はありません。インストールされている最新のパッチレベルが使用されます。
最新のパッチではない.NET SDKのバージョンを厳密に指定する必要がある場合は、UseDotNetタスクを使用して、ビルドの一部としてインストールしてください。
steps:
- task: UseDotNet@2
displayName: 'Use .NET Core sdk'
inputs:
version: <dotnet version>Azure Pipelinesは、アーティファクトの公開/ダウンロードのために2つのタスクセットをサポートしています。PublishPipelineArtifactとDownloadPipelineArtifactは、これらの手順を実行するための新しいタスクであり、推奨タスクです。
PublishBuildArtifactsとDownloadBuildArtifactsは旧式のタスクで、対応するPipelineArtifactタスクにあるようなパフォーマンスやストレージの最適化はありません。また、これらの古いタスクには、実装方法の面で規模の制限がありました。大規模なお客様の中には、この限界に直面している方もいらっしゃいます。
すべてのお客様にPipelineArtifactタスクに移行していただきたいと考えていますが、古いBuildArtifactタスクが直面するスケーラビリティ問題に対応するためにも、いくつかの措置を講じる必要がありました。スケーラビリティを向上させるための最近のアップデートの一環として、Azure Pipelinesエージェントは、(tfsドメインを経由するのではなく)blobstoreドメインを介してビルドアーティファクトと直接やり取りするようになりました。これらのパイプラインは、以前からAzure DevoOpsの許可リストに記載されていたものの、特定のパイプラインによって以前は使用されていなかった可能性のあるIPアドレスやドメインへのアクセスを開始します。
BuildArtifactタスクの更新された実装には、エージェントのアップグレードが必要ですが、自動アップグレードが無効になっていたり、ファイアウォールの設定が間違っていたりしない限り、エージェントの更新は自動的に行われるはずです。
リンク先の指示に従わなかったファイアウォール環境でエージェントが動作している場合、ファイアウォールの設定が修正されるまで、エージェントのアップデート時やPublishBuildArtifactsタスク、DownloadBuildArtifactsタスクで障害が発生することがあります。
この問題の一般的な症状は、sslハンドシェイクに関連する突然のエラーや、アーティファクトのダウンロードの失敗で、通常はリリース管理定義の対象となるデプロイメントプールで発生します。また、エージェントのアップグレードがブロックされている場合は、プール内でリリースがエージェントを待っているのに届かなかったり、エージェントがアップデートの途中でオフラインになったりすることがあります（後者は、エージェントCDNを誤ってブロックしている環境に関連しています）。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Aaron Hallberg