共用方式為

使用獨佔鎖定檢查時，支援循序部署

在此短期衝刺中，我們已擴充 Azure Pipelines 中獨佔鎖定檢查的功能，以支援循序部署。 現在，您可以將環境上的多個執行排入佇列，讓其中一個執行一次。

如需詳細資訊，請參閱下列功能描述。

Azure Boards

Azure Pipelines

Azure Boards

工作專案中 的開發區段 會顯示相關認可和提取要求的清單。 您可以檢視認可或提取要求的作者以及相關聯的時間。 透過此更新，我們已修正在檢視中不正確顯示作者的虛擬人偶問題。

Azure Pipelines

只有在使用獨佔鎖定檢查時，才支援循序部署，而不是最新的

在 YAML 管線中，會使用檢查來控制 受保護資源上的階段執行。 您可以使用的其中一個常見檢查是 獨佔鎖定檢查。 此檢查只允許從管線執行單一執行。 當多次執行嘗試同時部署到環境時，檢查會取消所有舊的執行，並允許部署最新的執行。

當您的版本是累積的，並包含先前執行的所有程式碼變更時，取消舊執行是很好的方法。 不過，有一些管線是程式碼變更不會累積的。 透過這項新功能，您可以選擇允許所有執行以循序方式繼續並部署至環境，或保留取消舊執行並只允許最新的先前行為。 您可以使用管線 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 管線現在都可與加拿大合作。 若要確保此整合能夠運作，請從服務立即存放區升級至新版本的應用程式， (4.188.0) 。 如需詳細資訊，請參閱 與 ServiceNow 變更管理整合。

在 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.302 會針對 2.1.3x 安裝，只有 2.1.403 適用于 2.1.4x 等等。 所有不是最新修補程式版本的 .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"
  }
}

rollForward如果未在 global.json 檔案中指定欄位，則不會為您變更。 會使用最新的已安裝修補程式層級。

如果您需要使用不是最新修補程式的確切 .NET SDK 版本，請使用工作 UseDotNet 將它安裝為組建的一部分：

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

PublishBuildArtifacts 和 DownloadBuildArtifacts 工作的變更

Azure Pipelines 支援兩組工作來發佈/下載成品。 PublishPipelineArtifact 和 DownloadPipelineArtifact 是執行這些步驟的較新建議工作。

PublishBuildArtifacts 和 DownloadBuildArtifacts 是較舊的工作，而且它們沒有對應 PipelineArtifact 工作中存在的相同效能和儲存體優化。 這些較舊的工作也會在實作方式方面有調整限制。 我們有些較大的客戶已執行這些限制。

雖然我們希望所有客戶都移至 PipelineArtifact 工作，但我們也必須採取一些步驟來解決舊版 BuildArtifact 工作的延展性。 在最近更新以改善其延展性時，Azure Pipelines 代理程式現在會透過 Blob 存放區網域直接與組建成品互動 (，而不是透過 tfs 網域) 路由。 這些管線會開始存取長時間在 Azure DevOps 允許清單 上的 IP 位址和網域，但在特定管線之前可能尚未使用。

BuildArtifact 工作的更新實作需要代理程式升級，除非特別停用自動升級或防火牆設定不正確，否則應該會自動進行。

如果您的代理程式在未遵循連結指示的防火牆環境中執行，則在更新代理程式或在 PublishBuildArtifacts 或 DownloadBuildArtifacts 工作中更新代理程式或 DownloadBuildArtifacts 工作時，可能會看到失敗，直到防火牆設定修正為止。

此問題的常見徵兆是與 ssl 交握或成品下載失敗相關的突然錯誤，通常是以Release Management定義為目標的部署集區。 或者，如果代理程式升級遭到封鎖，您可能會發現發行正在等候集區中永遠不會送達的代理程式，或者代理程式在更新 (這兩者與錯誤地封鎖代理程式 CDN) 的環境有關。

後續步驟

注意

這些功能將在接下來兩到三周推出。

請前往 Azure DevOps 並查看。

移至 Azure DevOps

如何提供意見反應

我們希望聽到您對這些功能的想法。 使用說明功能表來回報問題或提供建議。

提供建議

您也可以在 Stack Overflow上取得社群所回答的建議和問題。

感謝您！

Aaron Hallberg

  • Last updated on