| 開發人員社群 | 系統要求與相容性 | 許可條款 | 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 是錯誤修正的累積更新。 其中包含先前發行的 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頁面中的其他圖表類型
- 容器註冊表服務連線現在可以使用 Azure 管理的身份
您也可以跳至個別區段,以查看每個服務的新功能:
一般
所有公用 REST API 都支援細微的 PAT 範圍
在此之前,一些公開記錄的 Azure DevOps REST API 沒有與特定的 API 範圍(例如工作項目讀取)相關聯,這導致客戶需要使用完整範圍,透過像個人存取權杖(PAT)這類非互動式驗證機制來使用這些 API。 使用完整範圍的個人存取令牌可增加他們落在惡意使用者的手中時的風險。 這是許多客戶未充分利用 控制平面 原則來限制 PAT 使用方式和行為的主要原因之一。
現在,所有公用 Azure DevOps REST API 都會與細微的 PAT 範圍相關聯並支援它們。 如果您目前使用完整範圍的 PAT 向其中一個公用 Azure DevOps REST API 進行驗證,請考慮移轉至具有 API 所接受特定範圍的 PAT,以避免不必要的存取。 在 文件頁面的 [安全性] 區段中,可以找到指定 REST API 支援的細微 PAT 範圍。 此外, 這裡還有一個範圍數據表。
延伸模組應該顯示其範圍
將擴充功能安裝至 Azure DevOps 集合時,您可以檢閱擴充功能在安裝時所需的許可權。 不過,安裝擴充功能之後,擴充功能許可權就不會顯示在擴充功能設定中。 這給需要定期檢閱已安裝延伸模組的系統管理員帶來了挑戰。 現在,我們已將擴充功能許可權新增至延伸模塊設定,以協助您檢閱並決定是否要保留這些許可權。
董事會
[傳遞計劃] 頁面上的 [上次存取] 資料行
[傳遞計劃] 目錄頁面提供為您的專案定義的計劃清單。 您可以依:名稱、建立者、描述、上次設定或我的最愛排序。 透過此更新,我們已將 [上次存取] 資料行新增至目錄頁面。 這提供了何時上次開啟和查看交付計畫的清晰資訊。 因此,很容易識別不再使用且可刪除的計劃。
將傳遞計劃的所有相依性可視化
交付計劃一直提供查看工作項目之間相依性的能力。 您可以逐一查看依賴關係線。 在此版本中,我們改進了體驗,讓您可以在畫面上查看所有工作項目中所有的相依性關係,從而提升操作體驗。 只要按下交付計劃右上方的 [相依關係] 切換按鈕即可。 再次按一下關閉線條。
新的工作專案修訂限制
過去幾年來,我們看到具有自動化工具的專案集合會產生數萬個工作項目修訂。 這會在工作項目表單和報告 REST API 上建立效能和可用性的問題。 為了減輕問題,我們已對 Azure DevOps Service 實作工作專案修訂限制 10,000。 限制只會影響使用 REST API 的更新,而不是工作項目表單。
按兩下這裡 以深入瞭解修訂限制,以及如何在自動化工具中處理。
將傳遞計劃小組限制從15提高到20
傳遞計劃可讓您檢視專案集合中的多個待辦專案和多個小組。 之前,您可以查看 15 個團隊的待辦項目,包括來自不同專案的待辦項目和團隊組合。 在此版本中,我們將上限從15增加到20。
已修正報告工作項目連結取得的 API 錯誤
我們已修正 Reporting Work Item Links Get API 中的錯誤,以便對 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。 到目前為止,它曾經是 專案集合。 深入瞭解 作業存取令牌。 這項變更不會影響任何現有的管線。 它只會影響您從這個點建立的新傳統組建管線。
Azure Pipelines 對於 ServiceNow 的聖地牙哥、東京和猶他版本的支援
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:
- 取得分支
- 取得 Pull Request 資訊
- 報表組建狀態
Container Registry 服務連線現在可以使用 Azure 受控識別
您可以在建立 Azure Container Registry 的 Docker 登錄服務連線時,使用系統指派的受控識別。 這可讓您使用與自我裝載的 Azure Pipelines 代理程式相關聯的受控識別來存取 Azure Container Registry,而不需要管理認證。
備註
用來存取 Azure Container Registry 的 Managed Identity 需要具備適當的 Azure 角色型存取控制 (RBAC) 指派,例如 AcrPull 或 AcrPush 角色。
針對 Kubernetes Service 連線建立的自動令牌
由於 Kubernetes 1.24,自此,在建立新的 Kubernetes Service 連線時,不會再自動創建憑證。 我們已將這項功能新增回去。 不過,建議您在存取 AKS 時使用 Azure 服務連線。如需詳細資訊,請參閱 為 AKS 客戶提供 Kubernetes 工作的服務連線指南部落格文章。
Kubernetes 工作現在支援 kubelogin
我們已更新 KuberentesManifest@1、 HelmDeploy@0、 Kubernetes@1 和 AzureFunctionOnKubernetes@1 工作以支援 kubelogin。 這可讓您以 Azure Active Directory 整合設定的 Azure Kubernetes Service (AKS) 為目標。
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 Key Vault 的變數群組的變數,或由服務連線提供者標示為秘密的服務連接元素。
所有出現的秘密值都會被隱藏。 遮罩簡短秘密,例如 '1
、'、'2
'、'Dev
',可讓您輕鬆地猜測其值,例如日期: 'Jan 3, 202***
'
現在很明顯,『3
是一個秘密。 在這種情況下,您可能不想完全遮罩秘密。 如果無法將值標示為秘密(例如值取自 Key Vault),您可以將旋鈕設定 AZP_IGNORE_SECRETS_SHORTER_THAN
為最多 4 的值。
節點執行器下載工作
採用排除 Node.js 6 工作執行器之代理程式版本時,您可能會偶爾需要執行尚未更新來使用較新版本 Node.js 執行器的任務。 在此情境下,我們提供一種方法,可以在Node結束生命週期後仍然使用依賴該運行環境的工作,請參閱Node運行環境指南部落格文章。
下列工作是即時安裝 Node 6 運行環境的方法,因此舊工作仍然可以執行:
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.
在管線代理上手動預安裝 Node.js 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
和 PowerShell@2
工作的 AzurePowerShell@5
屬性現在預設會設定為 SilentlyContinue
。
.NET 6 上的管線代理程式 v3
管線代理程式已升級,將其運行環境從 .NET Core 3.1 改為 .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 中的項目發生事件時,服務攔截可讓您在其他服務上執行工作,執行 階段狀態已變更 為其中一個事件。 執行階段狀態變更事件必須包含執行的相關信息,包括管線的名稱。 先前,它只包含運行的 ID 和名稱的資料。 透過此更新,我們對事件進行了變更,以包含遺漏的資訊。
作業狀態變更的服務攔截
服務掛鉤可讓您回應在管線執行中狀態變更的相關事件。 到目前為止,您可以為管線運行和階段狀態變化設定服務掛鉤。
從現在開始,您可以設定服務掛鉤,在您的管線執行中作業狀態變更時觸發。 新事件的承載結構會顯示在下列範例中。
{
"subscriptionId": "8d91ad83-1db5-4d43-8c5a-9bb2239644b1",
"notificationId": 29,
"id": "fcad4962-f3a6-4fbf-9653-2058c304503f",
"eventType": "ms.vss-pipelines.job-state-changed-event",
"publisherId": "pipelines",
"message":
{
"text": "Run 20221121.5 stage Build job Compile succeeded.",
"html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
"markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
},
"detailedMessage":
{
"text": "Run 20221121.5 stage Build job Compile succeeded.",
"html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
"markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
},
"resource":
{
"job":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088"
},
"pipeline.web":
{
"href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/definition?definitionId=4647"
}
},
"id": "e87e3d16-29b0-5003-7d86-82b704b96244",
"name": "Compile",
"state": "completed",
"result": "succeeded",
"startTime": "2022-11-21T16:10:28.49Z",
"finishTime": "2022-11-21T16:10:53.66Z"
},
"stage": { ... },
"run": { ... },
"pipeline": { ... },
"repositories": [ ... ]
},
"resourceVersion": "5.1-preview.1",
"createdDate": "2022-11-21T16:11:02.9207334Z"
}
執行、階段和作業狀態變更服務攔截事件現在包含屬性 repository
,其中列出管線執行所使用的 Azure Repos。 例如:
"repositories":
[
{
"type": "Git",
"change":
{
"author":
{
"name": "Fabrikam John",
"email": "john@fabrikamfiber.com",
"date": "2022-11-11T15:09:21Z"
},
"committer":
{
"name": "Fabrikam John",
"email": "john@fabrikamfiber.com",
"date": "2022-11-11T15:09:21Z"
},
"message": "Added Viva support"
},
"url": "https://fabrikamfiber@dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_git/fabrikamfiber"
}
]
停用顯示流水線執行的最後一個認可訊息
先前,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
上執行管線,它會擴充template.yml
存放庫dev
分支中的templates
檔案所指定的範本。
或者,您可以撰寫下列 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 編輯器,選取 Triggers,然後選取 Process,然後開啟 Checkout 步驟。
如果您在 YAML 檔案和 UI 中同時指定此設定,則 YAML 檔案中指定的值優先。
針對您建立的所有新管線(YAML 或傳統),標籤預設依然會同步處理。 此選項不會變更現有管線的行為。 除非您如上述所述明確更改選項,否則這些管線中的標籤仍會保持同步。
工藝品
已更新預設信息流許可權
建立新的專案集合範圍 Azure Artifacts 摘要時,專案集合建置服務帳戶現在預設會有 共同作業者 角色,而不是目前的 參與者 角色。
上游套件搜尋的新用戶介面
先前,如果您有摘要的複本,您可能會看到上游套件。 您無法搜尋上游儲存庫中可用且尚未儲存在本地資料流中的套件,這就是問題所在。 現在,您可以使用新的摘要使用者介面來搜尋可用的上游套件。
Azure Artifacts 現在提供使用者介面,可讓您在上游來源中搜尋套件,並將套件版本儲存到摘要中。 這符合Microsoft改善產品和服務的目標。
報告
在查詢結果小工具中顯示父項
查詢結果組件現在支援父項名稱及其直接連結。
複製儀錶板
在此版本中,我們包括 複製儀錶板。
儀錶板上次存取日期及修改者
允許團隊建立數個儀錶板的挑戰之一,就是管理和清除這些過時且未使用的儀錶板。 瞭解上次流覽或修改儀錶板的時間是瞭解哪些儀錶板可以移除的重要部分。 在此版本中,我們在儀錶板目錄頁面中新增了兩個新的欄。 上次存取的日期 會追蹤儀錶板最近瀏覽的時間。 修改者 追蹤上次編輯儀錶板的時間,以及由誰編輯。
修改者資訊也會顯示在儀錶板頁面本身。
我們希望這些新欄位可協助專案管理員了解儀錶板的活動層級,以便在應移除儀錶板時做出明智的決定。
現在已提供分析檢視
分析檢視功能已處於預覽狀態,在我們的託管產品版本中已長時間處於預覽狀態。 在此版本中,我們很高興宣佈此功能現已可供所有專案集合使用。
在導覽中, 分析檢視 會從 [概 觀 ] 索引卷標移至 [ 面板 ] 索引卷標。
分析檢視提供簡化的方式,可根據分析數據指定Power BI報表的篩選準則。 如果您不熟悉 分析檢視,以下是一些文件來幫助您了解情況:
現已提供多個存放庫的提取要求小工具
我們很高興地宣佈 Azure DevOps Server 2022.1 現在提供多個存放庫的合併請求工具。 有了這個新的小工具,您可以在單一簡化清單中輕鬆檢視最多 10 個不同存放庫的提取要求,讓您比以往更輕鬆地掌握提取要求。
在燃盡圖和燃增圖中引入完成時即視為已解決的功能
我們瞭解正確反映小組進度的重要性,包括圖表中已完成的已解決專案。 使用簡單的切換選項,您現在可以選擇將已解決的項目顯示為已完成,以提供小組的待毀狀態真實反映。 這項增強功能允許更精確的追蹤和規劃,讓小組能夠根據實際進度做出明智的決策。 使用報表中已更新的燒毀和燒毀圖表,體驗改善透明度和更佳的深入解析。
的gif
維基
支援Wiki頁面中的其他圖表類型
我們已將Wiki頁面中使用的美人魚圖表版本升級為8.13.9。 透過此升級,您現在可以在 Azure DevOps Wiki 頁面中包含下列圖表和視覺效果:
- 流程圖
- 時序圖
- 甘特圖
- 餅圖
- 需求圖表
- 狀態圖
- 使用者旅程圖
不包含在實驗模式中的圖表,例如 Entity Relationship 和 Git Graph。 如需新功能的詳細資訊,請參閱 美人魚版本資訊。
意見反應
我們很希望聽聽您的意見! 您可以回報問題或提供想法,並透過 開發人員社群 追蹤問題,並取得 Stack Overflow 的建議。