排他ロック チェックを使用する場合のシーケンシャル デプロイのサポート

このスプリントでは、シーケンシャル デプロイをサポートするために、Azure Pipelines の排他ロック チェックの機能を拡張しました。 1 つの環境で複数の実行をキューに入れて、そのうちの 1 つだけを一度に実行できるようになりました。

詳細については、次の機能の説明を参照してください。

Azure Boards

• コミット リンクに正しいペルソナを表示する

Azure Pipelines

• 排他ロック チェックを使用する場合にのみ、最新ではなくシーケンシャル デプロイのサポート
• ServiceNow のケベックバージョンのサポート
• Microsoft でホストされている Windows および macOS エージェントでの .NET SDK プレインストール ポリシーの変更
• PublishBuildArtifacts タスクと DownloadBuildArtifacts タスクの変更

Azure Boards

コミット リンクに正しいペルソナを表示する

作業項目の 開発セクション には、関連するコミットとプル要求の一覧が表示されます。 コミットまたはプル要求の作成者を、関連付けられた時刻と共に表示できます。 この更新プログラムでは、作成者のアバターがビューに正しく表示されない問題を修正しました。

Azure Pipelines

排他ロック チェックを使用する場合にのみ、最新ではなくシーケンシャル デプロイのサポート

YAML パイプラインでは、 保護されたリソースに対するステージの実行を制御するためにチェックが使用されます。 使用できる一般的なチェックの 1 つは、排他ロック チェックです。 このチェックでは、パイプラインからの実行を 1 つだけ続行できます。 複数の実行が同時に環境にデプロイしようとすると、チェックは古い実行をすべて取り消し、最新の実行のデプロイを許可します。

リリースが累積的で、以前の実行からのコード変更がすべて含まれている場合は、古い実行をキャンセルすることをお勧めします。 ただし、コードの変更が累積されないパイプラインがいくつかあります。 この新機能を使用すると、すべての実行が環境に順番に進んでデプロイされるようにするか、以前の実行を取り消して最新の実行のみを許可する以前の動作を保持することを選択できます。 この動作は、パイプライン YAML ファイルで という新 lockBehavior しいプロパティを使用して指定できます。 の sequential 値は、すべての実行が保護されたリソースに対して順番にロックを取得することを意味します。 の runLatest 値は、最新の実行のみがリソースへのロックを取得することを意味します。

sequential デプロイまたは runLatest で排他ロックのチェックを使用するには、次の手順に従います。

1. 環境 (または別の保護されたリソース) で排他ロックのチェックを有効にします。
2. パイプラインの YAML ファイルで、 という lockBehavior名前の新しいプロパティを指定します。 これは、パイプライン全体または特定のステージに対して指定できます。

ステージに設定する場合:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

パイプラインに設定する場合:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

を指定 lockBehaviorしない場合は、 と見なされます runLatest。

ServiceNow のケベックバージョンのサポート

Azure Pipelines には、ServiceNow との既存の統合があります。 統合は、ServiceNow の アプリ と Azure DevOps の 拡張機能 に依存しています。 これで、アプリが更新され、ケベックバージョンの ServiceNow で動作するようになりました。 クラシック パイプラインと YAML パイプラインの両方がケベック州で動作するようになりました。 この統合が確実に機能するようにするには、Service Now ストアから新しいバージョンのアプリ (4.188.0) にアップグレードします。 詳細については、「 ServiceNow Change Management との統合」を参照してください。

Microsoft でホストされている Windows および macOS エージェントでの .NET SDK プレインストール ポリシーの変更

最近、Microsoft でホストされている Ubuntu エージェントの .NET SDK プレインストール ポリシーの変更を 発表 しました。 Microsoft がホストする Windows エージェントと macOS エージェントに対して同じ変更を行うようになりました。

現在、Microsoft がホストする Windows および macOS エージェントには、.NET SDK (2.1.x、3.1.x、5.0.x) の使用可能なバージョンとサポートされているすべてのバージョンがインストールされています。 この方法は、すべての機能バージョンに対して最新のパッチ バージョンをインストールするように変更されます。 この変更は、より多くの空き領域と新しいツール要求を提供するために行われています。

これはどういうことですか?

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 イメージから削除されます。 この変更は、Microsoft がホストするエージェント上のすべてのバージョンの Windows と macOS に影響します。

ターゲット日付

更新されたイメージのデプロイは 9 月 6 日に開始され、3 日から 4 日かかります。

考えられる影響

global.json ファイルを使用する場合、ビルドは次の場合に影響を受けます。

global.json ファイルに プロパティと最新のパッチ バージョンではない SDK バージョンが含まれている rollForward: disable 場合、ビルドは失敗します。 次に例を示します。

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

global.json ファイルに プロパティが含まれている場合、.NET SDK のバージョンは自動的に最新のパッチに rollForward: patch 変更されます。 次に例を示します。

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

rollForward global.json ファイルでフィールドが指定されていない場合は、変更はありません。 インストールされている最新のパッチ レベルが使用されます。

最新のパッチではない正確な .NET SDK バージョンを使用する必要がある場合は、タスクをUseDotNet使用してビルドの一部としてインストールしてください。

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

PublishBuildArtifacts タスクと DownloadBuildArtifacts タスクの変更

Azure Pipelines では、成果物を発行またはダウンロードするための 2 つのタスク セットがサポートされています。 PublishPipelineArtifact と DownloadPipelineArtifact は、これらの手順を実行するための新しい推奨されるタスクです。

PublishBuildArtifacts と DownloadBuildArtifacts は古いタスクであり、対応する PipelineArtifact タスクに存在するパフォーマンスとストレージの最適化は同じではありません。 これらの古いタスクには、実装方法に関するスケール制限も含まれています。 大規模な顧客の中には、これらの制限に達している人もいます。

すべてのお客様に PipelineArtifact タスクに移行していただきたいと考えていますが、以前の BuildArtifact タスクのスケーラビリティに対処するためのいくつかの手順も実行する必要がありました。 スケーラビリティを向上させるための最近の更新プログラムの一環として、Azure Pipelines エージェントは、(tfs ドメインを介してルーティングするのではなく) blobstore ドメインを介してビルド成果物と直接やり取りするようになりました。 これらのパイプラインは、Azure DevOps 許可リスト に長い間存在していたが、特定のパイプラインで以前に使用されていない可能性がある IP アドレスとドメインへのアクセスを開始します。

BuildArtifact タスクの更新された実装では、エージェントのアップグレードが必要です。これは、自動アップグレードが明示的に無効になっているか、ファイアウォールが正しく構成されていない限り、自動的に行われます。

リンクされた手順に従っていないファイアウォール環境でエージェントが実行されている場合は、ファイアウォールの構成が修正されるまで、エージェントを更新するとき、または PublishBuildArtifacts タスクまたは DownloadBuildArtifacts タスクでエラーが発生する可能性があります。

この問題の一般的な症状は、ssl ハンドシェイクまたは成果物のダウンロードエラーに関連する突然のエラーです。一般に、Release Management定義の対象となるデプロイ プールで発生します。 または、エージェントのアップグレードがブロックされている場合は、リリースがプール内のエージェントが到着しないのを待機しているか、エージェントが更新プログラムの途中でオフラインになる (この後者は、エージェント CDN を誤ってブロックする環境に関連している) ことを確認できます。

次の手順

Note

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

Azure DevOps に進み、見てみましょう。

Azure DevOps に移動する

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

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

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

よろしくお願いします。

アーロン・ハルベルク