| 開發者社群 | 系統要求和相容性 | 授權條款 | DevOps 部落格 | SHA-256 雜湊 |
在本文中,您將找到 Azure DevOps Server 最新版本的相關資訊。
若要深入瞭解如何安裝或升級 Azure DevOps Server 部署,請參閱 。
若要下載 Azure DevOps Server 產品,請流覽 Azure DevOps Server 下載頁面。
支援從 Azure DevOps Server 2019 或 Team Foundation Server 2015 或更新版本直接升級至 Azure DevOps Server。 如果您的 TFS 部署位於 TFS 2013 或更早版本上,您必須先執行一些臨時步驟,才能升級至 Azure DevOps Server 2022。 請參閱 安裝頁面 以取得更多資訊。
Azure DevOps Server 發布日期:2025 年 12 月 9 日
Azure DevOps Server RTW 是整合了錯誤修正與變更,以支援 SQL Server 2025。 它包含了先前發布的 Azure DevOps Server RC 中的所有功能。
你可以直接安裝 Azure DevOps Server,或從 Azure DevOps Server 2022、2020、2019 或 Team Foundation Server 2015 或更新版本升級。
Azure DevOps Server RTW 最新資訊摘要
- 合併的本地化變更。
- 支援 SQL Server 2025 的變更。
- 已修正一個問題,即在儀表板頁面的程式碼磚小工具設定中,過長的儲存庫或分支名稱會超過下拉選單的控制範圍。
- 已修正一個問題:當使用 webhook 時,無論是合併還是未合併的 pull request,GitHub PR 狀態都錯誤地被儲存為已關閉。 系統現在依賴 webhook 載荷中合併的布林值標誌來準確記錄資料庫中的正確狀態。
- 修正了一個遞迴屬性問題,導致 Visual Studio 在工作項目追蹤(WIT)連結情境中當機。
- 解決了一個問題:當分析功能被暫停或停用時,集合設定下的代理池頁面會出現錯誤且無法載入。 現在無論 Analytics 狀態如何,頁面都能正確載入。
Azure DevOps Server RC 發行日期:2025 年 10 月 7 日
Azure DevOps Server RC 的新內容摘要
Azure DevOps Server 引進我們先前在裝載的產品版本中發行的功能。 您可以跳至個別區段,以查看每項服務的所有新功能:
General
將程式代碼區塊複製到剪貼簿
為了回應您在 開發人員社群中的意見反應,我們已為轉譯 Markdown 中的所有程式碼區塊引進 [複製至剪貼簿 ] 按鈕。 這項增強功能可在Wiki頁面中取得、Repos中的 Markdown 檔案預覽、提取要求討論和描述,以及工作項目討論。
已新增交付計劃權限
作為持續安全性增強功能的一部分,我們引進了新的管理傳遞計劃專案層級許可權。 實作此變更是為了防止「讀者」群組中的使用者無意中讀取/寫入存取權。
Boards
GitHub 提取要求上的 AB# 連結
作為 Azure Boards + GitHub 整合持續增強功能的一部分,我們很高興推出一項新功能,以簡化 AB# 鏈接的顯示方式。 透過此更新,AB# 鏈接現在會直接出現在 GitHub 提取要求的 [開發] 區段中,讓您更輕鬆地存取連結的工作專案,而不需搜尋描述或批注。
只有在提取要求描述中包含AB# 時,才會顯示這些連結。 如果您直接從工作專案連結,它們將不會顯示在 [開發] 區段中。 此外,從描述中移除 AB# 連結會從開發控件中移除它。
線上至 GitHub 存放庫搜尋改善
我們已改善將 Azure DevOps 專案連線至 GitHub 組織的程式,特別適合擁有數千個存放庫的組織。 以前,您可能面臨逾時錯誤和等待時間過長等挑戰。 這次更新優化了搜尋和選擇體驗,消除了逾時錯誤的風險,使連線過程更加順暢和有效率。
GitHub 整合:顯示 YAML 管線的組建狀態
我們致力於在 YAML 與傳統管線之間達成功能同位。 當存儲庫託管於 GitHub 時,其中一項關鍵缺少的功能是提供「內建整合」連結。 在最新版本中,我們已藉由在 YAML 管線設定中新增選項來解決此差距,以便您檢查:
建置完成後,對應的連結會自動出現在相關聯的工作專案上,以改善整體可追蹤性的故事。
連線 GitHub 存放庫的 REST API 支援
我們引進了新的 REST API 端點,可讓您自動新增和移除 Azure DevOps Projects 中的 GitHub 存放庫。 此外,我們在使用這些端點時,將每個連線的存放庫限制從 500 增加到 2,000。
這些端點包括:
我們也 提供範例程式代碼 來協助您開始使用。
刪除區域和反覆專案路徑的變更
刪除區域或疊代路徑可能會造成中斷。 它可以將工作專案移至新的路徑,並可能導致小組無法存取其面板和待辦專案。 儘管有警告和提示,但有時路徑會在未完全了解後果的情況下被刪除。 為了解決此問題,我們變更了行為:區域和反覆專案路徑現在只有在不再被任何工作專案使用時才能刪除。
工作項目表單上的增強標記管理
Azure Boards 中的標籤管理已增強,以提供更精簡的體驗。 已刪除的標籤不再出現在工作項目表單的建議清單中,確保只會顯示作用中的標籤。
改善工作專案批注中的影像支援
我們已改善將影像貼入工作專案批注的支援。 您現在可以直接從Microsoft Teams、電子郵件和 Word 檔等來源貼上影像到工作項目的討論區段
REST API 對工作專案註解的限制
為了增強安全性,已對可透過 REST API 新增至工作專案的註解數目設定新的限制。 每個工作專案現在透過 API 最多支援 1,000 個註解。 此限制僅適用於 REST API,使用者仍然可以透過 Web 介面手動新增註解,即使超過 1,000 個註解閾值。
交付計劃限制提高
我們已將每個專案的最大交付計劃數量從 1,000 個增加到 1,500 個。
Repos
停用建立 TFVC 存放庫的新設定
近年來,Team Foundation 版本控制 (TFVC) 沒有新增任何新功能,因為 Git 已成為 Azure Repos 中慣用的版本控制系統。 安全性、效能和可存取性的所有最近改進都專門針對 Git 儲存庫進行,導致 TFVC 使用量持續下降。 雖然有些仍依賴 TFVC,而且我們不打算移除此功能集,但我們計劃逐步淘汰新專案和專案集合的 TFVC,以及目前未使用 TFVC 的專案。
在此轉換中,我們引進了「停用建立 TFVC 存放庫」的新設定,這只會影響建立新的 TFVC 存放庫,而不會影響現有的存放庫。
Git 子模組的 UI 支援
許多團隊積極使用 Git 子模組來組織他們的程式碼庫。 我們很高興與大家分享,我們已在檔案中樞新增了對 Git 子模組的支援。 現在,您只需單擊一下即可立即導覽至子模組版本庫,精確跳至主專案中參考的特定提交記錄。 當用作子模組時,支援下列 Git 服務:Azure Repos、GitHub、GitLab 和 Bitbucket。 也支援 .gitmodules 檔案中指定的多種 URL 格式,包括絕對 HTTPS、SSH 和相對 URL。
存放庫檔案中樞的新 [健康情況和使用方式] 面板
隨著 Git 存放庫成長,它們會累積認可、Blob 和其他數據,進而增加 Azure DevOps 基礎結構的負載,進而影響效能和用戶體驗。 維護狀況良好的存放庫是確保一致效能和可靠性的關鍵。
為了支援這項功能,我們現在會監視數個因素,例如存放庫大小、認可頻率、內容和結構。 如果您的存放庫開始對基礎結構產生負擔,您可能會收到通知,其中包含矯正措施的建議。 藉由管理存放庫的健康情況,您可以防止中斷情況發生,並確保作業順暢進行。
若要檢查存放庫的健康情況,請移至 [Azure Repos]、[檔案], > 然後從省略號功能表選擇 [健康情況和使用方式],以存取 [存放庫健康情況和使用方式] 面板。
設定提取要求的目標分支
在存放庫中管理多個分支可能會很困難,尤其是在建立新的提取要求時。 有了新的 [設定提取要求的目標分支] 功能,您現在可以指定慣用的目標分支清單,確保提取要求建議更準確且相關。 這有助於簡化工作流程,並減少以錯誤分支為目標的機會。 若要使用此功能,請在存放庫的預設分支中建立 .azuredevops/pull_request_targets.yml 檔案。 此 YAML 檔案應該包含標題為 pull_request_targets 的清單,其中包含符合候選分支的分支名稱或前置詞。 例如:
pull_request_targets:
- main
- release/*
- feature/*
在此設定中,會優先使用主要分支,但在適當時也會考慮以 release/ 或 feature/ 開頭的分支。 設定會在下列案例中套用:
- 提取要求建議:將分支推送至 Azure DevOps 之後,[存放庫] 頁面可能會建議從該分支建立提取要求,並動態選擇目標分支。
- 提取要求 URL:使用 sourceRef 參數直接流覽至提取要求建立頁面,但省略 targetRef 參數時,Azure DevOps 會根據此動態選擇選取目標分支。
建議只包含受提取要求原則保護的分支,以確保提示認可的第一個父代歷程記錄中的一致性。
在 markdown 文件中支持美人魚圖
包含美人魚語法的 Markdown 檔案現在會轉譯為存放庫檔案瀏覽器和提取要求中檔案預覽內的圖表。 這可協助您將更豐富的檔新增至存放庫。
在PR清單頁面上依標題搜尋提取要求
提取請求清單頁面現在包含依 PR 標題的篩選器,讓您更容易找到特定的提取請求。
Azure Repos 的疏鬆結帳
現在,YAML 簽出工作支援 git sparse-checkout 命令,以及 部分複製篩選器,以改善存放庫簽出效能。 您可以使用屬性 sparseCheckoutDirectories 和 sparseCheckoutPatterns。
設定 sparseCheckoutDirectories 會啟用錐體模式,其中簽出程式會使用目錄比對。 或者,您可以設定 sparseCheckoutPatterns,這會觸發非傳統圓錐模式,允許更複雜的模式比對。
如果設定這兩個屬性,代理程式就會使用目錄比對來初始化圓錐模式。 如果在檢出任務中未指定任何一個屬性,則會停用精簡檢出過程。 在命令執行期間遇到的任何問題都會導致簽出工作失敗。 稀疏檢出錐形模式的 YAML 範例:
checkout: repo
sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAMLCopy
checkout: repo
sparseCheckoutPatterns: /* !/img
這很重要
稀疏簽出功能需要代理程式 v3.248.0 (.NET 8 為 v4.248.0) 或更新版本。
您可以在 發布頁面上找到代理程式。
使跨存放庫政策區分大小寫
先前,跨存放庫政策的分支候選預覽是以不區分大小寫的方式顯示結果,儘管分支比對本身是區分大小寫的。 這種不一致造成了潛在的錯位,因為某些分支看起來似乎受到保護,但實際上並未受到保護。 為了解決此問題,我們已更新分支規則預覽,以符合策略應用的區分大小寫效能。
以前:
After:
TFVC 簽入原則變更
新版本 (19.254) 的 Microsoft.TeamFoundationServer.ExtendedClient NuGet 套件
NuGet Microsoft.TeamFoundationServer.ExtendedClient 套件已更新為新的 TFVC 原則類別和方法。
原則變更
我們正在變更在 Azure DevOps 中存儲 TFVC 簽入原則的方式,這也表示對 NuGet Microsoft.TeamFoundationServer.ExtendedClient 與服務通訊方式的更新。 如果您的 TFVC 專案使用簽入原則,請將這些原則移轉至新的格式。 有兩種方式可以執行這項作:
- 使用 Visual Studio。
警告
動作的危險特定後果:請確定您先將 Visual Studio 更新至最新版本,再繼續 (VS 2022、VS 2019 和 VS 2017 的最低版本 17.14 預覽版 3、17.13.6、17.12.7、17.10.13、17.8.20、16.11.46、15.9.72 支援新原則) 。
若要使用 Visual Studio 建立新原則,專案系統管理員應該開啟 [設定] -> [小組專案] -> 原始檔控制 -> [簽入原則],並使用與舊原則相同的參數新增原則 (沒有「已過時」標記):
- 如果您使用 Microsoft.TeamFoundationServer.ExtendedClient 的自訂實作來與伺服器通訊,請遵循 移轉指南。 需要移轉,才能讓 TFVC 簽入與未來的 Azure DevOps 版本相容。 目前,舊的(過時)和新的原則仍然有效且功能正常。 如需未來方案的資訊,請參閱我們的 部落格文章。
增強 GetRepository API 功能
我們已將 creationDate 屬性新增至 Repositories - Get Repository API 的回應,以傳回存放庫建立日期。 此屬性可在 API 7.2 預覽版和更新版本上使用。
增強 Pull Requests 查詢 API 功能
我們已在拉取請求查詢 - 取得 API 的回應中新增新的 Label 屬性。 您現在可以指定是否要在每次查詢中包含相關拉取請求的標籤。 新的 Include 屬性可供使用,如果設定為 [標籤],則回應會包含指定 PR 的標籤。 如果保留為 Null,則不會包含標籤。 若要防止發生非預期的錯誤,請確保不要明確指派 NotSet,否則會導致錯誤請求。
備註
標籤增強資源使用率取決於指派的標籤數量及其長度。 要求標籤可能會影響節流並增加網路負載。 若要將效能優化,建議您避免不必要的標籤要求。
請求負載範例
{
"queries": [
{
"type": "lastMergeCommit",
"include": "Labels",
"items": [
"0d6c9b2b524113113fced41aecbf8631a4649dec"
]
},
{
"type": "lastMergeCommit",
"items": [
"b524113113f0dd41aecbf8631a4649dec6c9b2ce"
]
}
]
}
Pipelines
TFX 會驗證任務是否使用生命週期結束節點執行器
工作作者使用 TFX 來發佈擴充功能。 TFX 已更新,可在其他節點執行器版本上執行驗證。
包含使用已達生命週期終點(EOL)的 Node.js 執行環境(從 Node 16 及之前的版本)的擴充功能將會看到此警告:
任務 < TaskName > 相依於即將停用且未來會被移除的任務執行程序。 作者應檢閱節點升級指引: https://aka.ms/node-runner-guidance
使用 Microsoft Entra ID 驗證從管線中存取 Azure 服務匯流排
您現在可以使用 Microsoft Entra ID 驗證,從 Azure Pipelines 存取 Azure 服務匯流排。 這可讓您利用 Azure RBAC 進行精細的存取控制。
存取 Azure 服務匯流排的身分識別必須在所存取的服務匯流排上授與 Azure 服務匯流排的其中一個 Azure 內建角色 。
PublishToAzureServiceBus@2 任務
您可以使用 Azure 服務連線來設定新的PublishToAzureServiceBus@2工作。 建立 Azure 服務連線 ,並填入新工作的 serviceBusQueueName 和 serviceBusNamespace 屬性:
- task: PublishToAzureServiceBus@2
inputs:
azureSubscription: my-azure-service-connection
serviceBusQueueName: my-service-bus-queue
serviceBusNamespace: my-service-bus-namespace
useDataContractSerializer: false
messageBody: |
{
"foo": "bar"
}
伺服器工作
使用 ServiceBus 執行的自訂伺服器 (無代理程式) 工作可以將 Azure 服務連線指定為 EndpointId,並省略 ConnectionString。 請參閱 伺服器工作編寫。
TFX 會驗證任務是否使用生命週期結束節點執行器
工作作者使用 TFX 來發佈擴充功能。 TFX 已更新,可在其他節點執行器版本上執行驗證。
包含使用已達生命週期終點(EOL)的 Node.js 執行環境(從 Node 16 及之前的版本)的擴充功能將會看到此警告:
任務 < TaskName > 相依於即將停用且未來會被移除的任務執行程序。 作者應檢閱節點升級指引: https://aka.ms/node-runner-guidance
使用生命週期結束節點執行器版本來執行發出警告的工作
依賴已停止支援的 Node.js 版本的管線任務將開始收到警告:任務 TaskName 的版本依賴於已停止支援的 Node.js 版本(10)。 請聯絡擴充功能擁有者以取得工作的更新版本。 工作維護者應檢閱節點升級指引: https://aka.ms/node-runner-guidance 若要隱藏這些警告,您可以在管線 (作業) 或工作層級設定環境或管線變數。 例如:
variables:
AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false
DockerCompose@0在 v1 相容性模式中使用 Docker Compose v2
Docker Compose v1 將達到其生命週期結束,並將於 2024 年 7 月 24 日從託管代理程式中移除。 我們已更新 DockerCompose@0 工作,如果代理程式上無法使用 Docker Compose v1,則會在 v1 相容模式下使用 Docker Compose v2。
然而,相容模式並不能解決所有相容性問題。 請參閱 移轉至 Compose V2。 某些使用者需要更多時間來更新其 Docker Compose 專案,以取得 Docker Compose v2 相容性。 在這些情況下,請遵循這些指示,將 DockerComposeV0 工作與 docker-compose v1 搭配使用。 注意:本指南是以安裝 Compose 獨立檔為基礎 在 Windows 上使用 docker-compose v1 將 powershell 步驟新增至管線,以下載 docker-Compose v1.29.2,並將其與 Windows 上的 DockerComposeV0 工作搭配使用:
variables:
dockerComposePath: C:\docker-compose
steps:
- powershell: |
mkdir -f $(dockerComposePath)
# GitHub now requires TLS1.2. In PowerShell, run the following
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: '**/docker-compose.yml'
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)\docker-compose.exe
Use docker-compose v1 on Linux
Add the bash step to your pipeline to download Docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Linux:
YAMLCopy
variables:
dockerComposePath: /tmp/docker-compose
steps:
- bash: |
sudo mkdir $(dockerComposePath)
sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
sudo chmod 755 $(dockerComposePath)/docker-compose
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)/docker-compose
Test Plans
Manifest V3 中的測試和意見反應延伸模組
我們很高興地宣佈 Chrome 和 Edge 的 Azure DevOps 測試和意見反應延伸模組的新更新。 此更新會將我們的實作從指令清單 V2 轉換為 V3,與 Google 的指令清單 V2 淘汰排程一致。 雖然延伸模組的核心功能保持不變,但更新可增強安全性和效能。
如需詳細資訊,請參閱我們最近關於此更新的部落格文章。 指令清單 V3 中的測試與意見反應延伸模組
Azure 測試執行器 1.2.2 版
Azure Test Plans 在 1.2.2 中針對 Test Plans 中最近發生的問題發行修正程式,其中 Azure Test Runner (ATR) 在 Chrome 130 版中遇到啟動失敗。 出現此問題的原因是 Chrome 增加了對非特殊方案 URL 的支持,這影響了 ATR 用戶流程。 透過此更新,迴歸錯誤已解決,並恢復了 ATR 功能。 有關此回歸錯誤的更多詳細信息,請訪問 Chromium 中的 此問題跟踪器 。
我們鼓勵您使用 Web 應用程式來增強功能。 如果您在 Web 應用程序中發現任何缺少的功能,我們很樂意聽取您的意見。 與我們分享您的反饋!
適用於測試案例執行的無縫建置管線整合
我們已藉由無縫整合組建管線組態來簡化測試案例執行程式。 在測試計劃層級設定的組建定義和標識元現在會自動傳播至 Web 執行器,而不需要每次手動設定。 這項改進可節省時間並提升效率,讓您專注於更關鍵的工作。
使用 REST API 還原已刪除的測試計劃和測試套件
使用新的自助式 API 輕鬆還原已刪除的測試計劃和測試套件。 我們正在引入 GET 和 PATCH API,可讓您查詢已刪除的測試計劃或套件,並將其連同其子項目一起還原,所有這些都不需要客戶支援。 透過這些 API,您可以快速復原意外刪除的測試工作項目,減少停機時間並提高生產力。 雖然不會還原執行成品,但所有相關的測試計劃、套件和測試案例都可以輕鬆地帶回您的工作區。 此自助服務功能可讓您更好地控制測試管理並簡化還原流程,從而更快、更有效率地恢復關鍵測試資產。
使用 XLSX 中的自訂數據行匯出測試案例
您現在可以在 XLSX 中匯出具有自訂列的測試案例。 根據您的意見反應,Test Plans 支援測試案例的匯出功能,並能自訂資料行,讓您更靈活地控制和分析所共用的資料。 此增強功能可協助您根據需求自訂匯出,確保您匯出的資訊相關且可操作。
Test Plans 目錄中的新排序功能
Test Plans 目錄現在提供增強的排序選項! 透過此更新,您可以按字母數字快速組織每列,從而提供一種簡化的方式來尋找和存取資料。
在 Web 和桌面執行器中復原測試步驟
使用新的「復原」選項掌控測試案例的運行。 您只需按兩下即可輕鬆還原測試步驟狀態,從而在測試運行期間為您提供更大的靈活性和控制力。 不再需要重新啟動測試案例來修復意外點擊,只需撤消操作然後繼續您的工作流程,即可不中斷地進行。
我們也引入了鍵盤友善的導航和輔助功能改進,以確保此功能對所有用戶無縫運行,包括依賴輔助技術的用戶。 此增強功能可協助您節省時間、減少挫折感,並專注於有效率地執行測試。
發佈程式碼涵蓋範圍結果 v2 工作改善
在此版本中,我們對 v2 工作進行了多項改進:
擴展了對各種程式碼涵蓋範圍格式的支援,包括:.coverage、.covx、.covb、.cjson、.xml、.lcov 和 pycov1。
產生完整的 cjson 檔案 (和程式碼涵蓋率報告),其中包含詳細的程式碼涵蓋率資訊,例如檔案名稱、涵蓋/未涵蓋的行等。
支援差異覆蓋率(PR 覆蓋率):v2 可以在同一管道中產生多種語言的差異覆蓋率 PR 註解。
v2 工作現在支援「建構品質檢查」工作,而這在 v1 工作中並不支援。
測試計劃中 YAML 管線的支援
除了傳統管線之外,您現在可以在設定 Test Plans 或從 Test Plans 執行自動化測試時使用 YAML 管線。
此要求是根據下列開發人員社群建議票證來排定優先順序。
報告
待辦工作項目中可用的彙總欄位資料
我們已更新彙總欄,以顯示最新的可用資料。 先前,這些資料行對於經常更新的工作專案可能顯示為空白,造成混淆。 您也會看到時間戳記,指出上次重新整理資料的時間。 雖然 Analytics 處理中出現一些延遲是正常的,但這些改進旨在在使用彙總欄時提供透明度和更流暢的體驗。
維基
改善將 HTML 內容貼入 Wikis
我們已更輕鬆地將 HTML 內容貼到 Wikis 中。 現在,鏈接、清單、數據表、影像、Excel 工作表、Microsoft Teams 訊息、電子郵件和 Azure 數據總管查詢等 HTML 元素會自動轉換成 Markdown 語法,以便更順暢地編輯。