Azure DevOpsServer 2020 Update 1 版本資訊
| 開發人員社群 System 需求 | 授權條款 | DevOps 部落格 | SHA-1 哈希
在本文中,您將找到 Azure DevOps Server 最新版的相關信息。
若要深入瞭解如何安裝或升級 Azure DevOps Server 部署,請參閱 Azure DevOps Server 需求。 若要下載 Azure DevOps 產品,請流覽 Azure DevOps Server 下載頁面。
Azure DevOps Server 2019 或 Team Foundation Server 2015 或更新版本支援直接升級至 Azure DevOps Server 2020。 如果您的 TFS 部署位於 TFS 2010 或更早版本,您必須在升級至 Azure DevOps Server 2019 之前執行一些過渡步驟。 若要深入瞭解,請參閱 安裝和設定 Azure DevOps 內部部署。
安全地從 Azure DevOps Server 2019 升級至 Azure DevOps Server 2020
Azure DevOps Server 2020 引進以專案層級設定為基礎的新管線執行(組建)保留模型。
Azure DevOps Server 2020 會根據管線層級保留原則,以不同的方式處理組建保留。 某些原則設定會導致在升級后刪除管線執行。 在升級之後,不會刪除已手動保留或由版本保留的管線執行。
如需如何安全地從 Azure DevOps Server 2019 升級至 Azure DevOps Server 2020 的詳細資訊,請閱讀我們的 部落格文章 。
Azure DevOps Server 2020 Update 1.2 Patch 13 發行日期:2024 年 3 月 12 日
檔案 | SHA-256 雜湊 |
---|---|
devops2020.1.2patch13.exe | 55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6 |
我們已針對 Azure DevOps Server 2020 Update 1.2 發行 Patch 13 ,其中包含下列專案的修正:
- 解決在安裝 Patch 12 之後 Proxy 伺服器停止運作的問題。
Azure DevOps Server 2020 Update 1.2 Patch 12 Release Date:2024 年 2 月 13 日
檔案 | SHA-256 雜湊 |
---|---|
devops2020.1.2patch12.exe | C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53 |
我們已發行 適用於 Azure DevOps Server 2020 Update 1.2 的 Patch 12 ,其中包含下列專案的修正:
- 已修正 Proxy 快取資料夾所使用的磁碟空間不正確且資料夾未正確清除的錯誤。
- CVE-2024-20667:Azure DevOps Server 遠端程式代碼執行弱點。
Azure DevOps Server 2020 Update 1.2 Patch 11 發行日期:2023 年 12 月 12 日
檔案 | SHA-256 雜湊 |
---|---|
devops2020.1.2patch11.exe | C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87 |
我們已針對 Azure DevOps Server 2020 Update 1.2 發行 Patch 11 ,其中包含下列專案的修正:
- 修正了預先部署核准安全性繼承無法在管線階段運作的錯誤。
Azure DevOps Server 2020 Update 1.2 Patch 10 Release Date:2023 年 11 月 14 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式,其中包含下列的修正程式。
- 擴充 PowerShell 工作允許啟用 殼層工作自變數參數驗證的字元清單。
注意
若要實作此修補程式的修正程式,您必須遵循許多步驟來手動更新工作。
安裝修補程式
重要
我們已發行 Azure Pipelines 代理程式的更新,修補程式 8 於 2023 年 9 月 12 日發行。 如果您未如 Patch 8 的版本資訊所述安裝代理程式更新,建議您先安裝這些更新,再安裝 Patch 10。 安裝 Patch 8 之後的新版本代理程式將會是 3.225.0。
設定 TFX
- 遵循將工作上傳至專案集合文件中的步驟,來使用 tfx-cli 進行安裝和登入。
使用 TFX 更新工作
檔案 | SHA-256 雜湊 |
---|---|
Tasks20231103.zip | 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5 |
- 下載並擷取 Tasks20231103.zip。
- 將目錄變更為解壓縮的檔案。
- 執行下列命令以上傳工作:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip
管線需求
若要使用新的行為,必須在使用受影響工作的管線中設定變數 AZP_75787_ENABLE_NEW_LOGIC = true
。
在傳統上:
在管線的 [變數] 索引標籤中定義變數。
YAML 範例:
variables:
- name: AZP_75787_ENABLE_NEW_LOGIC
value: true
Azure DevOps Server 2020 Update 1.2 Patch 9 發行日期:2023 年 10 月 10 日
重要
我們已發行 Azure Pipelines 代理程式的更新,修補程式 8 於 2023 年 9 月 12 日發行。 如果您未如 Patch 8 的版本資訊所述安裝代理程式更新,建議您先安裝這些更新,再安裝 Patch 9。 安裝 Patch 8 之後的新版本代理程式將會是 3.225.0。
我們已發行修補程式。 適用於包含下列修正的 Azure DevOps Server 2020 Update 1.2。
- 已修正「分析擁有者」身分識別在修補程式升級計算機上顯示為非使用中身分識別的錯誤。
Azure DevOps Server 2020 Update 1.2 Patch 8 Release Date:2023 年 9 月 12 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式,其中包含下列的修正程式。
- CVE-2023-33136:Azure DevOps Server 遠端程式碼執行弱點。
- CVE-2023-38155:Azure DevOps Server 和 Team Foundation Server 許可權提升弱點。
重要
請將修補檔部署到測試環境,並確定環境的管線在將修正程式套用至實際執行環境之前如預期般運作。
注意
若要實作此修補程式的修正程式,您必須遵循許多步驟來手動更新代理程式和工作。
安裝修補程式
- 下載並安裝 Azure DevOps Server 2020 Update 1.2 修補程式 8。
更新 Azure Pipelines 代理程式
- 從下列位置下載代理程式:https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
- 使用自我裝載 Windows 代理程式文件中概述的步驟來部署代理程式。
注意
AZP_AGENT_DOWNGRADE_DISABLED 必須設定為「true」,才能防止代理程式降級。 在 Windows 上,下列命令可以用於系統管理命令提示字元,後面接著重新開機。 setx AZP_AGENT_DOWNGRADE_DISABLED true /M
設定 TFX
- 遵循將工作上傳至專案集合文件中的步驟,來使用 tfx-cli 進行安裝和登入。
使用 TFX 更新工作
- 下載並解壓縮 Tasks_20230825.zip。
- 將目錄變更為解壓縮的檔案。
- 執行下列命令以上傳工作:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip
管線需求
若要使用新的行為,必須在使用受影響工作的管線中設定變數 AZP_75787_ENABLE_NEW_LOGIC = true
。
在傳統上:
在管線的 [變數] 索引標籤中定義變數。
YAML 範例:
variables:
- name: AZP_75787_ENABLE_NEW_LOGIC
value: true
Azure DevOps Server 2020 Update 1.2 Patch 7 Release Date:2023 年 8 月 8 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式 ,其中包含下列的修正程式。
- CVE-2023-36869:Azure DevOps Server 詐騙弱點。
- 更新 SSH 服務以支援 SHA2-256 和 SHA2-512。 如果您已將 SSH 設定檔硬式編碼為使用 RSA,您應該更新為 SHA2 或移除專案。
- 已解決在 Markdown 檔案中無法運作的相對鏈接問題。
- 已修正認可頁面上批注導覽的錯誤。
- 已修正分析擁有者身分識別顯示為非使用中身分識別的錯誤。
- 修正 CronScheduleJobExtension 上的無限迴圈 Bug。
Azure DevOps Server 2020 Update 1.2 Patch 6 發行日期:2023 年 6 月 13 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式 ,其中包含下列的修正程式。
- CVE-2023-21565:Azure DevOps Server 詐騙弱點。
- CVE-2023-21569:Azure DevOps Server 詐騙弱點。
- 已修正從 2018 或更早版本升級時干擾推送套件的錯誤。
- 已修正卸離或附加集合失敗的錯誤,回報下列錯誤:「TF246018:資料庫作業超過逾時限制且已取消。
Azure DevOps Server 2020 Update 1.2 Patch 5 Release Date:2023 年 2 月 14 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式 ,其中包含下列的修正程式。
- CVE-2023-21553:Azure DevOps Server 遠端程式代碼執行弱點
- 已修正透過 Web UI 的擱置集輔助功能問題
- 客戶必須在 Azure DevOps Server 管理控制台中更新 SMTP 相關設定之後,重新啟動 tfsjobagent 服務和 Azure DevOps Server 應用程式集區。
Azure DevOps Server 2020 Update 1.2 Patch 4 發行日期:2022 年 12 月 13 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式 ,其中包含下列的修正程式。
- 已修正 IdentityPicker 中特殊字元的顯示。
- 測試數據未遭到刪除,導致資料庫成長。 透過此修正,我們已更新組建保留,以避免建立新的孤立測試數據。
Azure DevOps Server 2020 Update 1.2 Patch 3 發行日期:2022 年 10 月 18 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式 ,其中包含下列的修正程式。
- 解決新增AD身分識別未出現在安全性對話身分識別選擇器的問題。
- 修正 Web 攔截設定中 [群組成員要求] 篩選條件的問題。
- 修正當管線的組織設定已將作業授權範圍設定為限制非發行管線目前專案的作業授權範圍時,修正網關簽入組建錯誤。
- 修正在建立已驗證 Proxy 後方的服務連線時,從 Azure 擷取存取令牌。
Azure DevOps Server 2020 Update 1.2 Patch 2 Release Date:2022 年 8 月 9 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式 ,其中包含下列的修正程式。
- 修正將工作專案指派給出現在不同網域中的身分識別時,識別值錯誤。
Azure DevOps Server 2020 Update 1.2 Patch 1 Release Date:2022 年 7 月 12 日
我們已發行 Azure DevOps Server 2020 Update 1.2 的修補程式 ,其中包含下列的修正程式。
- 在測試回合 API 中,傳回的接續令牌大於指定的 “maxLastUpdatedDate” 值。
Azure DevOps Server 2020 Update 1.2 發行日期:2022 年 5 月 17 日
Azure DevOps Server 2020 Update 1.2 是 Bug 修正的匯總。 您可以直接安裝 Azure DevOps Server 2020 Update 1.2 或從 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更新版本升級。
注意
此版本之後,Azure DevOps Server 2020 Update 1.2 大約三周后,數據遷移工具將可供使用。 您可以在這裡查看我們目前支援匯入的版本清單。
此版本包含下列專案的修正:
Azure DevOps Server 2020.1.2 會停用新的保留模型(在 Azure DevOps Server 2020 中引進),以避免遺失管線執行(組建)。 這表示系統會:
- 為執行 Server 2020 時產生的最近 3 個組建建立租用
- 針對沒有每個管線保留原則的 YAML 管線和傳統管線,會根據 集合層級的保留上限設定來保留組建
- 針對具有自定義每個管線保留原則的傳統管線,會根據管線特定的保留原則保留組建
- 具有租用的組建不會計入 [最小值] 以保留設定
變更集和擱置集批注連結未正確重新導向。 將批註新增至變更集或擱置集中的檔案時,選取這些批注不會重新導向至檔案檢視中的正確位置。
無法使用 [執行下一步] 按鈕略過組建佇列。 先前,僅針對專案集合管理員啟用 [執行下一步] 按鈕。
停用使用者的 Active Directory 帳戶之後,撤銷所有個人存取令牌。
Azure DevOps Server 2020.1.1 修補程式 4 發行日期:2022 年 1 月 26 日
我們已發行 Azure DevOps Server 2020.1.1 的修補程式 ,其中包含下列的修正程式。
- 使用工作專案中的 @mention 控件時,不會傳送電子郵件通知。
- 慣用的電子郵件地址未在使用者設定檔中進行更新。 這會導致電子郵件傳送至先前的電子郵件地址。
- 標頭未顯示在 [項目摘要] 頁面中。 標頭顯示數毫秒,然後消失。
- Active Directory 使用者同步處理的改善。
- 藉由從 log4j 二進位檔中移除 jndilookup 類別,解決了 Elasticsearch 弱點。
安裝步驟
- 使用 Patch 4 升級伺服器。
- 檢查位於
HKLM:\Software\Elasticsearch\Version
的登錄值。 如果登錄值不存在,請新增字串值,並將 Version 設定為 5.4.1 (Name = Version, Value = 5.4.1)。 - 執行讀我檔案中所提供的更新命令
PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update
。 其可能會傳回如下的警告:「無法連線至遠端伺服器」。 請勿關閉視窗,因為更新會執行重試,直到完成為止。
注意
如果 Azure DevOps Server 和 Elasticsearch 安裝在不同的電腦上,請遵循下列步驟。
- 使用 Patch 4 升級伺服器。
- 檢查位於
HKLM:\Software\Elasticsearch\Version
的登錄值。 如果登錄值不存在,請新增字串值,並將 Version 設定為 5.4.1 (Name = Version, Value = 5.4.1)。 - 將名為 zip、位於
C:\Program Files\{TFS Version Folder}\Search\zip
的資料夾內容複製到 Elasticsearch 遠端檔案資料夾。 - 在 Elasticsearch 伺服器電腦上執行
Configure-TFSSearch.ps1 -Operation update
。
SHA-256 哈希: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6
Azure DevOps Server 2020.1.1 Patch 3 發行日期:2021 年 12 月 15 日
Azure DevOps Server 2020.1.1 的修補程式 3 包含下列修正程式。
- 修正使用「包含文字」查詢的工作專案巨集。 先前,查詢會針對包含換行符的值傳回不正確的結果。
- 增加 Maven 套件版本字元長度的限制。
- 自訂工作專案版面配置狀態的當地語系化問題。
- 電子郵件通知範本中的當地語系化問題。
- 針對欄位定義多個 NOTSAMEAS 規則時,NOTSAMEAS 規則評估的問題。
Azure DevOps Server 2020.1.1 修補程式 2 發行日期:2021 年 10 月 26 日
Azure DevOps Server 2020.1.1 的修補程式 2 包含下列修正程式。
- 先前,Azure DevOps Server 只能建立 GitHub Enterprise Server 的連線。 透過此修補程式,專案管理員可以在 GitHub.com 上建立 Azure DevOps Server 與存放庫之間的連線。 您可以在 [項目設定] 下的 [GitHub 連線] 頁面中找到此設定。
- 解決測試計劃小工具的問題。 測試執行報告在結果上顯示不正確的使用者。
- 修正 [專案概觀摘要] 頁面無法載入的問題。
- 修正未傳送電子郵件以確認產品升級的問題。
Azure DevOps Server 2020.1.1 修補程式 1 發行日期:2021 年 9 月 14 日
Azure DevOps Server 2020.1.1 的修補程式 1 包含下列修正程式。
- 修正成品下載/上傳失敗。
- 解決測試結果數據不一致的問題。
Azure DevOps Server 2020 Update 1.1 發行日期:2021 年 8 月 17 日
Azure DevOps Server 2020 Update 1.1 是 Bug 修正的匯總。 您可以直接安裝 Azure DevOps Server 2020 Update 1.1 或從 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更新版本升級。
注意
此版本之後大約三周,Azure DevOps Server 2020 Update 1.1 將可使用數據遷移工具。 您可以在這裡查看我們目前支援匯入的版本清單。
此版本包含下列 Bug 的修正:
Azure Boards
- 通知電子郵件中的「檢視工作專案」超連結未使用公用 URL。
Azure Repos
- 已修正限制合併類型繼承複選框,以在設定跨存放庫原則之後啟用修改限制合併類型。
Azure Pipelines
- 變更代理程式更新的設定時,設定不會傳播至環境中的其他應用層。
一般
- 已修正伺服器組態精靈中的拼字。
- 增加擴充功能套件大小,並可讓您變更登錄中的大小。
Azure Test Plans
- 一旦您從歷程記錄回到摘要頁面,就無法流覽回測試結果。
Azure DevOps Server 2020.1 Patch 2 發行日期:2021 年 8 月 10 日
我們已發行 Azure DevOps Server 2020.1 的修補程式 ,以修正下列各項。
- 修正組建定義UI錯誤。
- 已變更瀏覽歷程記錄以顯示檔案,而不是根存放庫。
Azure DevOps Server 2020.1 修補程式 1 發行日期:2021 年 6 月 15 日
我們已發行 Azure DevOps Server 2020.1 的修補程式 ,以修正下列各項。
保護用於判斷提示
SameSite=None
之授權流程中的 Cookie。解決通知 SDK 的問題。 先前,未正確剖析使用區域路徑篩選的通知訂閱。
Azure DevOps Server 2020.1 RTW 發行日期:2021 年 5 月 25 日
Azure DevOps Server 2020.1 RTW 的新功能摘要
Azure DevOps Server 2020.1 RTW 是 Bug 修正的匯總。 其中包含先前發行的 Azure DevOps Server 2020.1 RC2 中的所有功能。 Azure DevOps Server 2020.1 RTW 是 Bug 修正的匯總。 您可以直接安裝 Azure DevOps Server 2020.1 或從 Azure DevOps Server 2020、2019 或 Team Foundation Server 2015 或更新版本升級。
注意
此版本之後,Azure DevOps Server 2020 Update 1 大約三周后,數據遷移工具將可供使用。 您可以在這裡查看我們目前支援匯入的版本清單。
Azure DevOps Server 2020.1 RC2 發行日期:2021 年 4 月 13 日
Azure DevOps Server 2020.1 RC2 的新功能摘要
Azure DevOps Server 2020.1 RC2 是 Bug 修正的匯總。 其中包含先前發行的 Azure DevOps Server 2020.1 RC1 中的所有功能。
Azure DevOps Server 2020.1 RC1 發行日期:2021 年 3 月 23 日
Azure DevOps Server 2020.1 RC1 的新功能摘要
Azure DevOps Server 2020.1 RC1 引進了許多新功能。 一些重點包括:
您也可以跳至個別區段,以查看每個服務的新功能:
Boards
狀態轉換限制規則
我們會繼續縮小託管 XML 與繼承進程模型之間的功能同位差距。 這個新的工作項目類型規則可讓您限制工作專案從某個狀態移至另一個狀態。 例如,您可以限制 Bug 從 [新增] 移至 [已解決]。 相反地,他們必須從 [新增 - 作用中> - 已解決]>
您也可以建立規則,以依群組成員資格限制狀態轉換。 例如,只有「核准者」群組中的使用者才能將用戶劇本從 New -> Approved 移動。
複製工作專案以複製子系
Azure Boards 的最上層要求功能之一,就是能夠複製也會複製子工作專案的工作專案。 我們已將 [包含子工作專案] 的新選項新增至複製工作項目對話方塊。 選取時,此選項會複製工作專案,並複製所有子工作專案(最多 100 個)。
改善已啟動和已解析欄位的規則
到目前為止,Activated By、Activated Date、Resolved By 和 Resolved Date 的規則一直是個謎。 它們只會針對系統工作項目類型進行設定,且專屬於「作用中」和「已解決」的狀態值。 我們已變更邏輯,讓這些規則不再適用於特定狀態。 相反地,它們會由狀態所在的類別(狀態類別)觸發。 例如,假設您在 [已解決] 類別中有「需要測試」的自定義狀態。 當工作專案從「作用中」變更為「需要測試」時, 會觸發「已解決者 」和 「已解決日期 」規則。
這可讓客戶建立任何自定義狀態值,但仍產生 [啟用者]、 [啟用日期]、 [解析依據] 和 [解析日期 ] 字段,而不需要使用自定義規則。
項目關係人可以跨面板移動工作專案行
項目關係人一直能夠變更工作項目的狀態。 但是,當他們移至工作流程看板面板時,就無法將工作專案從一個數據行移到另一個數據行。 相反地,專案關係人必須一次開啟每個工作專案,並更新狀態值。 這長期以來一直是客戶的痛點,我們很高興宣佈,您現在可以跨面板數據行移動工作專案。
待辦項目與面板上的系統工作項目類型
現在您可以將系統工作項目類型新增至選擇的待辦專案層級。 在過去,這些工作專案類型只能從查詢取得。
處理 | 工作項目類型 |
---|---|
敏捷式 | 問題 |
Scrum | 障礙 |
CMMI | 變更要求 |
問題 | |
檢閱 | |
風險 |
將系統工作專案類型新增至待辦專案層級很簡單。 只要進入您的自定義程式,然後按兩下 [待辦專案層級] 索引標籤。選取您選擇的待辦專案層級(例如:需求待辦專案),然後選擇 編輯選項。 然後新增工作項目類型。
引發 Azure Boards GitHub 應用程式存放庫限制
GitHub Marketplace 中 Azure Boards 應用程式的存放庫限制已從 100 增加到 250。
在合併提取要求時自訂工作項目狀態
並非所有工作流程都相同。 有些客戶想要在提取要求完成時關閉其相關的工作專案。 其他人想要在關閉之前,將工作項目設定為要驗證的另一個狀態。 我們應該同時允許這兩者。
我們有一項新功能,可讓您在提取要求合併並完成時,將工作項目設定為所需的狀態。 若要這樣做,我們會掃描提取要求描述,並尋找狀態值,後面接著工作專案的 #mention。 在此範例中,我們會將兩個用戶劇本設定為 [已解決] 並關閉兩個工作。
將您的工作項目連結至另一個專案中的組建 (機器翻譯)
您現在只要將工作專案連結至組建、在組建中找到或整合在組建中,即可輕鬆地追蹤專案之間的組建相依性。
編輯系統欄位上的描述 (說明文字) (機器翻譯)
您一直能夠編輯自定義欄位的描述。 但是,對於優先順序、嚴重性和活動等系統字段,無法編輯描述。 這是託管 XML 與 Inherited 之間的功能差距,導致某些客戶無法移轉至繼承的模型。 您現在可以編輯系統欄位的描述。 編輯的值只會影響進程中的欄位,以及該工作專案類型的欄位。 這可讓您彈性地針對不同工作項目類型上的相同欄位提供不同的描述。
在合併提取要求時自訂工作項目狀態
提取要求通常會參考多個工作專案。 當您建立或更新提取要求時,您可能會想要關閉其中一些要求、解決其中一些要求,並讓其餘專案保持開啟。 您現在可以使用批注,例如下圖所示的批注來完成此動作。 如需詳細資訊,請參閱檔。
工作面板上的父欄位
由於熱門要求,您現在可以將 [父] 字段新增至 [工作面板] 上的子卡片和父卡片。
拿掉 Bug 工作項目類型的「指派給」規則
敏捷式、Scrum 和 CMMI 中所有不同工作項目類型都有數個隱藏的系統規則。 這些規則已經存在了十多年,一般沒有投訴就罰款了。 然而,有幾個規則已經耗盡了他們的歡迎。 其中一項規則尤其給新客戶和現有客戶造成了很大的痛苦,我們決定是時候將其移除了。 此規則存在於敏捷式程式中的 Bug 工作項目類型上。
「當狀態變更為 [已解決] 時,將 [指派的值] 設定為 [建立者]
我們收到關於此規則的許多意見反應。 作為回應,我們繼續進行,並從敏捷式程式中的 Bug 工作項目類型中移除此規則。 這項變更會影響使用繼承的 Agile 或自定義繼承的 Agile 程式的每個專案。 對於喜歡和相依於此目前規則的客戶,請參閱我們的 部落格文章 ,以瞭解您可以使用自定義規則重新新增規則的步驟。
[工作項目] 頁面上已移除的項目
[ 工作專案] 頁面 是一個絕佳的位置,可讓您快速尋找您所建立或指派給您的專案,以及其他專案。 它提供數個個人化樞紐和篩選。 「指派給我」樞紐的其中一個最高投訴是它顯示已移除的工作專案(也就是處於已移除狀態的工作專案)。 我們同意了! 已移除的專案是不再值的工作,因此已從待辦專案中移除,因此在此檢視中包含專案並無説明。
您現在可以隱藏 [工作專案] 頁面上 [指派給我] 樞紐中的所有已移除專案。
Repos
默認分支名稱喜好設定
Azure Repos 現在提供 Git 的可自定義預設分支名稱。 在存放庫設定中,您可以選擇初始化存放庫時要使用的任何合法分支名稱。 Azure Repos 一律支援變更現有存放庫的預設分支名稱。
預設分支的組織層級設定
現在,新存放庫慣用的初始分支名稱有集合層級設定。 如果專案尚未選擇初始分支名稱,則會使用此組織層級設定。 如果您未在組織設定或項目設定中指定初始分支名稱,則新的存放庫將會使用 Azure DevOps 定義的預設值。
新增用於參與 PR 註解的新驗證範圍
此版本新增了讀取/寫入提取要求批注的新 OAuth 範圍。 如果您有只需要與批注互動的 Bot 或自動化,您可以只提供具有此範圍的 PAT。 如果自動化有 Bug 或令牌遭到入侵,此程式會減少爆炸半徑。
提取要求體驗改善
新的提取要求體驗已透過下列專案改善:
- 讓選擇性檢查更加可見
客戶會使用選擇性檢查來引起開發人員對潛在問題的注意。 在先前的體驗中,當這些檢查失敗時,它過去就很明顯。 不過,在預覽體驗中,情況並非如此。 必要檢查上的大綠色複選標記會遮罩選擇性檢查中的失敗。 使用者只能藉由開啟檢查面板來發現選擇性檢查失敗。 當沒有問題的跡象時,開發人員不會經常這麼做。 在此部署中,我們已在摘要中顯示選擇性檢查的狀態。
- 在功能表項上按 Ctrl 鍵
PR 上的索引標籤表不支援按 Ctrl 鍵。 使用者通常會在檢閱提取要求時開啟新的瀏覽器索引標籤。 此問題已修正。
- [+] 註釋的位置
PR 中檔案的樹狀結構清單會顯示註釋 [+],以協助作者和檢閱者識別新檔案。 由於批注是在省略號之後,所以通常看不到較長的檔名。
- PR 更新下拉式清單重新取得計時資訊
要選取更新和比較PR中檔案的下拉式清單遺失預覽體驗中的重要元素。 它未顯示該更新的建立時機。 此問題已修正。
- **改善批注篩選配置 **
篩選提取要求的摘要頁面上的批注時,下拉式清單位於右側,但文字靠左對齊。 此問題已修正。
- 瀏覽至父認可
在 [認可] 頁面底下,您可以比較特定認可中所做的變更與其父認可。 不過,您可能想要流覽至父認可,並進一步瞭解該認可與其父代有何不同。 當您想要瞭解版本中的所有變更時,通常需要此專案。 我們已將父代卡片新增至認可,以協助您達成此目的。
- PR 檔案索引標籤中有更多空間可容納具有完整名稱的資料夾和檔案
由於檔案樹狀結構中缺乏水準間距,所以已截斷具有長名稱的資料夾和檔案。 我們藉由修改樹狀結構縮排來比對根節點,並從頁面隱藏省略號按鈕,以復原樹狀結構中的一些額外空間,但暫留時除外。
新檔案樹狀結構的影像:
將滑鼠停留在目錄上方時,檔案樹狀結構的影像:
- 在調整 PR 檔案索引標籤中的差異窗格大小時保留捲軸位置
調整PR檔案索引標籤中並存差異窗格的大小時,使用者捲動位置將會遺失。 此問題已修正;用戶的捲動位置現在會保留在差異窗格大小上。
- 在行動裝置上搜尋認可
在行動裝置上檢視 [認可] 頁面時,新體驗中遺漏搜尋方塊。 因此,您很難依其哈希找到認可,並加以開啟。 現在已修正此問題。
- 新 PR 檔案差異行動檢視中改善的空間使用方式
我們已更新此頁面,以充分利用空間,讓用戶可以在行動檢視中看到更多檔案,而不是讓標頭佔用 40% 的畫面。
- PR 摘要檢視中的增強影像
PR 中編輯的影像未顯示在PR摘要檢視中,但已在PR檔案檢視中正確顯示。 這個問題已經解決。
- 增強建立新 PR 時的分支體驗
在此更新之前,此體驗並不理想,因為它會將變更與存放庫的預設分支進行比較,而不是比較分支。
管線
其他代理程序平臺:ARM64
我們已將Linux/ARM64新增至 Azure Pipelines 代理程式支援的平台清單。 雖然程式代碼變更最少,但許多幕後工作必須先完成,我們很高興宣佈其發行!
管線資源的標籤篩選支援
我們現在已在 YAML 管線中新增 「標記」。 您可以使用標記來設定要執行的 CI 管線,或何時自動觸發。
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main
tags: ### This filter is used for resolving default version
- Production ### Tags are AND'ed
trigger:
tags: ### This filter is used for triggering the pipeline run
- Production ### Tags are AND'ed
- Signed
上述代碼段顯示標記可用來判斷當CD(持續部署) 管線執行未由其他來源/資源或排程的執行觸發程式觸發時,要執行的預設 CI (持續整合) 管線版本。
例如,如果您的CD管線已設定已排程的觸發程式,只有在 CI 具有生產標記時才想要執行,則觸發程式區段中的標籤可確保只有在 CI 完成事件符合標記條件時,才會觸發 CD 管線。
控制管線中允許的工作
您現在可以停用 Marketplace 工作。 有些您可能允許 Marketplace 擴充功能,但不能允許它們帶來的管線工作。 為了更進一步的控制,我們也允許您獨立停用所有現成的工作(除了結帳,這是一個特殊動作)。 啟用這兩個設定后,唯一允許在管線中執行的工作就是使用 tfx 上傳的工作。 請瀏覽 https://dev.azure.com/<your_org>/_settings/pipelinessettings
並尋找稱為「工作限制」的區段以開始使用。
獨佔部署鎖定原則
透過此更新,您一次只能將單一執行部署至環境。 藉由在環境上選擇「獨佔鎖定」檢查,只會繼續執行一次。 後續要部署至該環境的執行將會暫停。 當具有獨佔鎖定的執行完成之後,最新的執行將會繼續進行。 任何中繼執行都會取消。
管線資源觸發程式的階段篩選
我們新增了 「階段」的支援,做為 YAML 中管線資源的篩選。 使用此篩選器時,您不需要等候整個 CI 管線完成以觸發 CD 管線。 您現在可以選擇在 CI 管線中完成特定階段時觸發 CD 管線。
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages: ### This stage filter is used when evaluating conditions for triggering your CD pipeline
- PreProduction ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered.
- Production
當您的 CI 管線中順利完成觸發程式篩選中提供的階段時,就會針對 CD 管線自動觸發新的執行。
YAML 管線的一般 Webhook 型觸發程式
目前,我們有各種資源(例如管線、容器、組建和套件),您可以透過這些資源取用成品並啟用自動化觸發程式。 不過,到目前為止,您無法根據其他外部事件或服務將部署程序自動化。 在此版本中,我們引進 YAML 管線中的 Webhook 觸發程式支援,以啟用管線自動化與任何外部服務的整合。 您可以透過其 Webhook 訂閱任何外部事件(Github、Github Enterprise、Nexus、Aritfactory 等),並觸發您的管線。
以下是設定 Webhook 觸發程式的步驟:
在您的外部服務上設定 Webhook。 建立 Webhook 時,您需要提供下列資訊:
- 要求 URL - “ADO 集合>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview”https://dev.azure.com/<
- 秘密 - 這是選擇性的。 如果您需要保護您的 JSON 承載,請提供 秘密 值
建立新的「傳入 Webhook」服務連線。 這是新引進的服務連線類型,可讓您定義三個重要資訊:
- Webhook 名稱:Webhook 的名稱應符合在外部服務中建立的 Webhook。
- HTTP 標頭 - 要求中 HTTP 標頭 的名稱,其中包含要求驗證的承載哈希值。 例如,在 GitHub 的情況下,要求標頭會是 “X-Hub-Signature”
- 秘密 - 秘密用來剖析用於驗證傳入要求的承載哈希(這是選擇性的)。 如果您在建立 Webhook 時使用了秘密,則必須提供相同的秘密密鑰
YAML 管線中引進名為
webhooks
的新資源類型。 若要訂閱 Webhook 事件,您必須在管線中定義 Webhook 資源,並將其指向傳入 Webhook 服務連線。 您也可以根據 JSON 承載數據在 Webhook 資源上定義其他篩選,以進一步自定義每個管線的觸發程式,並以作業中的變數形式取用承載數據。
resources:
webhooks:
- webhook: MyWebhookTrigger ### Webhook alias
connection: MyWebhookConnection ### Incoming webhook service connection
filters:
- path: repositoryName ### JSON path in the payload
value: maven-releases ### Expected value in the path provided
- path: action
value: CREATED
steps:
- task: PowerShell@2
inputs:
targetType: 'inline'
### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
script: |
Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
- 每當傳入 Webhook 服務連線收到 Webhook 事件時,就會針對訂閱 Webhook 事件的所有管線觸發新的執行。
YAML 資源觸發程式問題支援和可追蹤性
當管線觸發程式無法如預期般執行時,可能會造成混淆。 為了協助進一步瞭解這一點,我們在管線定義頁面中新增了一個名為「觸發程序問題」的功能表項,其中會顯示有關觸發程式執行原因的資訊。
資源觸發程式可能會因為兩個原因而無法執行。
如果所提供的服務連線來源無效,或觸發程式中有任何語法錯誤,則完全不會設定觸發程式。 這些會呈現為錯誤。
如果觸發條件不相符,則不會執行觸發程式。 每當發生這種情況時,就會顯示警告,以便您了解條件不相符的原因。
多重存放庫觸發程式
您可以在一個 YAML 檔案中指定多個存放庫,並讓管線由任何存放庫的更新觸發。 例如,這項功能在下列案例中很有用:
- 您可以從不同的存放庫取用工具或連結庫。 每當工具或連結庫更新時,您想要執行應用程式的測試。
- 您可以將 YAML 檔案保留在與應用程式程式代碼不同的存放庫中。 您想要在每次將更新推送至應用程式存放庫時觸發管線。
透過此更新,多存放庫觸發程式僅適用於 Azure Repos 中的 Git 存放庫。 它們不適用於 GitHub 或 BitBucket 存放庫資源。
以下範例示範如何在管線中定義多個存放庫資源,以及如何設定所有存放庫資源的觸發程式。
trigger:
- main
resources:
repositories:
- repository: tools
type: git
name: MyProject/tools
ref: main
trigger:
branches:
include:
- main
- release
如果有任何更新,就會觸發此範例中的管線:
main
self
存放庫中包含 YAML 檔案的分支main
或release
存放庫中的tools
分支
如需詳細資訊,請參閱 管線中的多個存放庫。
已改善代理程式記錄上傳作業
當代理程式停止與 Azure Pipelines 伺服器通訊時,它正在執行的作業會遭到放棄。 如果您碰巧查看串流控制台記錄,您可能已經收到一些有關代理程式在停止回應之前正確情況的線索。 但是,如果您沒有,或者如果您重新整理頁面,這些控制台記錄就消失了。 在此版本中,如果代理程式在傳送完整記錄之前停止響應,我們會將控制台記錄保留為下一個最佳專案。 控制台記錄每行限制為1000個字元,而且偶爾可能不完整,但它們比不顯示任何內容更有説明! 檢查這些記錄可協助您針對自己的管線進行疑難解答,而且在協助進行疑難解答時,它肯定會協助我們的支持工程師。
選擇性掛接唯讀容器磁碟區
當您在 Azure Pipelines 中執行容器作業時,包含工作區、工作和其他材質的數個磁碟區會對應為磁碟區。 這些磁碟區預設為讀取/寫入存取權。 為了提高安全性,您可以在 YAML 中變更容器規格,以只讀方式掛接磁碟區。 底下的 mountReadOnly
每個索引鍵都可以針對唯讀設定為 true
(預設值為 false
)。
resources:
containers:
- container: example
image: ubuntu:18.04
mountReadOnly:
externals: true
tasks: true
tools: true
work: false
精細地控制容器啟動/停止
一般而言,我們建議您允許 Azure Pipelines 管理作業和服務容器的生命週期。 不過,在某些不尋常的案例中,您可能想要自行啟動和停止它們。 在此版本中,我們已將該功能建置至 Docker 工作。
以下是使用新功能的範例管線:
resources:
containers:
- container: builder
image: ubuntu:18.04
steps:
- script: echo "I can run inside the container (it starts by default)"
target:
container: builder
- task: Docker@2
inputs:
command: stop
container: builder
# if any step tried to run in the container here, it would fail
此外,我們也在管線變數 Agent.ContainerMapping
中包含容器清單。 例如,如果您想要檢查文本中的容器清單,可以使用此選項。 它包含字串化的 JSON 物件,會將資源名稱 (上述範例中的“builder” 對應至代理程式所管理的容器識別符。
將每個步驟的工作套件組合解壓縮
當代理程式執行作業時,它會先下載作業步驟所需的所有工作配套。 一般而言,為了達到效能,即使工作用於多個步驟,它還是會為每個作業解壓縮一次工作。 如果您擔心未受信任的程式代碼會改變未解壓縮的內容,您可以讓代理程式將工作解壓縮到每個使用量,藉以消除一點效能。 若要啟用此模式,請在設定代理程式時傳遞 --alwaysextracttask
。
透過限制存取權杖的範圍提高版本安全性
根據我們的計劃來增強 Azure Pipelines 的安全性設定,我們現在支援限制發行的存取令牌範圍。
在版本中執行的每個作業都會取得存取令牌。 工作和腳本會使用存取令牌來回呼 Azure DevOps。 例如,我們使用存取令牌來取得原始程式碼、下載成品、上傳記錄、測試結果,或對 Azure DevOps 進行 REST 呼叫。 系統會為每個作業產生新的存取令牌,並在作業完成之後到期。
透過此更新,我們會藉由限制存取令牌的範圍,並將相同的擴充至傳統版本,來改善管線安全性。
這項功能預設會針對新的專案和集合開啟。 針對現有的集合,您必須在集合 [設定>管線設定>] 中啟用它。 >將作業授權範圍限制為發行管線的目前專案。 在這裡深入了解。
YAML 預覽 API 增強功能
您現在可以預覽管線的完整 YAML ,而不需要執行它。 此外,我們已建立預覽功能的專用新URL。 現在您可以POST以 https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview
擷取完成的YAML主體。 這個新的 API 會採用與佇列執行相同的參數,但不再需要「佇列組建」許可權。
接著執行此工作 (機器翻譯)
您有一個 Bugfix,您需要立即部署,但必須等待 CI 和 PR 作業嗎? 在此版本中,我們現在可讓您提高已排入佇列作業的優先順序。 具有集區 [管理] 許可權的使用者 ,通常是集區系統管理員 ,會在作業詳細數據頁面上看到新的 [執行下一步] 按鈕。 按兩下按鈕會將作業設定為儘快執行。 (當然,您仍然需要可用的平行處理原則和適當的代理程式。
YAML resources
區塊中允許的範本運算式
先前,Azure Pipelines YAML 檔案的 區段中不允許resources
編譯時間表達式 (${{ }}
)。 在此版本中,我們已解除容器的這項限制。 這可讓您在資源內使用 運行時間參數 內容,例如在佇列時間挑選容器。 我們計劃隨著時間將這項支援延伸至其他資源。
控制 Marketplace 中的自動化工作更新 (機器翻譯)
當您撰寫 YAML 管線時,通常只會指定內含工作的主要版本號碼。 這可讓您的管線自動採取最新的功能新增和錯誤修正。 有時候,您可能需要回復到工作先前的點版本,而且使用此更新,我們新增了您執行這項操作的能力。 您現在可以在 YAML 管線中指定完整的 major.minor.patch 工作版本。
我們不建議您定期執行這項操作,而且只有在發現較新的工作中斷管線時,才將其作為暫時的因應措施。 此外,這不會從 Marketplace 安裝舊版的工作。 它必須已存在於您的集合中,否則您的管線將會失敗。
範例:
steps:
- task: MyTask@1 # a normal, major-version only reference
- task: MyOtherTask@2.3.4 # pinned to a precise version
代理程式和工作中的節點 10 支援
由於不再支援 Node 6,因此我們會移轉工作以使用節點 10。 針對此更新,我們已將近 50% 的現成工作移轉至節點 10。 代理程式現在可以執行節點 6 和節點 10 工作。 在未來的更新中,我們會從代理程式完全移除節點 6。 為了準備從代理程式移除 Node 6,我們要求您更新內部延伸模組和自定義工作,以儘快使用節點 10。 若要將節點 10 用於您的工作,請在 的task.json
下,從 Node
更新為 Node10
execution
。
改善傳統組建設計工具中的 YAML 轉換
在此版本中,我們會為設計工具建置管線引進新的「匯出至 YAML」功能。 儲存您的管線定義,然後在功能表上尋找 [匯出至 YAML ...
]。
新的導出函式會取代先前在傳統組建設計工具中找到的「檢視為 YAML」函式。 該函式不完整,因為它只能檢查 Web UI 對組建的瞭解,這有時會導致產生不正確的 YAML。 新的導出函式會充分考慮管線的處理方式,併產生具有設計工具管線完整精確度的 YAML。
新的 Web 平台轉換 – 存放庫設定
我們已將兩個存放庫設定頁面轉換成升級至新 Web 平臺的單一體驗。 此升級不僅可讓體驗更快速且更現代化,而且這些頁面也會針對專案層級到分支層級的所有原則提供單一進入點。
有了這個新體驗,大量存放庫的項目流覽變得更容易,因為載入時間較快,而且已新增搜尋篩選。 您也可以在 [原則] 索引卷標下檢視專案層級原則和跨存放庫原則清單。
如果您按下存放庫,您可以檢視存放庫層級所設定的原則和許可權。 在 [原則] 索引標籤,您可以檢視原則設定的每個分支清單。 現在,按兩下分支以查看原則,同時永遠不要離開存放庫設定頁面。
現在,當原則繼承自範圍高於您使用的範圍時,我們會示範原則繼承自每個個別原則旁邊的位置。 您也可以按下範圍名稱,流覽至已設定較高層級原則的頁面。
原則頁面本身也已升級至具有可折迭區段的新 Web 平臺! 為了改善尋找特定組建驗證、狀態檢查或自動檢閱者原則的體驗,我們已為每個區段新增搜尋篩選。
ServiceNow 變更管理與 YAML 管線的整合
ServiceNow 的 Azure Pipelines 應用程式可協助您整合 Azure Pipelines 和 ServiceNow 變更管理。 透過此更新,我們會開始讓 Azure Pipelines 進一步瞭解在 ServiceNow 中管理的變更管理程式,進一步移至 YAML 管線。
藉由在資源上設定 「ServiceNow 變更管理」檢查,您現在可以暫停變更以核准,再將組建部署至該資源。 您可以自動為階段建立新的變更,或等候現有的變更要求。
您也可以在伺服器作業中新增工作 UpdateServiceNowChangeRequest
,以使用部署狀態、附注等更新變更要求。
Artifacts
能夠從UI建立組織範圍的摘要
我們讓客戶能夠透過內部部署和託管服務的 Web UI 建立和管理集合範圍摘要。
您現在可以透過UI建立組織範圍的摘要,方法是移至 [成品 -> 建立摘要],然後在 [範圍] 中選擇一種摘要。
雖然我們建議使用專案範圍的摘要,以配合 Azure DevOps 供應專案的其餘部分,但您可以再次透過 UI 和各種 REST API 建立、管理及使用集合範圍的摘要。 如需詳細資訊,請參閱我們的摘要檔。
Maven 套件現可使用更新套件版本 REST API
您現在可以使用 Azure Artifacts「更新套件版本」REST API 來更新 Maven 套件版本。 先前,您可以使用 REST API 來更新 NuGet、Maven、npm 和通用套件的套件版本,但無法更新 Maven 套件。
若要更新 Maven 套件,請使用 HTTP PATCH 命令,如下所示。
PATCH
https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1
您可以設定下列各項:
URI 參數
名稱 | In | 必要 | 類型 | 說明 |
---|---|---|---|---|
artifactId | path | TRUE | 字串 | 封裝的成品標識碼 |
摘要 | path | TRUE | 字串 | 摘要的名稱或識別碼 |
groupId | path | TRUE | 字串 | 套件的群組標識碼 |
collection | path | TRUE | 字串 | Azure DevOps 集合的名稱 |
version | path | TRUE | 字串 | 套件的版本 |
專案 | path | 字串 | 項目識別碼或項目名稱 | |
api-version | query | TRUE | 字串 | 要使用的 API 版本。 這應該設定為 『5.1-preview.1』 以使用此版本的 API |
要求本文
名稱 | 類型 | 說明 |
---|---|---|
檢視表 | JsonPatchOperation | 將新增套件版本的檢視 |
如需詳細資訊,請參閱 REST API 檔 ,因為它會更新。
意見反應
我們很希望聽聽您的意見! 您可以回報問題或提供想法,並透過 開發人員社群 追蹤問題,並取得 Stack Overflow 的建議。