Azure DevOps Server 2022 Update 1 版本資訊


| | 開發人員社群 System 需求和相容性 | 授權條款 | 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 2022 Update 1。 如果您的 TFS 部署位於 TFS 2013 或更早版本,則必須先執行一些過渡步驟,再升級至 Azure DevOps Server 2022。 如需詳細資訊,請參閱 安裝頁面


Azure DevOps Server 2022 Update 1 Patch 3 發行日期:2024 年 3 月 12 日

檔案 SHA-256 雜湊
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

我們已針對 Azure DevOps Server 2022 Update 1 發行修補程式 3,其中包含下列的修正程式。

  • 已解決 Proxy 伺服器在安裝 Patch 2 之後停止運作的問題。
  • 已修正延伸模組詳細數據頁面上影響非英文語言的轉譯問題。

Azure DevOps Server 2022 Update 1 Patch 2 發行日期:2024 年 2 月 13 日

檔案 SHA-256 雜湊
devops2022.1patch2.exe 59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

我們已針對 Azure DevOps Server 2022 Update 1 發行修補程式 2,其中包含下列專案的修正。

  • 修正搜尋延伸模組的詳細數據頁面轉譯問題。
  • 已修正 Proxy 快取資料夾使用的磁碟空間計算不正確且資料夾未正確清除的錯誤。
  • CVE-2024-20667:Azure DevOps Server 遠端程式代碼執行弱點。

Azure DevOps Server 2022 Update 1 Patch 1 發行日期:2023 年 12 月 12 日

檔案 SHA-256 雜湊
devops2022.1patch1.exe 9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

我們已針對 Azure DevOps Server 2022 Update 1 發行修補程式 1,其中包含下列專案的修正。

  • 防止在佇列管線執行時進行設定 requested for

Azure DevOps Server 2022 Update 1 發行日期:2023 年 11 月 28 日

注意

此版本有兩個已知問題:

  1. 升級至 Azure DevOps Server 2022.1 並使用代理程式集區組態中的更新代理程序之後,Agent 版本不會更新。 我們目前正在處理修補程式來解決此問題,並在進行進度時共用 開發人員社群 中的更新。 在此 開發人員社群 票證中,您可以找到此問題的因應措施。
  2. Maven 3.9.x 相容性。 Maven 3.9.x 引進了 Azure Artifacts 的重大變更,方法是將預設的 Maven 解析程式傳輸從 Wagon 更新為原生 HTTP。 這會導致使用 HTTP 而非 HTTPs 的客戶發生 401 驗證問題。 您可以 在這裡找到更多有關此問題的詳細數據。 因應措施是,您可以繼續使用 Maven 3.9.x 與 屬性 -Dmaven.resolver.transport=wagon。 這項變更會強制 Maven 使用 Wagon 解析程式傳輸。 如需詳細資訊,請參閱 這裡的 檔。

Azure DevOps Server 2022.1 是錯誤修正的匯總。 其中包含先前發行的 Azure DevOps Server 2022.1 RC2 中的所有功能。

注意

Maven 3.9.x 相容性有已知問題。 Maven 3.9.x 引進了 Azure Artifacts 的重大變更,方法是將預設的 Maven 解析程式傳輸從 Wagon 更新為原生 HTTP。 這會導致使用 HTTP 而非 HTTPs 的客戶發生 401 驗證問題。 您可以 在這裡找到更多有關此問題的詳細數據。

因應措施是,您可以繼續使用 Maven 3.9.x 與 屬性 -Dmaven.resolver.transport=wagon。 這項變更會強制 Maven 使用 Wagon 解析程式傳輸。 如需詳細資訊,請參閱 這裡的 檔。

Azure DevOps Server 2022 Update 1 RC2 發行日期:2023 年 10 月 31 日

Azure DevOps Server 2022.1 RC2 是錯誤修正的匯總。 其中包含先前發行的 Azure DevOps Server 2022.1 RC1 中的所有功能。

注意

Maven 3.9.x 相容性有已知問題。 Maven 3.9.x 引進了 Azure Artifacts 的重大變更,方法是將預設的 Maven 解析程式傳輸從 Wagon 更新為原生 HTTP。 這會導致使用 HTTP 而非 HTTPs 的客戶發生 401 驗證問題。 您可以 在這裡找到更多有關此問題的詳細數據。

因應措施是,您可以繼續使用 Maven 3.9.x 與 屬性 -Dmaven.resolver.transport=wagon。 這項變更會強制 Maven 使用 Wagon 解析程式傳輸。 如需詳細資訊,請參閱 這裡的 檔。

此版本已修正下列問題:

  • 已修正上游專案未解決顯示名稱變更的本機摘要中的問題。
  • 將索引標籤從 [程序代碼] 切換至 [搜尋] 頁面上的另一個索引卷標時,發生意外的錯誤。
  • 使用中文、日文和韓文 (CJK 建立新工作專案類型時發生錯誤,) 整合的 Ideographs。 當小組項目名稱或包含 CJK 的檔案時,原始記錄檔上會顯示問號。
  • 修正了在安裝搜尋期間,Java 虛擬機 (JVM) 無法配置足夠的記憶體給彈性搜尋程序的問題。 搜尋設定小工具現在會使用 Java 開發工具組 (搭配彈性搜尋的 JDK) ,因此會移除任何 Java 執行時間環境 (JRE) 預安裝在目標伺服器上的相依性。

Azure DevOps Server 2022 Update 1 RC1 發行日期:2023 年 9 月 19 日

Azure DevOps Server 2022.1 RC1 包含許多新功能。 一些重點包括:

您也可以跳到個別區段,以查看每個服務的新功能:


一般

所有公用 REST API 都支援細微的 PAT 範圍

先前,許多公開記載的 Azure DevOps REST API 並未與範圍相關聯 (例如工作專案讀取) ,讓使用完整範圍的客戶透過非互動式驗證機制取用這些 API,例如個人存取令牌 (PAT) 。 使用完整範圍的個人存取令牌可提高他們落在惡意使用者手上的風險。 這是許多客戶未充分利用 控制平面原則 以限制 PAT 使用方式和行為的主要原因之一。

現在,所有公用 Azure DevOps REST API 現在都會與 相關聯,並支援細微的 PAT 範圍。 如果您目前使用完整範圍的 PAT 向其中一個公用 Azure DevOps REST API 進行驗證,請考慮移轉至具有 API 所接受特定範圍的 PAT,以避免不必要的存取。 您可以在 檔案頁面的安全性一節中找到所支援細微的 PAT 範圍 (指定 REST API 的) 。 此外, 這裡還有一個範圍數據表。

延伸模組應該會顯示其範圍

將擴充功能安裝至 Azure DevOps 集合時,您可以檢閱擴充功能在安裝過程中所需的許可權。 不過,安裝后,擴充功能許可權就不會顯示在擴充功能設定中。 這對於需要定期檢閱已安裝延伸模組的系統管理員造成挑戰。 現在,我們已將擴充功能許可權新增至延伸模塊設定,以協助您檢閱並做出有關是否要保留這些許可權的明智決策。

建立個人存取令牌以部署至 Marketplace

Boards

[傳遞方案] 頁面上的 [上次存取] 資料行

[傳遞計劃] 目錄頁面提供為您的專案定義的計劃清單。 您可以依:名稱、建立者、描述、上次設定或我的最愛排序。 透過此更新,我們已將 [上次存取的數據行] 新增至目錄頁面。 這可讓您查看上次開啟並查看傳遞計劃的時間。 因此,很容易識別不再使用且可以刪除的計劃。

Gif 以示範 [傳遞方案] 頁面上的 [上次存取] 字段。

可視化傳遞計劃的所有相依性

傳遞計劃一律能夠查看工作項目之間的相依性。 您可以將相依性行可視化,逐一可視化。 在此版本中,我們可讓您在畫面上查看所有工作專案的所有相依性行,藉此改善體驗。 只要按下傳遞計劃右上方的 [相依性] 切換按鈕即可。 再次按下以關閉這幾行。

Gif 示範以可視化方式呈現 [傳遞方案] 頁面上的所有相依性。

新的工作專案修訂限制

在過去數年,我們已看到具有自動化工具的專案集合會產生數千個工作項目修訂。 這會在工作項目表單和報告 REST API 上建立效能和可用性的問題。 為了減輕此問題,我們已對 Azure DevOps Service 實作 10,000 個工作專案修訂限制。 限制只會影響使用 REST API 的更新,而不是工作項目表單。

按兩下這裡 以深入瞭解修訂限制,以及如何在自動化工具中處理。

將傳遞計劃小組限制從15增加到20

傳遞計劃可讓您檢視專案集合中的多個待辦專案和多個小組。 先前,您可以檢視 15 個小組待辦專案,包括來自不同項目的積存專案和小組混合。 在此版本中,我們會將上限從15增加到20。

我們已修正報告工作項目連結取得 API 中的錯誤,以傳回連結類型的正確 remoteUrl 值 System.LinkTypes.Remote.Related 。 在此修正之前,我們傳回了錯誤的專案集合名稱和遺漏的專案標識碼。

建立暫存查詢 REST 端點

我們已看到數個擴充作者實例嘗試透過查詢字串傳遞工作專案查詢語言 (WIQL) 語句來執行未儲存的查詢。 除非您有達到查詢字串長度的瀏覽器限制的大型WIQL語句,否則這可以正常運作。 為了解決此問題,我們已建立新的 REST 端點,以允許工具作者產生暫存查詢。 使用來自回應的標識碼透過querystring傳遞,可消除此問題。

如需詳細資訊,請參閱 暫存查詢 REST API 文件頁面

批次刪除 API

目前,從回收站移除工作專案的唯一方式是使用此 REST API 一次刪除一個。 這可以是緩慢的程式,而且在嘗試進行任何類型的大量清除時,會受限於速率限制。 為了回應,我們已新增 REST API 端點,以批次刪除和/或終結工作專案。

@CurrentIteration 傳遞計劃中的宏

透過此更新,我們已新增傳遞計畫中樣式宏的支援 @CurrentIteration 。 此宏可讓您從方案中每個數據列的小組內容取得目前的反覆專案。

Gif 以示範 Delivery Plans 中的 CurrentIteration 宏。

傳遞計劃中的卡片重設大小邏輯

並非所有人都會在追蹤功能和 Epic 時使用目標日期和/或開始日期。 有些選擇使用日期和反覆專案路徑的組合。 在此版本中,我們會根據使用的反覆專案路徑和日期欄位組合,改善邏輯來適當地設定反覆項目路徑和日期字段組合。

例如,如果未使用目標日期,而且您調整卡片大小,則會設定新的反覆項目路徑,而不是更新目標日期。

要示範的 Gif 複製批注連結。

批次更新改善

我們對工作專案批次更新 API 的 7.1 版進行了數項變更。 這些包括次要效能改善和部分失敗的處理。 這表示,如果一個修補程序失敗,但其他修補程式未失敗,則其他修補程式將會順利完成。

按兩下這裡 以深入瞭解批次更新 REST API。

批次刪除 API

此新的 REST API 端點可刪除和/或終結批次中的工作專案現已公開推出。 請按一下這裡深入了解。

防止編輯可共享選擇清單欄位

自定義欄位會跨進程共用。 這可能會為挑選清單欄位建立問題,因為我們允許進程管理員從欄位中新增或移除值。 這麼做時,變更會影響每個進程上的該欄位。

為了解決此問題,我們新增了集合管理員無法編輯欄位的能力。 鎖定挑選清單欄位時,本機進程管理員無法變更該挑選清單的值。 他們只能從進程新增或移除欄位。

Gif 示範可共享選擇清單欄位的編輯。

新的儲存批注許可權

僅儲存工作專案批注的能力是 開發人員社群中的最上層要求。 我們很高興讓您知道我們已實作這項功能。 首先,讓我們檢閱最常見的案例:

「我想要防止某些用戶編輯工作專案字段,但允許他們參與討論。」

若要完成這項作業,您必須移至 [項目設定 > ] [專案組態 > 區域路徑]。 然後選取所選的區域路徑,然後按兩下 [安全性]。

區域路徑

請注意新的許可權 「在此節點中編輯工作專案批注」。 根據預設,許可權會設定為 [未設定]。 也就是說,工作項目的行為與之前的行為完全相同。 若要允許群組或使用者儲存批注,請選取該群組/使用者,並將許可權變更為 [允許]。

新增許可權

當使用者在此區域路徑中開啟工作項目表單時,他們將能夠新增批注,但無法更新任何其他欄位。

示範可共享選擇清單欄位的編輯。

我們希望您喜歡這項功能,就像我們一樣多。 一如往常,如果您有任何意見反應或建議, 請讓我們知道

互動式面板報表

位於 Boards 中樞的互動式報表,已在我們裝載的產品版本中存取數年。 它們會取代較舊的累計流程圖、速度及短期衝刺待用圖表。 在此版本中,我們將提供它們。

若要檢視這些圖表,請按兩下 Kanban 面板、待辦專案和短期衝刺頁面上的 [分析 ] 索引標籤位置。

互動式報表

Repos

拿掉分支建立者的「編輯原則」許可權

之前,當您建立新的分支時,我們獲授與編輯該分支原則的許可權。 透過 此更新,我們會將預設行為變更為不授與此權限,即使存放庫的 [權限管理] 設定已開啟也一樣。

許可權管理映像。

您必須透過安全性權限繼承或群組成員資格,手動或透過 REST API 明確授與「編輯原則」權限。

Pipelines

目前專案集為傳統管線中建置存取令牌的預設範圍

Azure Pipelines 會在運行時間使用作業存取令牌來存取 Azure DevOps 中的其他資源。 作業存取令牌是 Azure Pipelines 在運行時間針對每個作業動態產生的安全性令牌。 先前,在建立新的傳統管線時,存取令牌的預設值已設定為 Project Collection。 透過此更新,我們會在建立新的傳統管線時,將作業授權範圍設定為 目前的專案 作為預設值。

您可以在 存取存放庫、成品和其他資源檔中,找到更多有關作業存取令牌的詳細數據。

變更傳統組建管線中存取令牌的預設範圍

為了改善傳統組建管線的安全性,建立新的管線時, 建置作業授權範圍 預設會是 Project。 到目前為止,它用來做為 專案集合。 深入瞭解 作業存取令牌。 這項變更不會影響任何現有的管線。 它只會影響您從這一點建立的新傳統組建管線。

Azure Pipelines 支援 San、東京 & Utah 版本 ServiceNow

Azure Pipelines 有與 ServiceNow 的現有整合。 整合依賴 ServiceNow 中的應用程式,以及 Azure DevOps 中的擴充功能。 我們現在已更新應用程式,以使用「東京」& Utah 版本的 ServiceNow。 若要確保這項整合能夠運作,請從 ServiceNow 存放區升級至新版本的應用程式 (4.215.2) 。

如需詳細資訊,請參閱 與 ServiceNow 變更管理整合檔

使用 Proxy URL 進行 GitHub Enterprise 整合

Azure Pipelines 與內部部署 GitHub Enterprise Server 整合,以執行持續整合和 PR 組建。 在某些情況下,GitHub Enterprise Server 位於防火牆後方,而且需要透過 Proxy 伺服器路由傳送流量。 為了支援此案例,Azure DevOps 中的 GitHub Enterprise Server 服務連線可讓您設定 Proxy URL。 之前,並非所有來自 Azure DevOps 的流量都會透過此 Proxy URL 路由傳送。 透過此更新,我們會確保從 Azure Pipelines 路由傳送下列流量,以通過 Proxy URL:

  • 取得分支
  • 取得提取要求資訊
  • 報表組建狀態

Container Registry 服務連線現在可以使用 Azure 受控識別

您可以在建立適用於 Azure Container Registry 的 Docker 登錄服務連線時,使用系統指派的受控識別。 這可讓您使用與自我裝載 Azure Pipelines 代理程式相關聯的受控識別來存取 Azure Container Registry,而不需要管理認證。

變更核准的新 Docker 登錄服務連線

注意

用來存取 Azure Container Registry 的受控識別需要適當的 Azure 角色型 存取控制 (RBAC) 指派,例如 AcrPull 或 AcrPush 角色。

針對 Kubernetes Service 連線建立的自動令牌

由於 Kubernetes 1.24,建立新的 Kubernetes Service 連線時,不會再自動建立令牌。 我們已將這項功能加回。 不過,建議您在存取 AKS 時使用 Azure 服務連線,若要深入瞭解,請參閱 使用 Kubernetes 工作之 AKS 客戶的服務連線指引部落格文章

Kubernetes 工作現在支援 kubelogin

我們已更新 KuberentesManifest@1HelmDeploy@0Kubernetes@1AzureFunctionOnKubernetes@1 工作以支援 kubelogin。 這可讓您將目標 Azure Kubernetes Service (AKS) 設定 Azure Active Directory 整合

裝載 映像上未預安裝 Kubelogin。 若要確定上述工作使用 kubelogin,請在相依的工作之前插入 KubeloginInstaller@0 工作來安裝它:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

管線許可權的體驗改善

我們已改善管理管線許可權的體驗,讓許可權系統記住管線先前是否使用受保護的資源,例如服務連線。

在過去,如果您在建立受保護的資源時核取了「授與所有管線的訪問許可權」,但之後您限制資源的存取權,您的管線需要新的授權才能使用資源。 此行為與後續對資源的開啟和關閉存取不一致,因為不需要新的授權。 現在已修正此問題。

用於管理管線授權和核准和檢查的新 PAT 範圍

為了限制透過流失 PAT 令牌所完成的損害,我們新增了名為 Pipeline Resources的新 PAT 範圍。 您可以使用 受保護的資源管理管線授權時使用此 PAT 範圍,例如服務連線,或管理 該資源的核准和檢查

管線 REST API 匯報

下列 REST API 呼叫支援新的 PAT 範圍,如下所示:

限制對資源管理員開啟受保護的資源

為了改善您安全地建置和部署應用程式的能力所需的資源安全性,Azure Pipelines 現在需要資源類型系統管理員角色,才能開啟對所有管線的資源存取權。

例如,需要一般服務 Connections 系統管理員角色,才能允許任何管線使用服務連線。 建立受保護的資源或編輯其安全性設定時,適用這項限制。

此外,在建立服務連線且您沒有足夠的許可權時,會停用 [授與所有管線的訪問許可權 ] 選項。

服務 Connections 此外,當您嘗試開啟現有資源的存取權,而且您沒有足夠的許可權時,您會收到您未獲授權來開啟此資源訊息的存取權。

管線許可權

管線 REST API 安全性改善

Azure DevOps 中的大部分 REST API 都使用限定範圍的 PAT 令牌。 不過,其中有些則需要完整範圍的 PAT 令牌。 換句話說,您必須選取 [完整存取權] 來建立 PAT 令牌,才能使用其中一些 API。 這類令牌會造成安全性風險,因為它們可以用來呼叫任何 REST API。 我們已改善 Azure DevOps,藉由將每個 REST API 併入特定範圍,來移除完整範圍令牌的需求。 在這項工作中, 更新資源的管線許可權的 REST API 現在需要特定範圍。 範圍取決於授權使用的資源類型:

  • Code (read, write, and manage) 針對類型的資源 repository
  • Agent Pools (read, manage)或類型為和 Environment (read, manage) 的資源queueagentpool
  • Secure Files (read, create, and manage) 針對類型的資源 securefile
  • Variable Groups (read, create and manage) 針對類型的資源 variablegroup
  • Service Endpoints (read, query and manage) 針對類型的資源 endpoint
  • Environment (read, manage) 針對類型的資源 environment

若要大量編輯管線許可權,您仍然需要完整範圍的 PAT 令牌。 若要深入瞭解如何更新資源的管線許可權,請參閱 管線許可權 - 更新資源的管線許可權 檔。

代理程式集區的細微存取管理

代理程式集區可讓您指定和管理管線執行所在的機器。

先前,如果您使用自定義代理程式集區,則管理哪些管線可以存取它已粗略。 您可以允許所有管線使用它,或要求每個管線要求許可權。 不幸的是,一旦您將管線訪問許可權授與代理程式集區,您便無法使用管線 UI 來撤銷它。

Azure Pipelines 現在為代理程式集區提供更細緻的存取管理。 此體驗類似於管理服務 Connections 管線許可權的體驗。

FabrikamFiber 代理程式集區,以變更核准

防止授與所有管線對受保護資源的存取權

當您建立受保護的資源,例如服務連線或環境時,您可以選擇選取 [ 授與所有管線的訪問許可權 ] 複選框。 到目前為止,預設會核取此選項。

雖然這讓管線更容易使用新的受保護資源,但相反地,它偏好不小心授與太多管線來存取資源的許可權。

若要依默認升級安全選擇,Azure DevOps 現在會取消勾選複選框。

默認會關閉授與所有管線的訪問許可權

停用簡短秘密遮罩的能力

Azure Pipelines 會遮罩記錄中的秘密。 秘密可以是標示為秘密的變數、連結至 Azure 金鑰保存庫 之變數群組的變數,或由服務提供商標示為秘密的服務連線元素。

所有出現的秘密值都會遮罩。 遮罩簡短秘密,例如 '1'、'2'、'Dev' 可讓您輕鬆地猜測其值,例如在日期中: 'Jan 3, 202***'
現在3,'' 是秘密。 在這種情況下,您可能不想完全遮罩秘密。 如果無法將值標示為秘密 (例如值取自 金鑰保存庫) ,您可以將 knob 設定AZP_IGNORE_SECRETS_SHORTER_THAN為最多 4 的值。

節點執行器下載工作

採用 排除 Node 6 工作執行器的代理程式版本 時,您可能偶爾需要執行尚未更新的工作,才能使用較新的節點執行器。 在此案例中,我們提供一種方法來繼續使用相依於節點生命週期結束執行器的工作,請參閱節點執行器指引 部落格文章

下列工作是安裝 Node 6 執行器 Just-In-Time 的方法,因此舊工作仍然可以執行:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

已更新 TFX 節點執行器驗證

工作作者 會使用延伸模組封裝工具 (TFX) 來發佈延伸模組。 TFX 已更新為在節點執行器版本上執行驗證,請參閱節點執行器指引 部落格文章

使用 Node 6 執行器包含工作的延伸模組會看到下列警告:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

在管線代理程式上手動預安裝 Node 6 的指示

如果您使用 pipeline- 代理程式摘要,則代理程式中未包含 Node 6。 在某些情況下,Marketplace 工作仍會依賴 Node 6,且代理程式無法使用 NodeTaskRunnerInstaller 工作 (例如,因為連線限制),您必須獨立預先安裝 Node 6。 若要達成此目的,請參閱如何手動安裝 Node 6 執行器的 指示

管線工作變更記錄

我們現在會將對管線工作的變更發佈至此 變更記錄 中。 這包含對 內建管線工作 所做的完整變更清單。 我們已回溯發佈先前的變更,因此變更記錄會提供工作更新的歷程記錄。

發行工作使用 Microsoft 圖形 API

我們已更新發行工作以使用 Microsoft 圖形 API。 這會從工作中移除 AAD 圖形 API 的使用方式。

Windows PowerShell 工作效能改善

您可以使用工作在管線中定義自動化。 其中一項工作是 PowerShell@2 公用程式工作,可讓您在管線中執行 PowerShell 腳本。 若要使用 PowerShell 腳本以 Azure 環境為目標,您可以使用工作 AzurePowerShell@5 。 某些可以列印進度更新的PowerShell命令,例如 Invoke-WebRequest,現在執行速度會更快。 如果您的腳本中有許多這些命令,或長時間執行,則改善會更加重要。 透過此更新,progressPreferenceAzurePowerShell@5 工作的 PowerShell@2 屬性現在預設會設定為 SilentlyContinue

.NET 6 上的 Pipelines Agent v3

管線代理程式已升級為使用 .NET 3.1 Core 至 .NET 6 作為運行時間。 這引進了 Apple Silicon 和 Windows Arm64 的原生支援。

使用 .NET 6 會影響代理程序的系統需求。 具體而言,我們卸除下列操作系統的支援:CentOS 6、Fedora 29-33、Linux Mint 17-18、Red Hat Enterprise Linux 6。 請參閱 Agent 軟體第 3 版的檔。

腳本 可用來識別使用代理程式與不支援作業系統的管線。

重要

請注意,在我們推出以 .NET 6 為基礎的代理程序之後,上述任何操作系統上執行的代理程式將不再更新或失敗。

在代理程式 VM 擴充功能中指定代理程式版本

Azure VM 可以使用 VM 擴充功能包含在部署群組中。 VM 擴充功能已更新為選擇性地指定要安裝的代理程式版本:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

用來控制傳統管線建立的新切換

Azure DevOps 現在可讓您藉由停用建立傳統組建管線、傳統發行管線、工作組和部署群組,以確保您的專案集合只使用 YAML 管線。 您現有的傳統管線將會繼續執行,而且您將能夠編輯它們,但您將無法建立新的管線。

Azure DevOps 現在可讓您藉由停用傳統組建管線、傳統發行管線、工作組和部署群組的建立,確保組織只使用 YAML 管線。 您現有的傳統管線將會繼續執行,而且您將能夠編輯它們,但您將無法建立新的管線。

您可以開啟對應的切換,以停用在專案集合層級或專案層級建立傳統管線。 您可以在 [專案/ 項目設定 - 管線 -> 設定]> 中找到切換。 有兩個切換:一個用於傳統 組建 管線,另一個用於傳統 發行 管線、部署群組和工作組。

停用傳統管線的建立

切換狀態預設為關閉,您需要系統管理員許可權才能變更狀態。 如果切換是在組織層級開啟,則會對所有項目強制執行停用。 否則,每個專案都可以自由選擇是否要強制執行停用。

強制執行停用傳統管線的建立時,與建立傳統管線、工作組和部署群組相關的 REST API 將會失敗。 建立 YAML 管線的 REST API 將會運作。

匯報「執行階段狀態已變更」服務攔截事件

服務勾點可讓您在 Azure DevOps 中的項目中發生事件時,在其他服務上執行工作, 執行階段狀態已變更 為下列其中一個事件。 執行階段狀態變更事件必須包含有關執行的資訊,包括管線的名稱。 之前,它只會包含有關執行標識碼和名稱的資訊。 透過此更新,我們對事件進行了變更,以包含遺漏的資訊。

停用顯示管線執行的最後一個認可訊息

先前,當顯示管線的執行時,用來顯示最後一個認可訊息的 Pipelines UI。

上次認可訊息的範例

例如,當您的 YAML 管線程式代碼位於與保存其所建置程式代碼不同的存放庫中時,此訊息可能會令人困惑。 我們從 開發人員社群 收到您的意見反應,要求我們啟用/停用將最新的認可訊息附加至每個管線執行的標題。

透過此更新,我們新增了名為 appendCommitMessageToRunName的新 YAML 屬性,可讓您確實這麼做。 根據預設,屬性會設定為 true。 當您會設定為 false時,管線執行只會顯示 BuildNumber

具有組建編號的管線執行範例

使用最後一個認可訊息執行管線的範例

增加 Azure Pipeline 限制,使其符合 Azure Resource Manager (ARM) 範本大小上限 4 MB。

您可以使用 Azure Resource Manager 樣本部署工作來建立 Azure 基礎結構。 為了回應您的意見反應,我們已將 Azure Pipelines 整合限制增加到 2 MB 到 4 MB。 這會配合整合大型範本期間,ARM 範本 的大小上限為 4 MB 解析大小限制。

管線執行狀態概觀圖示

在此版本中,我們可讓您更輕鬆地瞭解管線執行的整體狀態。

對於具有許多階段的 YAML 管線,很難知道管線執行的狀態,也就是說,它仍在執行中或已完成。 如果完成,則為整體狀態:成功、失敗或已取消。 我們已修正此問題,方法是新增執行狀態概觀圖示。

管線執行狀態概觀圖示

管線階段側邊面板

YAML 管線可以有數十個階段,並非所有階段都適合您的畫面。 雖然管線執行概觀圖示告訴您執行的整體狀態,但還是很難知道哪個階段失敗,或哪個階段仍在執行,例如。

在此版本中,我們新增了管線階段側邊面板,可讓您快速查看所有階段的狀態。 接著,您可以按兩下階段並直接進入其記錄。

更新管線

管線 UI 更新

在側邊面板中搜尋階段

我們已讓您更輕鬆地在階段側邊面板中尋找您要尋找的階段。 您現在可以根據階段的狀態快速篩選階段,例如執行階段或需要手動介入的階段。 您也可以依其名稱搜尋階段。

更新 AZ Pipelines

暫存快速動作

管線的 [ 執行 ] 畫面可讓您快速存取所有執行階段。 在此版本中,我們新增了階段面板,您可以從中為每個階段執行動作。 例如,您可以輕鬆地重新執行失敗的工作,或重新執行整個階段。 當並非所有階段都符合使用者介面時,可以使用面板,如下列螢幕快照所示。

管線有太多階段的螢幕快照。 當您在 [階段] 資料行中按兩下 [+] 登入時,階段面板隨即顯示,然後您可以執行階段動作。

階段面板的螢幕快照。

檢查用戶體驗改善

我們正在讓讀取檢查記錄更容易。 檢查記錄會提供部署成功的關鍵資訊。 他們可以告訴您您是否忘記關閉工作專案票證,或您需要在 ServiceNow 中更新票證。 先前,知道提供這類重要資訊的檢查很困難。

現在,管線執行詳細數據頁面會顯示最新的檢查記錄。 這僅適用於遵循建議使用方式的檢查。

顯示最新檢查記錄的影像。為了防止錯誤核准的核准,Azure DevOps 會在管線執行的詳細數據頁面中顯示核准者的指示,並檢查側邊面板。

等候管線檢閱影像。

停用檢查

我們已讓偵錯檢查變得較不繁瑣。 有時候,叫用 Azure 函式或叫用 REST API 檢查無法正常運作,而且您需要修正它。 之前,您必須刪除這類檢查,以防止它們錯誤地封鎖部署。 修正檢查之後,您必須將它新增回並正確設定,確定已設定所有必要的標頭,或查詢參數正確無誤。 這很繁瑣。

現在,您可以只停用檢查。 停用的檢查不會在後續的檢查套件評估中執行。

停用檢查影像。 修正錯誤檢查之後,您只要啟用它即可。

啟用檢查影像。

管線執行 Rest API 中的已耗用資源和範本參數

擴充 管線執行 REST API 現在會傳回管線執行所使用的更多成品類型,以及用來觸發該執行的參數。 我們已增強 API,以傳回 container 管線執行中使用的 和 pipeline 資源和範本參數。 例如,您現在可以撰寫合規性檢查,以評估管線所使用的存放庫、容器和其他管線執行。

以下是新回應本文的範例。

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

YAML 編輯器中的一般可用性範本支援

範本 是 YAML 管線中常用的功能。 它們是共用管線代碼段的簡單方式。 它們也是透過管線驗證或強制執行 安全性和治理 的強大機制。

Azure Pipelines 支援 YAML 編輯器,在編輯管線時可能會很有説明。 不過,編輯器目前不支援範本。 使用範本時,YAML 管線的作者無法透過 Intellisense 取得協助。 範本作者無法使用YAML編輯器。 在此版本中,我們會在 YAML 編輯器中新增範本的支援。

當您編輯主要 Azure Pipelines YAML 檔案時,您可以 包含擴充 範本。 當您輸入範本的名稱時,系統會提示您驗證範本。 驗證之後,YAML 編輯器會了解範本的架構,包括輸入參數。

管線 REST API 匯報

驗證后,您可以選擇瀏覽至範本。 您將能夠使用 YAML 編輯器的所有功能,對範本進行變更。

已知有一個限制:

  • 如果範本有未在主要 YAML 檔案中作為輸入提供的必要參數,則驗證會失敗,並提示您提供這些輸入。 在理想的體驗中,應該不會封鎖驗證,而且您應該能夠使用 Intellisense 填入輸入參數。
  • 您無法從編輯器建立新的範本。 您只能使用或編輯現有的範本。

新的預先定義系統變數

我們引進了名為 Build.DefinitionFolderPath的新預先定義系統變數,其值是組建管線定義的資料夾路徑。 變數可在 YAML 和傳統組建管線中使用。

例如,如果您的管線位於 Azure Pipelines 中的資料夾底下 FabrikamFiber\Chat ,則的值 Build.DefinitionFolderPath 會是 FabrikamFiber\Chat

在 YAML 範本運算式中新增字串分割函式的支援

YAML 管線可讓您方便減少程式碼重複的方式,例如 迴圈查看 each 物件清單 或屬性的值。

有時候,要逐一查看的專案集會以字串表示。 例如,當要部署的環境清單是由字串 integration1, integration2所定義時。

當我們從 開發人員社群 聆聽您的意見反應時,我們聽到您想要 YAML 範本運算式中的字串split函式。

現在,您可以 split 字串並逐一查看 each 其子字串。

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

存放庫資源定義的範本運算式

我們已在 YAML 管線中定義 ref 資源的 屬性 repository 時,新增範本運算式的支援。 這是我們的 開發人員社群 高度要求的功能

當您想要讓管線簽出相同存放庫資源的不同分支時,有一個使用案例。

例如,假設您有一個管線可建置自己的存放庫,因此需要從資源存放庫取出連結庫。 此外,假設您想要讓管線簽出與本身所使用的相同連結庫分支。 例如,如果您的管線在 main 分支上執行,它應該取出 main 鏈接庫存放庫的分支。 如果管線在分支上 dev 執行,它應該會簽出連結 dev 庫分支。

到目前為止,您必須明確指定分支來簽出,並在分支變更時變更管線程序代碼。

現在,您可以使用範本運算式來選擇存放庫資源的分支。 請參閱下列 YAML 程式代碼範例,以用於管線的非主要分支:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

當您執行管線時,您可以指定要簽出存放庫的 library 分支。

指定要在組建佇列時間擴充的範本版本

範本 代表減少程式代碼重複 改善管線安全性的絕佳方式。

其中一個熱門的使用案例是將範本儲存在自己的存放庫中。 這樣可減少範本與擴充範本與管線之間的結合,並讓您更輕鬆地獨立發展範本和管線。

請考慮下列範例,其中範本用來監視步驟清單的執行。 範本程式代碼位於存放 Templates 庫中。

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

假設您有一個擴充此樣本的 YAML 管線,位於存放庫 FabrikamFiber。 目前為止,您無法在使用存放庫作為範本來源時動態指定 ref 存放庫資源的 屬性 templates 。 這表示如果您想要讓管線變更管線的程式代碼:從不同的分支擴充範本,請從與管線相同的分支名稱擴充範本,而不論您執行管線的分支為何

透過在存放庫資源定義中引進範本運算式,您可以撰寫管線,如下所示:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

如此一來,您的管線會擴充與管線執行所在分支相同的分支中的範本,因此您可以確定管線和範本的分支一律相符。 也就是說,如果您在分支dev上執行管線,它會擴充存放庫分支templatesdev檔案所template.yml指定的範本。

或者,您可以撰寫下列 YAML 程式代碼,在組建佇列時間選擇要使用的範本存放庫分支。

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

現在,您可以在分支上讓管線在分支main上從分支擴充一個執行中的範本,並從另一個執行中的分支devmain擴充範本,而不需變更管線的程序代碼。

指定存放庫資源屬性的範本運算式 ref 時,您可以使用 parameters 和系統預先定義的變數,但無法使用 YAML 或 Pipelines UI 定義的變數。

容器資源定義中的範本表示式

我們已在 YAML 管線中定義endpoint資源的、 volumesportsoptions 屬性container時,新增範本運算式的支援。 這是我們的 開發人員社群 高度要求的功能

現在,您可以撰寫 YAML 管線,如下所示。

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

您可以在樣本表示式中使用 parameters.variables. 。 針對變數,您只能使用 YAML 檔案中定義的變數,但不能使用 Pipelines UI 中定義的變數。 例如,如果您重新定義變數,則使用代理程式記錄命令不會有任何作用。

排程的組建改善

我們已修正導致管線的排程資訊損毀,且管線無法載入的問題。 例如,當分支的名稱超過特定數目的字元時,就會造成此情況。

改善無法載入管線時的錯誤訊息

Azure Pipelines 提供數種類型的觸發程式來設定管線的啟動方式。 執行管線的其中一種方式是使用排程的觸發程式。 有時候,管線的排程執行資訊會損毀,而且可能會導致負載失敗。 先前,我們顯示誤導的錯誤訊息,指出找不到管線。 透過此更新,我們已解決此問題,並傳回資訊性錯誤訊息。 接下來,您會收到類似下列的訊息:如果管線無法載入 ,組建排程數據就會損毀

擷取 Git 存放庫時不要同步標記

簽出工作會使用--tags擷取 Git 存放庫內容的選項。 這會導致伺服器擷取所有標籤,以及這些標記所指向的所有物件。 這會增加在管線中執行工作的時間,特別是如果您有具有許多卷標的大型存放庫。 此外,即使啟用淺層擷取選項,簽出工作也會同步標記,因而可能會破壞其用途。 為了減少從 Git 存放庫擷取或提取的數據量,我們現在已將新選項新增至工作,以控制同步標記的行為。 此選項可在傳統和 YAML 管線中使用。

此行為可以從 YAML 檔案或 UI 來控制。

若要退出退出透過 YAML 檔案同步標記,請將 新增 fetchTags: false 至簽出步驟。 fetchTags未指定選項時,會與fetchTags: true使用 的選項相同。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

如果您想要變更現有 YAML 管線的行為,在 UI 中設定此選項可能會比較方便,而不是更新 YAML 檔案。 若要流覽至 UI,請開啟管線的 YAML 編輯器,選取 [觸發程式],然後選取 [處理],然後開啟 [簽出] 步驟。

如果您在 YAML 檔案和 UI 中指定此設定,則 YAML 檔案中指定的值優先。

針對您建立的所有新管線 (YAML 或傳統) ,預設仍會同步標記。 此選項不會變更現有管線的行為。 除非您明確變更上述選項,否則這些管線中的標記仍會同步處理。

Artifacts

已更新預設摘要許可權

建立新的專案集合範圍的 Azure Artifacts 摘要時,專案集合建置服務帳戶現在預設會有共同作業 者角色, 而不是目前的 參與者 角色。

先前,如果您有摘要的複本,您可能會看到上游套件。 問題在於您無法搜尋上游中可用的套件,而且尚未儲存在摘要中。 現在,您可以使用新的摘要使用者介面來搜尋可用的上游套件。

Azure Artifacts 現在提供使用者介面,可讓您在上游來源中搜尋套件,並將套件版本儲存到摘要中。 這與 Microsoft 的目標一致,以改善產品和服務。

報表

在查詢結果小工具中顯示父項

查詢結果小工具現在支援父系的名稱,以及該父系的直接連結。

建立個人存取令牌以部署至 Marketplace

複製儀表板

在此版本中,我們包括 複製儀錶板

具有複製儀錶板的影像

儀錶板上次存取日期和修改者

允許小組建立數個儀錶板的其中一項挑戰,就是管理和清除過期和未使用的儀錶板。 瞭解上次流覽或修改儀錶板的時間是瞭解哪些儀錶板可以移除的重要部分。 在此版本中,我們已在 [儀錶板目錄] 頁面中包含兩個新的數據行。 上次存取的日期 會追蹤儀錶板最近瀏覽的時間。 修改 者 追蹤 儀錶板上次編輯的時間和作者。

[修改者] 資訊也會顯示在儀錶板頁面本身。

儀錶板預覽

我們希望這些新欄位可協助專案管理員了解儀錶板的活動層級,以便在應移除時做出教育決策。

分析檢視現已推出

分析檢視功能已在我們裝載的產品版本中長時間處於預覽狀態。 在此版本中,我們很高興宣佈此功能現在可供所有專案集合使用。

在導覽中, 分析檢視 會從 [ 概觀 ] 索引卷標移至 [ 面板 ] 索引卷標。

面板導覽中的分析檢視。

分析檢視提供簡化的方式,可根據分析數據指定Power BI報表的篩選準則。 如果您不熟悉 分析檢視,以下是一些讓您趕上的檔:

多個存放庫的提取要求小工具現已推出

我們很高興宣佈多個存放庫的提取要求小工具可在 2022.1 Azure DevOps Server 取得。 透過這個新的小工具,您可以在單一簡化的清單中輕鬆檢視最多 10 個不同的存放庫提取要求,讓您更輕鬆地掌握提取要求。

GA 的多個存放庫小工具

社群建議票證

已解決為待用和待用圖表中已完成的簡介

我們瞭解正確反映小組進度的重要性,包括圖表中已完成的已解決專案。 使用簡單的切換選項,您現在可以選擇將已解析的項目顯示為已完成,以提供小組待處理狀態的真實反映。 這項增強功能允許更精確的追蹤和規劃,讓小組能夠根據實際進度做出明智的決策。 使用報表中已更新的待處理和待用圖表,體驗改善的透明度和更佳見解。

要示範的 Gif 已解析為已完成的待用圖表和待用圖表。

Wiki

支援Wiki頁面中的其他圖表類型

我們已將Wiki頁面中所使用的 Mermaid 圖表版本升級為 8.13.9。 透過此升級,您現在可以在 Azure DevOps Wiki 頁面中包含下列圖表和視覺效果:

  • 流程圖
  • 順序圖表
  • 甘特圖
  • 圓形圖
  • 需求圖表
  • 狀態圖表
  • 使用者旅程圖

不包含處於實驗模式的圖表,例如 Entity Relationship 和 Git Graph。 如需新功能的詳細資訊,請參閱 mermaid 版本資訊


意見反應

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


頁面頂端