Azure DevOps Server 2022 Update 2 版本資訊
| 開發人員社群 System 需求和相容性 | 授權條款 | DevOps 部落格 | SHA-256 哈希 | |
在本文中,您將找到 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.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 並使用 Agent 集區設定中的更新代理程序之後,代理程式版本不會更新
- 開發人員社群 意見反應票證:載入小組設定頁面的問題
- 開發人員社群 意見反應票證:修正特定地區格式 PR 電子郵件通知中的不正確日期處理
Azure DevOps Server 2022 Update 2 RC 發行日期:2024 年 5 月 7 日
Azure DevOps Server 2022.2 RC 包含許多新功能。 一些重點包括:
- 區域和反覆項目路徑的限制
- 略過管線中的核准和檢查
- 改善 YAML 驗證
- 適用於 Cargo Crates 的 Azure Artifacts 支援
- 新的儀錶板目錄體驗
- 使用測試計劃或套件識別碼快速複製和匯入
您也可以跳至個別區段,以查看每個服務的新功能:
一般
發佈測試結果工作
[發佈測試結果] 工作現在支援 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
});
Boards
區域和反覆項目路徑的限制
限制在維護大型全球服務的健康與效率方面起著重要作用。 在此版本中,我們針對區域和反覆專案路徑引進每個專案的硬性限制為 10,000。 請流覽工作 追蹤、程式和專案限制 頁面,以深入瞭解服務中的不同限制。
開發和部署控制件
我們現在會根據您的項目設定方式,從工作專案中移除開發和/或部署控件。 例如,您可以設定項目設定來關閉 Repos 和/或 Pipelines。
當您移至工作專案時,表單中將會隱藏對應的開發和部署控制項。
如果您決定將 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 觸發程式 ] 的專案集合和專案層級管線設定,可讓您變更此行為。 如果遺漏觸發程式區段,您可以選擇不要觸發管線。
在核准和簽出逾時時重試階段
核准和檢查逾時時,會略過其所屬的階段。 也會略過相依於略過階段的階段。
現在,您可以在核准和檢查逾時時重試階段。之前,只有在核准逾時時,才可能這樣做。
略過核准和檢查
核准和檢查 有助於保護重要資源的存取,例如服務連線、存放庫或代理程式集區。 常見的使用案例是在部署至生產環境時使用核准和檢查,而您想要保護ARM服務連線。
假設您已在服務連線上新增下列檢查:核准、上班時間檢查和叫用 Azure 函式檢查(以強制執行不同區域之間的延遲)。
現在,假設您必須執行 Hotfix 部署。 您啟動管線執行,但不會繼續,它會等候大部分的檢查完成。 您無法等待核准和檢查完成。
在此版本中,我們可讓您略過執行中的核准和檢查,以便完成 Hotfix。
您可以略過執行中的核准、上班時間、叫用 Azure 函式和叫用 REST API 檢查。
略過核准。
略過上班時間檢查。
略過叫用 Azure 函式檢查。 略過上班時間檢查。
略過檢查時,您可以在 [檢查] 面板中看到它。
只有當您是已定義檢查的資源系統管理員時,才能略過檢查。
重新執行叫用 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 管線時,您可以使用 函 式來定義變數值。
假設您定義下列變數:
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 時,Patch
工作NuGetCommand
才會執行。 同樣地,條件中有錯字,而 [驗證 ] 功能會顯示它。
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 工作使用節點 16
管線中的工作會使用執行器來執行,且大部分情況下會使用Node.js。 使用節點做為執行器的 Azure Pipelines 工作現在全都使用節點 16。 由於 Node 16 是第一個原生支援 Apple 晶片的 Node 版本,這也會完成 Apple 晶片上 macOS 的完整工作支援。 在 Apple 晶片上執行的代理程式不需要 Rosetta 執行。
隨著節點 16 生命週期結束日期的 推進,我們已開始使用節點 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 遭到封鎖的必要檢查。
現在,如果建置失敗,程式代碼涵蓋範圍原則將不會覆寫為「失敗」。 此功能將會為所有客戶啟用。
Artifacts
介紹 Azure Artifacts 對 Cargo Crates 的支援
我們很高興宣佈 Azure Artifacts 現在提供貨物箱的原生支援。 除了 crates.io 作為上游來源,這項支援還包含現有通訊協定的功能同位。 Rust 開發人員和小組現在可以順暢地取用、發佈、管理及共用其 Cargo 箱,同時使用 Azure 的強固基礎結構並留在熟悉的 Azure DevOps 環境中。
NuGet 還原 v1 和 NuGet 安裝程式 v0 管線工作的淘汰公告
如果您使用 NuGet Restore v1 和 NuGet Installer v0 管線工作,請立即轉換至NuGetCommand@2管線工作。 如果您尚未進行轉換,您很快就會在管線中收到警示。 若未採取任何動作,從 2023 年 11 月 27 日起,您的組建將會導致失敗。
npm 稽核的 Azure Artifacts 支援
Azure Artifacts 現在支援 npm audit
和 npm audit fix
命令。 此功能可讓用戶藉由自動更新不安全的套件版本來分析和修正其專案的弱點。 若要深入瞭解, 請使用 npm 稽核來偵測並修正套件弱點。
報表
新的儀錶板目錄體驗
我們已聆聽您的意見反應,並很高興推出新的儀錶板目錄體驗。 它不僅具有新式UI設計,還可讓您依每個數據行排序,並新增 [上次設定 ] 資料行。 此數據行可讓您深入了解專案集合內的整體儀錶板使用量。 此外,您現在可以依小組或專案層級儀錶板進行篩選,讓您只存取隱藏您不想檢視之儀錶板時需要查看的項目清單。
立即試用,並讓我們知道您在 Azure DevOps 社群中 的想法
工作項目篩選
我們很高興宣佈 工作專案圖表篩選。 這項功能可讓您將滑鼠停留在工作項目圖表上,以取得快速概觀,並向下切入至特定圖表區段以取得詳細深入解析。 您不再需要建立自定義查詢,即可存取所需的確切數據片段。 您現在可以按幾下滑鼠,深入探討工作項目圖表中的工作專案。
您的意見反應對於塑造此功能的未來非常重要。 立即試用,讓我們知道您在 Azure DevOps 社群中的想法。
資料夾的程式代碼涵蓋範圍結果
程式代碼涵蓋範圍的結果現在可供每個個別檔案和資料夾使用,而不只是最上層數位。 切換 [資料夾檢視模式] 按鈕時 ,會出現程式代碼涵蓋範圍 檢視。 在此模式中,您可以向下切入並查看所選子樹的程式代碼涵蓋範圍。 使用切換按鈕在新的和舊檢視之間切換。
測試計劃
使用測試計劃或套件識別碼快速複製和匯入
您現在可以輕鬆處理 Azure Test Plans 中的多個測試計劃! 辨識先前針對匯入、複製或複製測試案例所面臨長下拉功能表的挑戰,特別是針對廣泛的計劃或套件,我們已採取步驟來簡化您的工作流程。
我們很高興宣布測試方案和套件標識碼搜尋功能。 輸入您的測試計劃或套件識別碼,以快速匯入或複製測試案例,而不會有任何延遲。 此更新是我們持續致力於改善測試管理體驗的一部分,使其更直覺且更耗時。
Azure 測試執行器更新
我們很高興分享 Azure 測試執行器已更新為較新版本。 此更新可改善穩定性和效能,讓您在不中斷或延遲的情況下執行測試。 不再支援舊版的 Azure 測試執行器。 為了獲得最佳測試作業的效能和可靠性,建議您儘快更新為最新版本。
新功能?
- 增強穩定性和效能: 我們已大幅改善測試執行器,解決一些使用者遇到的問題。 此升級可確保更可靠的測試程式,將工作中斷降至最低。
- 升級提示: 若要順暢地轉換至新版本,您將會遇到升級的提示。 這可確保每個人都能在方便時輕鬆移至改良的版本,提高相容性和效能。
意見反應
我們很希望聽聽您的意見! 您可以回報問題或提供想法,並透過 開發人員社群 追蹤問題,並取得 Stack Overflow 的建議。