Azure DevOps Server 2022 Update 2 版本資訊

發行項
03/11/2025

在本文中，您將找到 Azure DevOps Server 最新版的相關信息。

若要深入瞭解如何安裝或升級 Azure DevOps Server 部署，請參閱 Azure DevOps Server 需求。

若要下載 Azure DevOps Server 產品，請流覽 Azure DevOps Server 下載頁面。

Azure DevOps Server 2019 或 Team Foundation Server 2015 或更新版本支援直接升級至 Azure DevOps Server 2022 Update 2。如果您的 TFS 部署是在 TFS 2013 或更早版本上，您必須先執行一些過渡步驟，才能升級至 Azure DevOps Server 2022。如需詳細資訊，請參閱安裝頁面。

Azure DevOps Server 2022 Update 2 Patch 4 發行日期：2025 年 3 月 11 日

檔案	SHA-256 雜湊
devops2022.2patch4	975B0FC28737C15BA40D6E084663D1A735A66FA821EB40C7A377AE3D58F0C7DA

我們已發行 Azure DevOps Server 2022 Update 2 的 Patch 4，以納入：

因 Edgio CDN 淘汰而更新任務。如需詳細資訊，請參閱切換 CDN 提供者部落格文章。
升級了 Mermaid 依賴項。

Azure DevOps Server 2022 Update 2 Patch 3 發行日期：2025 年 2 月 11 日

注意

在 2025 年 2 月 24 日星期一，我們針對 Azure DevOps Server 2022.2 重新發行 Patch 3。如果您先前已安裝此修補程式的舊版，請使用提供的連結加以更新。此重新發行可解決導致 YAML 管線失敗的問題。如需此問題的進一步詳細資料，請參閱開發人員社群。

檔案	SHA-256 雜湊
devops2022.2patch3	F5C2DA846B8A38A1FB55D1EB555FB2FD6B974B0436F573CC01A0FEBAF3D67521

我們已發行 Azure DevOps Server 2022 Update 2 Patch 3，其中包括：

工件中的更新，以新增 Python 增強提案（PEP）685。此更新回應了開發人員社群中的意見反應。

Azure DevOps Server 2022 Update 2 Patch 2 發行日期：2024 年 11 月 12 日

檔案	SHA-256 雜湊
devops2022.2patch2.exe	70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23

我們已針對 Azure DevOps Server 2022 更新 2，發行了修補程式 2，以升級易受攻擊的相依性。

Azure DevOps Server 2022.2 RTW 發行日期：2024 年 7 月 9 日

Azure DevOps Server 2022.2 RTW 的新功能摘要

注意

我們已重新發行 Azure DevOps Server 2022.2，以修正載入 Teams 名稱的問題。在 Azure DevOps Server 2022.2 RTW 現已提供的部落格文章中，此問題已被回報。如果您已安裝 7 月 9 日發行的 Azure DevOps Server 2022.2 版本，您可以安裝適用於 Azure DevOps Server 2022.2 的修補程式 1 來修正此問題。第一次安裝 Azure DevOps Server 2022.2 時，不需要修補程式 1，因為下載連結已更新，已包含修正程式。

Azure DevOps Server 2022.2 RTW 是 Bug 修正的匯總。其中包含先前發行的 Azure DevOps Server 2022.2 RC 中的所有功能。您可以直接安裝 Azure DevOps Server 2022.2 或從 Azure DevOps Server 2020、2019 或 Team Foundation Server 2015 或更新版本升級。此版本已解決下列問題和弱點：

CVE-2024-35266：Azure DevOps Server 詐騙弱點
CVE-2024-35267：Azure DevOps Server 詐騙弱點
開發人員社群意見反應票證：升級至 Azure DevOps Server 2022.1 並使用代理程式集區設定中的更新代理程序之後，代理程式版本不會更新
開發人員社群意見反應票證：載入小組設定頁面的問題
開發人員社群意見反應票證：修正特定地區格式 PR 電子郵件通知中的不正確日期處理

Azure DevOps Server 2022 Update 2 RC 發行日期：2024 年 5 月 7 日

Azure DevOps Server 2022.2 RC 包含許多新功能。一些重點包括：

區域和疊代路徑的限制
略過管線中的核准和檢查
改善 YAML 驗證
Azure Artifacts 對 Cargo Crates 的支援
新的儀錶板目錄體驗
使用測試計劃或套件識別碼快速複製和匯入

您也可以跳至個別區段，以查看每個服務的新功能：

一般
公告欄
Repos
管線
文物
報表

一般

發佈測試結果工作

[發佈測試結果] 工作現在支援 JUnit 報表格式的測試運行附件。

新版的 Azure DevOps Web 擴充功能 SDK

透過此更新，我們將發行新版本的 Azure DevOps Web 擴充功能 SDK。用戶端 SDK 可讓 Web 延伸模組與主機框架通訊。它可以用來：

通知主機延伸套件已載入或有錯誤
取得目前頁面的基本內容資訊（目前使用者、主機和延伸模組資訊）
取得主題資訊
取得授權令牌以便在 REST 呼叫返回 Azure DevOps 時使用
取得由主機框架提供的遠端服務

您可以在 azure-devops-extension-sdk 套件檔中找到完整的 API 參考。這個新版本提供下列模組的支援：

ES 模組支援： SDK 現在除了現有的 AMD（異步模組定義）模組之外，還支援ES （ECMAScript）模組。您現在可以使用 ES 模組語法來匯入 SDK，其可提供效能改善並減少應用程式大小。
AMD 模組的回溯相容性： AMD 模組的現有支援保持不變。如果您的專案使用 AMD 模組，您可以像以前一樣繼續使用它們，而不需要進行任何變更。

如何使用：

針對 ES 模組，您可以使用 import 語句來匯入我們的模組：

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

如果您使用 AMD 模組，您可以使用函 require 式繼續匯入 SDK：

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

板子

區域和迭代路徑的限制

限制在維護大型全球服務的健康與效率方面起著重要作用。在此版本中，我們為區域路徑和迭代路徑每個專案引入硬性限制，設為 10,000。請流覽工作追蹤、程式和專案限制頁面，以深入瞭解服務中的不同限制。

區域和反覆專案路徑的螢幕快照。

開發和部署控制件

我們現在會根據您的項目設定方式，從工作專案中移除開發和/或部署控件。例如，您可以設定項目設定來關閉 Repos 和/或 Pipelines。

DevOps 服務的螢幕快照。

當您移至工作專案時，表單中將會隱藏對應的開發和部署控制項。

相關工作的螢幕快照。

如果您決定將 GitHub 存放庫連線至 Azure Boards，則會顯示 GitHub 存放庫的開發控制件。

開發控件的螢幕快照。

Repos

新的「分支原則」可防止使用者核准自己的變更

為了更好地控制使用者核准的變更項目並滿足更嚴格的法規/合規性要求，我們提供選項來防止使用者核准自己的變更，除非有明確允許。

具有管理分支政策能力的用戶現在可以在「推送新變更時」選擇切換新添加的選項「每次迭代至少需要一個批准」。當選擇此選項時，至少需要針對來源分支最後一次變更的核准投票。使用者的核准不會計入該使用者所推送的任何先前未核准版本。因此，最後一次迭代需要由另一位用戶進行額外的批准。

下圖顯示使用者 A 所建立的提取要求，以及使用者 B、C、A 和 C 對該提取要求所做的額外 4 個認可（反覆專案）。在第二次反覆專案（使用者 B 完成的認可）完成之後，使用者 C 核准了。屆時，這意味著核准了使用者 A 的第一次提交（建立提取請求時），並且新引進的政策將會成功。第五次反覆運算之後（使用者 C 的最後一次認可），使用者 A 已完成核准。此隱含核准先前由使用者 C 完成的認可，但不表示第四次反覆運算中使用者 A 完成的第二次認可核准。若要讓新引進的政策成功，尚未核准的第4版必須由使用者 B、C，或任何其他未對拉取請求進行變更的使用者核准。

權限管理圖像。

註

已知的問題是，分支原則將這類設為檢閱者的群組視作核准實體。假設 G 群組的任何使用者都已完成必要的核准。使用者 A 是該群組 G 的成員。在使用者 A 提供如上圖中的核准之後（第五次反覆項目之後），群組 G 核准會核准使用者 A 所做的變更。這並非預期，將會在 RTW 版本中解決。

無 Blob 和無樹狀篩選支援

重要

預設會停用此功能。若要啟用此功能，請在 Config DB 上執行下列查詢：

exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1

Azure DevOps 現在支援複製/擷取時另外兩個篩選。以下是： --filter=blob:none 和 --filter=tree:0 第一個選項（無 Blob 複製）最適合用於常規開發，而第二個選項（無樹狀複製）更適合於那些在使用完後，例如在執行完組建後就刪除複製的情況。

SSH-RSA 漸進淘汰政策

Azure Repos 提供兩種方法，讓使用者存取 Azure Repos 中的 Git 存放庫 – HTTPS 和 SSH。若要使用 SSH，您必須使用其中一種支援的加密方法建立金鑰組。過去，我們只支援 SSH-RSA，並要求使用者在這裡啟用 SSH-RSA。

透過此更新，我們宣佈淘汰 SSH-RSA 作為支援使用 SSH 連線到 Azure Repos 的加密方法。您可以在 Azure Repos 的 SSH-RSA 終止支援部落格文章中看到更多詳細數據。

管線

防止非預期的管線執行

目前，如果您的 YAML 管線未指定 trigger 區段，它會針對推送至其存放庫的任何變更執行。這可能會讓人對管線執行的原因感到困惑，並會導致許多非預期的運行。

我們新增了名為 [停用隱含 YAML CI 觸發程式 ] 的專案集合和專案層級管線設定，可讓您變更此行為。如果觸發區段遺漏，您可以選擇不觸發流水線。

YAML CI 觸發程式的螢幕快照。

在核准和檢查逾時時重新嘗試該階段

核准和檢查逾時時，會略過其所屬的階段。相依於被略過階段的其他階段也會被略過。

您現在可以在核准和檢查逾時時重試流程步驟。之前僅限於在核准逾時時才能這樣做。

階段重試的螢幕快照。

略過核准和檢查

核准和檢查有助於保護重要資源的存取，例如服務連線、存放庫或代理程式集區。常見的使用案例是在部署至生產環境時使用核准和檢查，而您想要保護ARM服務連線。

假設您在服務連線中新增了以下檢查：核准檢查、營業時間檢查，以及呼叫 Azure 函數檢查（以在不同區域之間強制延遲）。

現在，假設您必須執行 Hotfix 部署。您啟動管線執行，但執行不會繼續，會等候大部分檢查完成。您不能再等著核准和檢查完成。

在此版本中，我們允許您略過執行中的核准和檢查，以便完成緊急修正。

您可以略過核准流程、勤務時間、呼叫 Azure 函式和呼叫 REST API 檢查。

略過核准。

略過核准的螢幕快照。

略過上班時間檢查。

略過上班時間檢查的螢幕快照。

略過叫用 Azure 函式檢查。略過上班時間檢查。

略過呼叫 Azure 函式檢查的螢幕快照。

略過檢查時，您可以在 [檢查] 面板中看到它。

已略過檢查的螢幕快照。

只有當您是已定義檢查的資源系統管理員時，才能略過檢查。

必要 YAML 範本的螢幕快照。

重新執行叫用 Azure 函式檢查

假設您在多個階段部署系統。在部署第二個階段之前，會先進行核准並叫用 Azure 函式以進行系統已部署部分的完整性檢查。

檢閱核准申請時，您會注意到合理性檢查已於兩天前執行。在此案例中，您可能會注意到另一個會影響理智檢查結果的部署。

透過此更新，您可以重新執行叫用 Azure 函式和叫用 REST API 檢查。這項功能僅適用於成功且沒有重試的檢查。

動態檢查的螢幕快照。

注意

只有當您是已定義檢查的資源系統管理員時，才能重新執行檢查。

必要範本檢查對 GitHub 企業伺服器的支援

範本是一種安全性機制，可讓您控制專案集合中管線的階段、作業和步驟。

要求範本檢查讓您可以強制管線必須從一組核准的範本延伸之後，才能存取受保護的資源，例如代理程式集區或服務連線。

您現在可以指定位於 GitHub Enterprise Server 存放庫中的範本。

所有環境的系統管理員角色

YAML 管線中的環境代表您部署應用程式的計算資源，例如 AKS 叢集或一組 VM。他們為您的部署提供安全控制和追蹤能力。

管理環境可能相當具有挑戰性。這是因為建立環境時，建立環境的人員會自動成為唯一的系統管理員。例如，如果您想要以集中式方式管理所有環境的核准和檢查，您必須要求每個環境管理員將特定使用者或群組新增為系統管理員，然後使用 REST API 來設定檢查。此方法很繁瑣、容易出錯，而且在新增環境時不會進行調整。

在此版本中，我們在環境中樞層級新增了系統管理員角色。這使環境能達到與服務連線或代理程式集區相同的水準。若要將系統管理員角色指派給使用者或群組，您必須已經是 environment-hub 系統管理員或專案集合擁有者。

系統管理員角色的螢幕快照。

具有此系統管理員角色的使用者可以管理許可權、管理、檢視和使用任何環境。這包括對所有管線開放環境。

當您在環境中樞層級授與用戶系統管理員角色時，這些角色會成為所有現有環境和任何未來環境的系統管理員。

改善 YAML 驗證

若要確認 YAML 語法正確，您可以使用 Azure Pipelines Web 編輯器的 Validate 功能。因此，這項功能必須盡可能攔截許多 YAML 問題。

YAML 驗證的螢幕快照。

在表達式方面，YAML 驗證現在更徹底。

撰寫 YAML 管線時，您可以使用函式來定義變數值。

假設您定義下列變數：

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

變數 Patch 是使用 counter 函式和其他兩個變數來定義。在上述 YAML 程式代碼中，文字 format 拼錯。先前，這個錯誤未偵測到。現在，驗證功能會偵測到此狀況並顯示錯誤訊息。

偵測到不正確變數定義的螢幕快照。

Azure Pipelines 會在管線/階段/作業層級偵測不正確的變數定義。

在 YAML 管線中，您可以使用條件來略過執行階段。錯字也可以顯示在這裡，如下列範例所示。

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

只有當該變數的值為0時，NuGetCommand任務才會執行。同樣地，條件中有錯字，而 [驗證 ] 功能會顯示它。

Patch 變數的螢幕快照。

Azure Pipelines 會偵測在管線/階段/作業層級定義的不正確 YAML 條件。

適用於環境的 REST API

環境是您可以從管線部署的目標資源集合。環境提供部署歷程記錄、工作項目和提交的追蹤能力，以及存取控制機制。

我們知道您想要以程序設計方式建立環境，因此我們已發佈其 REST API 的檔。

核准流程 REST API 的改善

我們已經改善了搜尋指派給使用者之核准的功能，透過在搜尋結果中顯示使用者所屬的群組。

批准現在包含其所屬的管道運行的資訊。

例如，下列 GET REST API 呼叫 https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending 會傳回

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

管線記錄現在包含資源使用率

Azure 管線記錄現在可以擷取資源使用率計量，例如記憶體、CPU 使用量和可用的磁碟空間。日誌還包括管線代理程式及子程序所使用的資源，包括在作業中執行的任務。

記錄的螢幕快照，包括管線所使用的資源。

如果您懷疑管線作業可能會遇到資源限制，請啟用詳細日誌，以便將資源使用率資訊添加到管線記錄中。這適用於與裝載模型無關的任何代理程式。

Azure Pipelines 代理程式現在支援 Alpine Linux

Pipeline 代理程式 v3.227 現在支援 Alpine Linux 3.13 版和更新版本。 Alpine Linux 適用於容器（基底）映像。您可以在發行頁面上找到代理程式。 Alpine Linux 版本的代理程式具有前置詞 vsts-agent-linux-musl ，例如 vsts-agent-linux-musl-x64-3.227.1.tar.gz。

Azure Pipelines 工作使用 Node 16

管線中的工作會使用執行器來執行，且大部分情況下會使用Node.js。使用 Node.js 做為執行器的 Azure Pipelines 工作現在全都使用 Node.js 16。由於 Node 16 是第一個原生支援 Apple 晶片的 Node 版本，這也會完成 Apple 晶片上 macOS 的完整工作支援。在 Apple 晶片上執行的代理程式不需要 Rosetta 執行。

隨著 Node.js 16 生命週期結束日期的提前，我們已開始使用 Node.js 20 進行任務。

增加 Azure Pipeline 限制，以符合 4 MB 的 Azure Resource Manager （ARM）範本大小上限。

您可以使用 Azure Resource Manager 範本部署工作來建立 Azure 基礎結構。為了回應您的意見反應，我們已將 Azure Pipelines 整合限制 2 MB 增加到 4 MB。這將與 ARM 範本的 4 MB 大小上限一致，以解決整合大型範本時的大小限制問題。

AzureRmWebAppDeployment 工作支援 Microsoft Entra ID 身份驗證

AzureRmWebAppDeploymentV3 和AzureRmWebAppDeployment@4工作已更新，以支援已停用基本身份驗證的 App Service。如果 App Service 上停用基本身份驗證，AzureRmWebAppDeploymentV3/4 工作會使用 Microsoft Entra ID 驗證來執行 App Service Kudu 端點的部署。這需要在代理程式上安裝最新版本的 msdeploy.exe，也就是 windows-2022/windows-latest 託管代理程式上的情況（請參閱工作參考）。

建置失敗時，停用將程式碼覆蓋原則狀態覆寫為“失敗”的功能。

先前在某些情況下，如果您的 PR 建置失敗，程式碼覆蓋率政策的狀態會被覆寫為「失敗」。這對於一些將建置作為選擇性檢查，並把程式碼涵蓋率政策設為必要檢查的您來說，是造成 PR 被阻擋的一個障礙。

現在，如果建置失敗，程式代碼涵蓋範圍原則將不會覆寫為「失敗」。此功能將會為所有客戶啟用。

文物

介紹 Azure Artifacts 對 Cargo Crates 的支援

我們很高興宣佈 Azure Artifacts 現在提供對 Cargo crates 的原生支援。除了 crates.io 作為上游來源之外，這項支援還包括與現有通訊協定的功能對等。 Rust 開發人員和小組現在可以順暢地取用、發佈、管理及共用其 Cargo 箱，同時使用 Azure 的強固基礎結構並留在熟悉的 Azure DevOps 環境中。

NuGet 還原 v1 和 NuGet 安裝程式 v0 管線任務的棄用公告

如果您使用 NuGet Restore v1 和 NuGet Installer v0 管線工作，請立即轉換至NuGetCommand@2管線工作。如果您尚未進行轉換，您很快就會在您的管線中收到警示。若未採取任何動作，從 2023 年 11 月 27 日起，您的組建將會導致失敗。

Azure Artifacts 對 npm 稽核的支援

Azure Artifacts 現在支援 npm audit 和 npm audit fix 命令。此功能可讓用戶藉由自動更新不安全的套件版本來分析和修正其專案的弱點。若要深入瞭解，請使用 npm 稽核來偵測並修正套件弱點。

報告

新的儀錶板目錄體驗

我們已聆聽您的意見反應，並很高興推出新的儀錶板目錄體驗。它不僅具有新式UI設計，還可讓您依每個數據行排序，並新增 [上次設定 ] 資料行。此欄位可提供您更佳的洞察力，以便瞭解專案集合內儀錶板的整體使用情況。此外，您現在可以依據小組或專案層級的儀錶板進行篩選，這樣您只會看到需要的項目清單，而不會顯示不想查看的儀錶板。

Gif 用於演示新的儀錶板目錄。

立即試用，並讓我們知道您在 Azure DevOps 社群中的想法

工作項目篩選

我們很高興宣佈 工作專案圖表篩選。 這項功能可讓您將滑鼠停留在工作項目圖表上，以取得快速概觀，並向下切入至特定圖表區段以取得詳細深入解析。您不再需要建立自定義查詢，即可存取所需的確切數據片段。您現在可以透過幾個點擊，探索工作項目圖表中的工作項目。

GIF 示範工作項目篩選。

您的意見反應對於塑造此功能的未來非常重要。立即試用，讓我們知道您在 Azure DevOps 社群中的想法。

資料夾的程式碼涵蓋率結果

程式碼涵蓋範圍的結果現在可供每個個別檔案和資料夾查看，而不僅僅是作為一個最高層級數字。按下資料夾檢視模式按鈕時，會出現程式代碼涵蓋範圍檢視。在此模式中，您可以向下切入並查看所選子樹的程式代碼涵蓋範圍。使用切換按鈕在新的和舊檢視之間切換。

測試計劃

使用測試計劃或套件識別碼快速複製和匯入

您現在可以輕鬆處理 Azure Test Plans 中的多個測試計劃！認識到先前在匯入、複製或克隆測試案例時長下拉選單帶來的挑戰，特別是針對大型的計劃或套件，我們已採取措施來簡化您的工作流程。

我們很高興宣布測試方案和套件標識碼搜尋功能。輸入您的測試計劃或套件識別碼，以快速匯入或複製測試案例，而不會有任何延遲。此更新是我們持續致力於改善測試管理體驗的一部分，使其更直覺且更省時。

GIF 用來演示測試計劃、套件ID搜尋的詳細資料。

Azure 測試執行器更新

我們很高興分享 Azure 測試執行器已更新為較新版本。此更新可改善穩定性和效能，讓您在不中斷或延遲的情況下執行測試。不再支援舊版的 Azure 測試執行器。為了獲得最佳測試作業的效能和可靠性，建議您儘快更新為最新版本。

新功能？

增強穩定性和效能： 我們已大幅改善測試執行器，解決一些使用者遇到的問題。此升級可確保更可靠的測試程式，將工作中斷降至最低。
升級提示： 若要順暢地轉換至新版本，您將會遇到升級的提示。這可確保每個人都能在方便時輕鬆移至改良的版本，提高相容性和效能。

升級提示的螢幕快照。

意見反應

我們很希望聽聽您的意見！您可以回報問題或提供想法，並透過開發人員社群追蹤問題，並取得 Stack Overflow 的建議。

頁首

共用方式為