Azure DevOps Server 2022 Update 1 版本資訊
| 開發人員社群 系統需求和相容性 | 授權條款 | 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 1。 如果您的 TFS 部署是在 TFS 2013 或更早版本上,您必須先執行一些過渡步驟,才能升級至 Azure DevOps Server 2022。 如需詳細資訊,請參閱 安裝頁面 。
Azure DevOps Server 2022 Update 1 Patch 4 發行日期:2024 年 6 月 11 日
檔案 | SHA-256 雜湊 |
---|---|
devops2022.1patch4.exe | 29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F |
我們已發行 適用於 Azure DevOps Server 2022 Update 1 的修補程式 4 ,其中包含下列專案的修正程式。
- 已修正Wiki和工作項目中的問題,其中搜尋結果不適用於以土耳其地區設定命名為土耳其文 「I」 的專案。
Azure DevOps Server 2022 Update 1 Patch 3 發行日期:2024 年 3 月 12 日
檔案 | SHA-256 雜湊 |
---|---|
devops2022.1patch3.exe | E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911 |
我們已發行 適用於 Azure DevOps Server 2022 Update 1 的修補程式 3 ,其中包含下列的修正程式。
- 解決在安裝 Patch 2 之後 Proxy 伺服器停止運作的問題。
- 已修正延伸模組詳細數據頁面上影響非英文語言的轉譯問題。
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 日
注意
此版本有兩個已知問題:
- 升級至 Azure DevOps Server 2022.1 並使用 Agent 集區設定中的更新代理程式之後,代理程式版本不會更新。 我們目前正在處理修補程式來解決此問題,並在進行時共用 開發人員社群 中的更新。 同時,您可以在此 開發人員社群 票證中找到此問題的因應措施。
- Maven 3.9.x 相容性。 Maven 3.9.x 透過從 Wagon 將預設 Maven 解析程式傳輸至原生 HTTP,引進了 Azure Artifacts 的重大變更。 這會導致使用 HTTP 而非 HTTPs 的客戶發生 401 驗證問題。 您可以在這裡找到有關此問題的更多詳細數據。 因應措施是,您可以繼續使用 Maven 3.9.x 搭配 屬性
-Dmaven.resolver.transport=wagon
。 這項變更會強制 Maven 使用 Wagon 解析程式傳輸。 如需詳細資訊,請參閱這裡的檔。
Azure DevOps Server 2022.1 是 Bug 修正的匯總。 其中包含先前發行的 Azure DevOps Server 2022.1 RC2 中的所有功能。
注意
Maven 3.9.x 相容性有已知問題。 Maven 3.9.x 透過從 Wagon 將預設 Maven 解析程式傳輸至原生 HTTP,引進了 Azure Artifacts 的重大變更。 這會導致使用 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 是 Bug 修正的匯總。 其中包含先前發行的 Azure DevOps Server 2022.1 RC1 中的所有功能。
注意
Maven 3.9.x 相容性有已知問題。 Maven 3.9.x 透過從 Wagon 將預設 Maven 解析程式傳輸至原生 HTTP,引進了 Azure Artifacts 的重大變更。 這會導致使用 HTTP 而非 HTTPs 的客戶發生 401 驗證問題。 您可以在這裡找到有關此問題的更多詳細數據。
因應措施是,您可以繼續使用 Maven 3.9.x 搭配 屬性 -Dmaven.resolver.transport=wagon
。 這項變更會強制 Maven 使用 Wagon 解析程式傳輸。 如需詳細資訊,請參閱這裡的檔。
此版本已修正下列事項:
- 修正了上游項目無法解析顯示名稱變更的本機摘要中的問題。
- 將索引標籤從 [程序代碼] 切換至 [搜尋] 頁面上的另一個索引卷標時,發生意外的錯誤。
- 使用中文、日文和韓文 (CJK) 統一表意法建立新工作項目類型時發生錯誤。 當小組項目名稱或包含 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 範圍
- [傳遞計劃] 頁面上的 [上次存取] 資料行
- 將傳遞計劃的所有相依性可視化
- 傳遞計劃中@CurrentIteration巨集
- 目前項目會設定為傳統管線中建置存取令牌的預設範圍
- 在查詢結果小工具中顯示父項
- 複製儀錶板
- 支援Wiki頁面中的其他圖表類型
- Container Registry 服務連線現在可以使用 Azure 受控識別
您也可以跳至個別區段,以查看每個服務的新功能:
一般
所有公用 REST API 都支援細微的 PAT 範圍
先前,一些公開記載的 Azure DevOps REST API 與範圍(例如工作專案讀取)沒有關聯,導致客戶使用完整範圍,透過個人存取令牌(PAT)等非互動式驗證機制取用這些 API。 使用完整範圍的個人存取令牌可增加他們落在惡意使用者的手中時的風險。 這是許多客戶未充分利用 控制平面 原則來限制 PAT 使用方式和行為的主要原因之一。
現在,所有公用 Azure DevOps REST API 現在都會與 相關聯,並支援細微的 PAT 範圍。 如果您目前使用完整範圍的 PAT 向其中一個公用 Azure DevOps REST API 進行驗證,請考慮移轉至具有 API 所接受特定範圍的 PAT,以避免不必要的存取。 在文件頁面的 [安全性] 區段中,可以找到指定 REST API 支援的細微 PAT 範圍。 此外,這裡還有一個範圍數據表。
延伸模組應該會顯示其範圍
將擴充功能安裝至 Azure DevOps 集合時,您可以檢閱擴充功能在安裝時所需的許可權。 不過,安裝擴充功能之後,擴充功能許可權就不會顯示在擴充功能設定中。 這給需要定期檢閱已安裝延伸模組的系統管理員帶來了挑戰。 現在,我們已將擴充功能許可權新增至延伸模塊設定,以協助您檢閱並決定是否要保留這些許可權。
Boards
[傳遞計劃] 頁面上的 [上次存取] 資料行
[傳遞計劃] 目錄頁面提供為您的專案定義的計劃清單。 您可以依:名稱、建立者、描述、上次設定或我的最愛排序。 透過此更新,我們已將 [上次存取] 資料行新增至目錄頁面。 這會提供上次開啟並查看傳遞計劃的時間可見度。 因此,很容易識別不再使用且可刪除的計劃。
將傳遞計劃的所有相依性可視化
傳遞計劃一律提供查看工作專案相依性的能力。 您可以逐一可視化相依性行。 在此版本中,我們可讓您在畫面上查看所有工作專案的所有相依性行,藉此改善體驗。 只要按下傳遞計劃右上方的 [相依性] 切換按鈕即可。 再次按下以關閉行。
新的工作專案修訂限制
過去幾年來,我們看到具有自動化工具的專案集合會產生數萬個工作項目修訂。 這會在工作項目表單和報告 REST API 上建立效能和可用性的問題。 為了減輕問題,我們已對 Azure DevOps Service 實作工作專案修訂限制 10,000。 限制只會影響使用 REST API 的更新,而不是工作項目表單。
按兩下這裡 以深入瞭解修訂限制,以及如何在自動化工具中處理。
將傳遞計劃小組限制從15提高到20
傳遞計劃可讓您檢視專案集合中的多個待辦專案和多個小組。 先前,您可以檢視 15 個小組待辦專案,包括來自不同專案的待辦專案和小組組合。 在此版本中,我們將上限從15增加到20。
已修正報告工作項目連結取得 API 中的 Bug
我們已修正 Reporting Work Item Links Get API 中的 Bug,以傳 System.LinkTypes.Remote.Related
回連結類型的正確 remoteUrl 值。 在此修正之前,我們會傳回錯誤的專案集合名稱和遺漏的專案標識碼。
建立暫存查詢 REST 端點
我們已看到數個延伸模組作者實例嘗試透過查詢字串傳遞工作專案查詢語言 (WIQL) 語句來執行未儲存的查詢。 除非您有達到查詢字串長度的瀏覽器限制的大型WIQL語句,否則這可正常運作。 為了解決這個問題,我們已建立新的 REST 端點,以允許工具作者產生暫時查詢。 使用回應中的標識碼透過querystring傳遞,可排除此問題。
如需詳細資訊,請參閱 暫存查詢 REST API 文件頁面。
批次刪除 API
目前,從回收站移除工作專案的唯一方式是使用此 REST API 一次刪除一個。 這可以是一個緩慢的過程,而且在嘗試進行任何類型的大規模清理時,會受到速率限制。 為了回應,我們已新增 REST API 端點,以刪除和/或終結批次中的工作專案。
@CurrentIteration 傳遞計劃中巨集
透過此更新,我們已新增對傳遞計畫中樣式巨集的支援 @CurrentIteration 。 此巨集可讓您從方案中每個數據列的小組內容取得目前的反覆專案。
傳遞方案中的卡片重設大小邏輯
並非每個人都會在追蹤功能與 Epic 時使用目標日期和/或開始日期。 有些選擇使用日期和反覆專案路徑的組合。 在此版本中,我們已改善邏輯,根據反覆運算路徑和日期欄位組合的使用方式,適當地設定反覆運算路徑和日期欄位組合。
例如,如果未使用目標日期,而且您調整卡片大小,則會設定新的反覆項目路徑,而不是更新目標日期。
批次更新改善
我們對 7.1 版的工作專案批次更新 API 進行了數個變更。 其中包括次要效能改善和部分失敗的處理。 這表示,如果一個修補程序失敗,但其他修補失敗,則其他修補程式將會順利完成。
按兩下這裡 以深入瞭解批次更新 REST API。
批次刪除 API
這個可刪除和/或終結批次中工作專案的新 REST API 端點現在已公開推出。 請按一下這裡深入了解。
防止編輯可共享選擇清單欄位
自定義欄位會跨進程共用。 這可能會為挑選清單欄位建立問題,因為我們允許進程管理員從欄位中新增或移除值。 這樣做時,變更會影響使用該欄位的每個進程。
為了解決這個問題,我們新增了集合管理員「鎖定」欄位無法編輯的功能。 當選取清單欄位鎖定時,本機進程管理員無法變更該挑選清單的值。 他們只能從進程新增或移除欄位。
新增儲存批注許可權
僅儲存工作專案批注的能力是開發人員社群中的首要要求。 我們很高興讓您知道我們已實作這項功能。 首先,讓我們檢閱最常見的案例:
“我想防止某些用戶編輯工作專案字段,但允許他們參與討論。
若要達成此目的,您必須移至 [項目設定 > 專案組態 > 區域路徑]。 然後選取所選的區域路徑,然後按兩下 [安全性]。
請注意新的許可權 「在此節點中編輯工作專案批注」。 根據預設,許可權會設定為 [未設定]。 也就是說,工作項目的行為會與之前完全相同。 若要允許群組或使用者儲存批注,請選取該群組/使用者,並將許可權變更為 [允許]。
當使用者在此區域路徑中開啟工作項目表單時,他們將能夠新增批注,但無法更新任何其他欄位。
我們希望您喜歡此功能,就像我們一樣多。 一如往常,如果您有任何意見反應或建議, 請讓我們知道。
互動式面板報表
位於 Boards 中樞的互動式報告,已可透過我們裝載的產品版本存取數年。 它們會取代較舊的累積流程圖、速度及短期衝刺燒毀圖表。 在此版本中,我們將提供它們。
若要檢視這些圖表,請按下 工作流程看板、待辦專案和短期衝刺頁面上的 [分析 ] 索引標籤位置。
Repos
拿掉分支建立者的「編輯原則」許可權
先前,當您建立新的分支時,我們獲授與編輯該分支上原則的許可權。 透過 此更新,我們會將預設行為變更為不授與此權限,即使存放庫的 [權限管理] 設定已開啟也一樣。
您必須透過安全性權限繼承或群組成員資格,手動或透過 REST API 明確授與「編輯原則」權限。
管線
目前項目會設定為傳統管線中建置存取令牌的預設範圍
Azure Pipelines 會使用作業存取令牌在運行時間存取 Azure DevOps 中的其他資源。 作業存取權杖是 Azure Pipelines 在執行階段針對每個作業動態產生的安全性權杖。 先前,建立新的傳統管線時,存取令牌的預設值會設定為 Project Collection。 透過此更新,我們會在建立新的傳統管線時,將作業授權範圍 設定為目前的專案 作為預設值。
您可以在存取存放庫、成品和其他資源檔中找到有關作業存取令牌 的更多詳細數據。
變更傳統組建管線中存取令牌的預設範圍
若要改善傳統建置管線的安全性,建立新的管線時,根據預設, 建置作業授權範圍 會是 Project。 到目前為止,它曾經是 專案集合。 深入瞭解 作業存取令牌。 這項變更不會影響任何現有的管線。 它只會影響您從這個點建立的新傳統組建管線。
適用於聖地牙哥、東京和猶他州 ServiceNow 的 Azure Pipelines 支援
Azure Pipelines 與 ServiceNow 有現有的整合。 整合依賴 ServiceNow 中的應用程式,以及 Azure DevOps 中的擴充功能。 我們現在已更新應用程式,以與聖迭戈、東京和猶他州版本的 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,而不需要管理認證。
注意
用來存取 Azure Container Registry 的受控識別需要適當的 Azure 角色型 存取控制 (RBAC) 指派,例如 AcrPull 或 AcrPush 角色。
針對 Kubernetes Service 連線建立的自動令牌
由於 Kubernetes 1.24,建立新的 Kubernetes Service 連線時,不會再自動建立令牌。 我們已將這項功能新增回去。 不過,建議您在存取 AKS 時使用 Azure 服務連線,以深入瞭解 如何使用 Kubernetes 工作部落格文章來取得 AKS 客戶的服務連線指引。
Kubernetes 工作現在支援 kubelogin
我們已更新 KuberentesManifest@1、 HelmDeploy@0、 Kubernetes@1 和 AzureFunctionOnKubernetes@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 呼叫支援新的 PAT 範圍,如下所示:
- 更新核准 支援範圍
Pipeline Resources Use
- 管理檢查 支援範圍
Pipeline Resources Use and Manage
- 更新資源 管線許可權支援範圍
Pipeline Resources Use and Manage
- 授權定義資源 支援範圍
Pipeline Resources Use and Manage
- 授權專案資源 支援範圍
Pipeline Resources Use and Manage
將受保護的資源限制為資源管理員
為了改善資源的安全性,對於您安全地建置和部署應用程式的能力至關重要,Azure Pipelines 現在需要資源類型系統管理員角色,才能將資源存取權開啟至所有管線。
例如,需要一般服務連線系統管理員角色,才能允許 任何 管線使用服務連線。 建立受保護的資源或編輯其安全性設定時,適用這項限制。
此外,建立服務連線且您沒有足夠的許可權時, 會停用 [授與所有管線的訪問許可權 ] 選項。
此外,當您嘗試開啟現有資源的存取權,且您沒有足夠的許可權時,您會收到 「您未獲授權」開啟此資源 訊息的存取權。
管線 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)
類型queue
為和的資源agentpool
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 現在為代理程式集區提供更細緻的存取管理。 此體驗類似於管理服務連線管線許可權的體驗。
防止授與所有管線對受保護資源的存取權
當您建立受保護的資源,例如服務連線或環境時,您可以選擇 [ 授與所有管線的訪問許可權 ] 複選框。 到目前為止,預設會核取此選項。
雖然這可讓管線更容易使用新的受保護資源,但相反的是,它偏好不小心授與太多管線存取資源的許可權。
若要升級默認選擇,Azure DevOps 現在會取消勾選複選框。
停用簡短秘密遮罩的能力
Azure Pipelines 會遮罩記錄中的秘密。 秘密可以是標示為秘密的變數、連結到 Azure 金鑰保存庫 之變數群組的變數,或是 Service Connection 提供者標示為秘密的服務連線專案。
所有出現的秘密值都會遮罩。 遮罩簡短秘密,例如 '1
、'、'2
'、'Dev
',可讓您輕鬆地猜測其值,例如日期: 'Jan 3, 202***
'
現在很明顯,『3
是一個秘密。 在這種情況下,您可能不想完全遮罩秘密。 如果無法將值標示為秘密(例如值取自 金鑰保存庫),您可以將旋鈕設定AZP_IGNORE_SECRETS_SHORTER_THAN
為最多 4 的值。
節點執行器下載工作
採用 排除節點 6 工作執行器 之代理程式版本時,您可能偶爾需要執行尚未更新以使用較新節點執行器的工作。 在此案例中,我們提供一種方法來仍然使用相依於節點生命週期結束執行器的工作,請參閱節點執行器指引部落 格文章。
下列工作是安裝 Node 6 執行器 Just-In-Time 的方法,因此舊工作仍然可以執行:
steps:
- task: NodeTaskRunnerInstaller@0
inputs:
runnerVersion: 6
已更新 TFX 節點執行器驗證
工作作者會使用 延伸模組封裝工具 (TFX) 來發佈延伸模組。 TFX 已更新為在節點執行器版本上執行驗證,請參閱節點執行器指引部落 格文章。
包含使用節點 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.
在管線代理程式上手動預安裝節點 6 的指示
如果您使用 pipeline-
代理程式摘要,則代理程式未包含節點 6。 在某些情況下,Marketplace 工作仍會依賴 Node 6,且代理程式無法使用 NodeTaskRunnerInstaller 工作 (例如,因為連線限制),您必須獨立預先安裝 Node 6。 若要達成此目的,請參閱如何手動安裝 Node 6 執行器的 指示 。
管線工作變更記錄
我們現在會將對管線工作的變更發佈至此 變更記錄 中。 這包含對 內建管線工作 所做的完整變更清單。 我們已回溯發佈先前的變更,因此變更記錄會提供工作更新的歷程記錄。
發行工作使用 Microsoft Graph API
我們已更新發行 工作 ,以使用 Microsoft Graph API。 這會從我們的工作中移除 AAD 圖形 API 的使用方式。
Windows PowerShell 工作效能改善
您可以使用工作在管線中定義自動化。 其中一項工作是 PowerShell@2
公用程式工作,可讓您在管線中執行 PowerShell 腳本。 若要使用 PowerShell 腳本以 Azure 環境為目標,您可以使用工作 AzurePowerShell@5
。 某些可以列印進度更新的PowerShell命令,例如 Invoke-WebRequest
,現在執行得更快。 如果您的腳本中有許多命令,或長時間執行,則改善更為顯著。 透過此更新,progressPreference
和 AzurePowerShell@5
工作的 PowerShell@2
屬性現在預設會設定為 SilentlyContinue
。
.NET 6 上的管線代理程式 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 限制,以符合 4 MB 的 Azure Resource Manager (ARM) 範本大小上限。
您可以使用 Azure Resource Manager 範本部署 工作來建立 Azure 基礎結構。 為了回應您的意見反應,我們已將 Azure Pipelines 整合限制 2 MB 增加到 4 MB。 這會與 ARM 範本 在整合大型範本期間的大小上限 4 MB 解析大小限制一致。
管線執行狀態概觀圖示
在此版本中,我們可讓您更輕鬆地瞭解管線執行的整體狀態。
對於具有許多階段的 YAML 管線,很難知道管線執行的狀態,也就是它仍在執行中或完成。 如果完成,則為整體狀態:成功、失敗或取消。 我們已藉由新增執行狀態概觀圖示來修正此問題。
管線階段側邊面板
YAML 管線可以有數十個階段,並非所有階段都適合您的畫面。 雖然管線執行概觀圖示會告訴您執行的整體狀態,但仍很難知道哪個階段失敗,或哪個階段仍在執行,例如。
在此版本中,我們新增了管線階段側邊面板,可讓您快速查看所有階段的狀態。 然後,您可以按下某個階段,並直接前往其記錄。
在側邊面板中搜尋階段
我們已更輕鬆地在階段側面板中尋找您要尋找的階段。 您現在可以根據階段的狀態快速篩選階段,例如執行階段或需要手動介入的階段。 您也可以依其名稱搜尋階段。
暫存快速動作
管線的 [執行] 畫面可讓您快速存取所有執行階段。 在此版本中,我們新增了階段面板,您可以從中為每個階段執行動作。 例如,您可以輕鬆地重新執行失敗的工作,或重新執行整個階段。 當並非所有階段都符合使用者介面時,即可使用面板,如下列螢幕快照所示。
當您在 [階段] 資料行中按兩下 [+] 登入時,[階段] 面板隨即出現,然後您可以執行階段動作。
檢查用戶體驗改善
我們正在讓讀取檢查記錄更容易。 檢查記錄會提供部署成功的關鍵資訊。 他們可以告訴您您是否忘記關閉工作專案票證,或您需要在 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 編輯器會了解範本的架構,包括輸入參數。
驗證后,您可以選擇瀏覽至範本。 您將能夠使用 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
上執行管線,它會擴充存放庫分支templates
中dev
檔案所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
上將管線從一次執行的分支 dev
擴充範本,並從另一個執行中的分支 main
擴充範本,而不需要變更管線的程式代碼。
指定存放庫資源屬性的範本運算式 ref
時,您可以使用 parameters
和系統預先定義的變數,但無法使用 YAML 或 Pipelines UI 定義的變數。
容器資源定義中的範本表示式
我們已在 YAML 管線中定義 endpoint
資源的 、 volumes
、 ports
和 options
屬性 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改善產品和服務的目標。
報表
在查詢結果小工具中顯示父項
查詢結果小工具現在支援父代的名稱和該父系的直接連結。
複製儀錶板
在此版本中,我們包括 複製儀錶板。
儀錶板上次存取日期及修改者
允許小組建立數個儀錶板的挑戰之一,就是管理和清除過時且未使用的儀錶板。 瞭解上次流覽或修改儀錶板的時間是瞭解哪些儀錶板可以移除的重要部分。 在此版本中,我們已在 [儀錶板] 目錄頁面包含兩個新的數據行。 上次存取的日期 會追蹤儀錶板最近瀏覽的時間。 修改者 追蹤上次編輯儀錶板的時間,以及由誰編輯。
[ 修改者] 資訊也會顯示在儀錶板頁面本身。
我們希望這些新欄位可協助專案管理員了解儀錶板的活動層級,以便在應移除儀錶板時做出受過教育的決定。
現在已提供分析檢視
分析 檢視 功能已處於預覽狀態,在我們的託管產品版本中已長時間處於預覽狀態。 在此版本中,我們很高興宣佈此功能現已可供所有專案集合使用。
在導覽中,分析檢視會從 [概觀] 索引卷標移至 [面板] 索引卷標。
分析檢視提供簡化的方式,可根據分析數據指定Power BI報表的篩選準則。 如果您不熟悉 分析檢視,以下是一些可供您趕上的檔:
現已提供多個存放庫的提取要求小工具
我們很高興宣佈 Azure DevOps Server 2022.1 提供多個存放庫的提取要求小工具。 有了這個新的小工具,您可以在單一簡化清單中輕鬆檢視最多 10 個不同存放庫的提取要求,讓您比以往更輕鬆地掌握提取要求。
已解決為已完成的燒毀和燒毀圖表簡介
我們瞭解正確反映小組進度的重要性,包括圖表中已完成的已解決專案。 使用簡單的切換選項,您現在可以選擇將已解決的項目顯示為已完成,以提供小組的待毀狀態真實反映。 這項增強功能允許更精確的追蹤和規劃,讓小組能夠根據實際進度做出明智的決策。 使用報表中已更新的燒毀和燒毀圖表,體驗改善透明度和更佳的深入解析。
Wiki
支援Wiki頁面中的其他圖表類型
我們已將Wiki頁面中使用的美人魚圖表版本升級為8.13.9。 透過此升級,您現在可以在 Azure DevOps Wiki 頁面中包含下列圖表和視覺效果:
- 流程圖
- 順序圖表
- 甘特圖
- 圓形圖
- 需求圖表
- 狀態圖
- 使用者旅程圖
不包含在實驗模式中的圖表,例如 Entity Relationship 和 Git Graph。 如需新功能的詳細資訊,請參閱 美人魚版本資訊。
意見反應
我們很希望聽聽您的意見! 您可以回報問題或提供想法,並透過 開發人員社群 追蹤問題,並取得 Stack Overflow 的建議。