次の方法で共有

排他ロック チェックを使用する場合の順次展開のサポート

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

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

Azure Boards

Azure Pipelines

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.32 のみがインストールされ、2.1.4x の場合は 2.1.403 のみがインストールされます。 最新のパッチ バージョンではない .NET SDK のすべてのバージョンは、9 月 6 日に Windows および macOS イメージから削除されます。 この変更は、Microsoft がホストするエージェント上のすべてのバージョンの 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>

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

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

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

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

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

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

この問題の一般的な症状は、SSL ハンドシェイクまたは成果物のダウンロードエラーに関連する突然のエラーです。一般に、リリース管理定義の対象となる展開プールで発生します。 エージェントのアップグレードがブロックされている場合、プール内でリリースを待っているエージェントが決して現れない、またはエージェントが更新の途中でオフラインになる状況を観察するかもしれません（後者は誤ってエージェントのCDNをブロックしている環境に関連しています）。

次のステップ

注

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

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

Azure DevOps に移動する

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

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

提案を行う

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

よろしくお願いします。

アーロン・ハルベルク

  • Last updated on