Azure DevOpsServer 2020 Update 1 版本資訊

| 開發人員社群 系統需求 | 授權條款 | 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 發行日期: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 發行日期: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

  1. 請遵循 將工作上傳至專案集合檔中 的步驟,以安裝及登入 tfx-cli。

使用 TFX 更新工作

檔案 SHA-256 雜湊
Tasks20231103.zip 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5
  1. 下載並擷取 Tasks20231103.zip
  2. 將目錄變更為解壓縮的檔案。
  3. 執行下列命令以上傳工作:
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 發行日期: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 提高許可權弱點。

重要

請將修補程式部署到測試環境,並確保環境的管線如預期般運作,再將修正套用至生產環境。

注意

若要實作此修補程式的修正程式,您必須遵循幾個步驟來手動更新代理程式和工作。

安裝修補程式

  1. 下載並安裝 Azure DevOps Server 2020 Update 1.2 patch 8

更新 Azure Pipelines 代理程式

  1. 從下列位置下載代理程式: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
  2. 使用 自我裝載 Windows 代理程式檔中 概述的步驟來部署代理程式。  

注意

AZP_AGENT_DOWNGRADE_DISABLED必須設定為 「true」,以防止代理程序降級。 在 Windows 上,下列命令可用於系統管理命令提示字元,後面接著重新啟動。 setx AZP_AGENT_DOWNGRADE_DISABLED true /M

設定 TFX

  1. 請遵循 將工作上傳至專案集合檔中 的步驟,以安裝及登入 tfx-cli。

使用 TFX 更新工作

  1. 下載並擷取 Tasks_20230825.zip
  2. 將目錄變更為解壓縮的檔案。
  3. 執行下列命令以上傳工作:
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 發行日期: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 發行日期:2023 年 2 月 14 日

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

  • CVE-2023-21553:Azure DevOps Server 遠端程式代碼執行弱點
  • 已修正透過 Web UI 的擱置集輔助功能問題
  • 客戶必須在更新 Azure DevOps Server Management Console 中的 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 中特殊字元的顯示。

Gif 以示範 IndetityPicker 中的特殊字元。

  • 測試數據未遭到刪除,導致資料庫成長。 透過此修正,我們已更新組建保留期,以防止建立新的孤立測試數據。

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 發行日期:2022 年 8 月 9 日

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

  • 修正將工作專案指派給出現在不同網域中的身分識別時,識別值錯誤。

Azure DevOps Server 2020 Update 1.2 Patch 1 發行日期: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 Patch 4 發行日期:2022 年 1 月 26 日

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

  • 在工作專案中使用 @mention 控件時,不會傳送 Email 通知。
  • 慣用的電子郵件位址未在使用者配置檔中更新。 這會導致電子郵件傳送至先前的電子郵件位址。
  • 標題未顯示在 [項目摘要] 頁面中。 標頭會顯示數毫秒,然後消失。
  • Active Directory 使用者同步的改善。
  • 從log4j二進位檔中移除 jndilookup 類別,以解決 Elasticsearch 弱點。

安裝步驟

  1. 使用 Patch 4 升級伺服器。
  2. 檢查 位於 HKLM:\Software\Elasticsearch\Version的登錄值。 如果登錄值不存在,請新增字串值,並將 Version 設定為 5.4.1 (Name = Version, Value = 5.4.1) 。
  3. 執行自述檔中提供的更新命令 PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update 。 它可能會傳回警告,例如: 無法連線到遠端伺服器。 請勿關閉窗口,因為更新正在執行重試,直到完成為止。

注意

如果 Azure DevOps Server 和 Elasticsearch 安裝在不同的電腦上,請遵循下列步驟。

  1. 使用 Patch 4 升級伺服器。
  2. 檢查 位於 HKLM:\Software\Elasticsearch\Version的登錄值。 如果登錄值不存在,請新增字串值,並將 Version 設定為 5.4.1 (Name = Version, Value = 5.4.1) 。
  3. 將名為 zip C:\Program Files\{TFS Version Folder}\Search\zip 的資料夾內容複製到 Elasticsearch 遠端檔案資料夾。
  4. 在 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 包含下列的修正程式。

  • 修正具有 「Contains Words」 之查詢的工作項目宏。 先前,查詢會針對包含換行符的值傳回不正確的結果。
  • 增加 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。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 從 [新增] 限制為 [已解決]。 相反地,他們必須從 [新增 -> 作用中 -> 已解決]

img

您也可以建立規則,以依群組成員資格限制狀態轉換。 例如,只有「核准者」群組中的使用者可以從 New -> Approved 行動使用者劇本。

複製工作專案以複製子系

Azure Boards 的最上層要求功能之一,就是能夠複製也會複製子工作專案的工作專案。 我們已將新的選項新增至 [複製工作專案] 對話方塊的 [包含子工作專案]。 選取時,此選項會複製工作專案,並將所有子工作專案 (最多 100 個) 。

此頁面會顯示 Azure Boards 在複製的工作專案中包含子工作專案的新選項。

已改善已啟動和已解析欄位的規則

到目前為止, 啟動者啟動日期已解析日期和 解析日期 的規則都已經是一個老式規則。 它們只會針對系統工作項目類型進行設定,而且專屬於狀態值 「Active」 和 「Resolved」。 我們已變更邏輯,讓這些規則不再適用於特定狀態。 相反地,它們是由狀態所在) (狀態類別 (觸發。 例如,假設您在 [已解決] 類別中有「需要測試」的自定義狀態。 當工作專案從「作用中」變更為「需要測試」時,就會觸發已 解決的 ByResolved Date 規則。

這可讓客戶建立任何自定義狀態值,而且仍會產生 [ 啟動者]、[ 啟用日期]、[ 解析日期] 和 [ 解析日期 ] 字段,而不需要使用自定義規則。

項目關係人可以跨面板數據行移動工作專案

項目關係人一律能夠變更工作項目的狀態。 但是,當他們移至工作流程看板時,就無法將工作專案從一個數據行移到另一個數據行。 相反地,專案關係人必須一次開啟每個工作專案,並更新狀態值。 這一點對客戶而言很長,我們很高興宣佈您現在可以跨面板數據行移動工作專案。

待辦專案和面板上的系統工作項目類型

現在您可以將系統工作項目類型新增至所選擇的待辦專案層級。 在過去,這些工作專案類型只能從查詢取得。

流程 工作項目類型
敏捷 問題
Scrum 阻礙
CMMI 變更要求
問題
檢閱
風險

將系統工作專案類型新增至待辦專案層級很簡單。 只要進入您的自定義程式,然後按兩下 [待辦專案層級] 索引標籤。選取您選擇的待辦專案層級 (範例:需求待辦專案) 並選擇 編輯選項。 然後新增工作項目類型。

積壓

Azure Boards 引發 GitHub 應用程式存放庫限制

GitHub Marketplace 中 Azure Boards 應用程式的存放庫限制已從 100 增加到 250。

合併提取要求時自定義工作項目狀態

並非所有工作流程都相同。 有些客戶想要在提取要求完成時關閉其相關工作專案。 其他人想要在關閉之前,將工作項目設定為另一個要驗證的狀態。 我們應該允許這兩者。

我們有一項新功能,可讓您在合併和完成提取要求時,將工作項目設定為所需的狀態。 若要這樣做,我們會掃描提取要求描述,並尋找狀態值,後面接著工作專案 () #mention。 在此範例中,我們會將兩個用戶劇本設定為 [已解決] 和 [關閉兩個工作]。

work-item-state

您現在可以將工作專案連結至組建、在組建中找到或整合建置,輕鬆地追蹤專案之間的組建相依性。

連結工作專案

編輯說明 (系統欄位上的說明文字)

您一律能夠編輯自定義欄位的描述。 但對於優先順序、嚴重性和活動等系統字段,無法編輯描述。 這是託管 XML 與 Inherited 之間的功能差距,可防止某些客戶移轉至繼承的模型。 您現在可以編輯系統欄位的描述。 編輯的值只會影響進程和該工作專案類型的該欄位。 這可讓您彈性地針對不同工作項目類型上的相同欄位有不同的描述。

編輯描述

合併提取要求時自定義工作項目狀態

提取要求通常是指多個工作專案。 當您建立或更新提取要求時,您可能會想要關閉其中一些要求、解決其中一些要求,並讓其餘部分保持開啟。 您現在可以使用下圖所示的批註來完成此動作。 如需 詳細資訊,請參閱檔

自訂狀態

工作面板上的父欄位

由於熱門要求,您現在可以將 [父] 字段新增至 [工作面板] 上的子卡片和父卡片。

父欄位工作面板

拿掉 Bug 工作項目類型的「指派給」規則

Agile、Scrum 和 CMMI 中所有不同工作項目類型都有數個隱藏的系統規則。 這些規則已存在 10 年以上,且通常可正常運作,而不需要任何抱怨。 不過,有幾個規則已用盡其歡迎。 其中一項規則特別導致新客戶和現有客戶感到許多困難,我們決定要移除它。 此規則存在於敏捷式程式中的 Bug 工作項目類型上。

「將狀態變更為已解決時,將 [指派的值] 設定為 [建立者]

我們收到關於此規則的許多意見反應。 為了回應,我們繼續進行,並從敏捷式程式中的 Bug 工作項目類型中移除此規則。 這項變更會影響使用繼承的 Agile 或自定義繼承的 Agile 程式的每個專案。 對於喜歡和依賴此目前規則的客戶,請參閱我們的 部落格文章 ,以瞭解您可以使用自定義規則重新新增規則所採取的步驟。

已移除 [工作專案] 頁面上的專案

[ 工作專案] 頁面 是一個很好的位置,可快速尋找您所建立或指派給您的專案,以及其他專案。 它提供數個個人化樞紐和篩選。 「指派給我」樞紐的其中一大抱怨,就是它會顯示 [已移除的工作專案] (,也就是處於 [已移除] 狀態的工作專案) 。 我們同意! 已移除的專案是不再值的工作,因此已從待辦專案中移除,因此在此檢視中包含它並不實用。

您現在可以在 [工作專案] 頁面上,從 [指派給我] 樞紐中隱藏所有已移除的專案。

Repos

默認分支名稱喜好設定

Azure Repos 現在提供 Git 的可自定義預設分支名稱。 在存放庫設定中,您可以選擇在初始化存放庫時使用的任何合法分支名稱。 Azure Repos 一律支援變更現有存放庫的預設分支名稱。 如需詳細資訊,請造訪 管理分支

 default-branch-name

注意:如果您未啟用此功能,您的存放庫將會以 Azure Repos 的預設名稱初始化。 現在,該預設值為 master。 為了遵守 Microsoft 的承諾,以及客戶對包容性語言的要求,我們將加入 業界對等, 將這個預設值變更為 main。 此變更將於此年晚發生。 如果您想要繼續使用 圖形,您應該立即開啟此功能,並將它設定為 master

默認分支的組織層級設定

現在有新存放庫慣用初始分支名稱的集合層級設定。 如果專案尚未選擇初始分支名稱,則會使用此組織層級設定。 如果您未在組織設定或項目設定中指定初始分支名稱,則新的存放庫會使用 Azure DevOps 定義的預設值。

組織層級的分支設定

新增用於參與PR批注的新驗證範圍

此版本新增了讀取/寫入提取要求批注的新 OAuth 範圍。 如果您有只需要與批注互動的 Bot 或自動化,您可以只提供具有此範圍的 PAT。 如果自動化有 Bug 或令牌遭到入侵,此程式就會減少快射半徑。

提取要求體驗改善

已使用下列專案改善新的提取要求體驗:

  • 讓選擇性檢查更可見

客戶會使用選擇性檢查來吸引開發人員注意潛在問題。 在先前的體驗中,這些檢查失敗時會很明顯。 不過,這不是預覽體驗中的案例。 必要檢查上的大綠色複選標記會遮罩選擇性檢查中的失敗。 使用者只能藉由開啟檢查面板來發現選擇性檢查失敗。 當沒有問題指示時,開發人員通常不會這麼做。 在此部署中,我們已在摘要中顯示選擇性檢查的狀態。


顯示選擇性檢查


  • 在功能表項上按兩下 Ctrl 鍵

PR 上的索引標籤表不支援按 Ctrl 鍵。 使用者通常會在檢閱提取要求時開啟新的瀏覽器索引標籤。 這個問題已經修正。

  • [+] 批注的位置

PR 中的檔案樹狀結構清單會顯示註釋 [+],以協助作者和檢閱者識別新的檔案。 由於批注是在省略號之後,因此通常不會顯示較長的檔名。


顯示批注的位置

  • PR 更新下拉式清單重新取得計時資訊

選取更新和比較PR中檔案的下拉式清單遺失預覽體驗中的重要元素。 未顯示該更新的時機。 這個問題已經修正。


PR 更新下拉式清單遺漏計時資訊

  • **改善的批注篩選配置 **

篩選提取要求的摘要頁面上的批注時,下拉式清單位於右側,但文字靠左對齊。 這個問題已經修正。


改善的批注篩選配置

  • 流覽至父系認可

在 [認可] 頁面上,您可以比較特定認可中所做的變更與其父認可。 不過,您可能想要巡覽至父認可,並進一步了解該認可與自己的父系有何不同。 當您想要瞭解版本中的所有變更時,通常需要這樣做。 我們已將父 () 卡新增至認可,以協助您達成此目標。


流覽至父認可

  • [PR 檔案] 索引標籤中具有長名稱的資料夾和檔案空間

由於檔案樹狀結構中缺少水準間距,所以已截斷具有長名稱的資料夾和檔案。 我們已藉由修改樹狀結構縮排來比對根節點,並從頁面隱藏省略號按鈕,以復原樹狀結構中的一些額外空間,但暫留時除外。

新檔案樹狀結構的影像:


資料夾和檔案的更多空間

將滑鼠停留在目錄上方時,檔案樹狀結構的影像:


名稱顯示

  • 在 [PR 檔案] 索引卷標中調整差異窗格的大小時保留卷動位置

在 [PR 檔案] 索引卷標中調整並存差異窗格的大小時,使用者的捲動位置將會遺失。 此問題已修正;用戶捲動位置現在會保留在差異窗格重設大小上。

  • 在行動裝置上搜尋認可

在行動裝置上檢視 [認可] 頁面時,新體驗中缺少搜尋方塊。 因此,您很難依其哈希尋找認可,並加以開啟。 現在已修正此問題。


在行動裝置上搜尋認可

  • 改善新 PR 檔案差異行動檢視的空間使用量

我們已更新此頁面以更妥善地使用空間,讓使用者可以在行動檢視中看到更多檔案,而不是讓標頭佔用 40% 的螢幕。


改善空間新 PR 檔名的使用方式

  • PR 摘要檢視中的增強影像

PR 中編輯的影像未顯示在PR摘要檢視中,但已在PR檔案檢視中正確顯示。 這個問題已經解決。

  • 建立新 PR 時的增強分支體驗

在此更新之前,此體驗並不理想,因為它會比較變更與存放庫的預設分支,而不是 compare 分支。


分支體驗增強功能

Pipelines

其他代理程序平臺:ARM64

我們已將Linux/ARM64新增至 Azure Pipelines 代理程式支援的平台清單。 雖然程式代碼變更很小,但許多幕後工作必須先完成,而且我們很高興宣佈其發行!

管線資源的標籤篩選支援

我們現在已在 YAML 管線中新增 「標記」。 您可以使用標記來設定要執行的 CI 管線,或在何時自動觸發。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    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管線設定排程觸發程式,而您的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 觸發程式的步驟:

  1. 在您的外部服務上設定 Webhook。 建立 Webhook 時,您需要提供下列資訊:

    • 要求 URL - “https://dev.azure.com/<ADO 集合>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview”
    • 秘密 - 這是選擇性的。 如果您需要保護 JSON 承載,請提供 秘密
  2. 建立新的「傳入 Webhook」服務連線。 這是新引進的服務連線類型,可讓您定義三個重要資訊片段:

    • Webhook 名稱:Webhook 的名稱應該符合在外部服務中建立的 Webhook。
    • HTTP 標頭 - 要求中包含要求驗證承載哈希值之 HTTP 標頭的名稱。 例如,在 GitHub 的情況下,要求標頭會是 “X-Hub-Signature
    • 秘密 - 秘密是用來剖析用於驗證傳入要求之承載哈希, (這是選擇性) 。 如果您在建立 Webhook 時使用了秘密,則必須提供相同的秘密密鑰

    在 [編輯服務連線] 頁面中,設定 Webhook 觸發程式。

  3. 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}}
  1. 每當傳入 Webhook 服務連線收到 Webhook 事件時,所有訂閱 Webhook 事件的管線都會觸發新的執行。

YAML 資源觸發程式問題支援和可追蹤性

當管線觸發程式無法如預期般執行時,可能會造成混淆。 為了協助進一步了解,我們已在管線定義頁面中新增名為「觸發程序問題」的新功能表項,其中會顯示有關觸發程式執行原因的資訊。

資源觸發程式可能會因為兩個原因而無法執行。

  1. 如果所提供的服務連線來源無效,或觸發程式中有任何語法錯誤,則完全不會設定觸發程式。 這些會顯示為錯誤。

  2. 如果觸發條件不相符,則不會執行觸發程式。 每當發生這種情況時,就會顯示警告,讓您了解條件未相符的原因。

    此稱為 「觸發程式問題」的管線定義頁面會顯示觸發程式未執行的原因相關信息。

多重存放庫觸發程式

您可以在一個 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

如果有任何更新,將會觸發此範例中的管線:

  • mainself存放庫中包含 YAML 檔案的分支
  • mainrelease 存放庫中的 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 管線時,通常只會指定內含工作的主要版本號碼。 這可讓您的管線自動取得最新的功能新增和 Bug 修正。 有時候,您可能需要回復到先前的工作點版本,而透過此更新,我們新增了您這麼做的能力。 您現在可以在 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,因此我們會移轉工作以使用 Node 10。 針對此更新,我們已將幾乎 50% 的內建工作移轉至節點 10。 代理程式現在可以同時執行節點 6 和節點 10 工作。 在未來的更新中,我們會從代理程式完全移除 Node 6。 為了準備從代理程式移除 Node 6,我們要求您更新內部延伸模組和自定義工作,以便儘快使用 Node 10。 若要將 Node 10 用於您的工作,請在 task.json的下 execution,從 Node 更新為 Node10

改善傳統組建設計工具中的 YAML 轉換

在此版本中,我們會為設計工具建置管線引進新的「匯出至 YAML」功能。 儲存管線定義,然後在功能表上尋找 [匯出至 YAML ... ]。

新的導出函式會取代先前在傳統組建設計工具中找到的「檢視為 YAML」函式。 該函式不完整,因為它只能檢查 Web UI 知道有關組建的內容,這有時會導致產生不正確的 YAML。 新的導出函式會確切考慮管線的處理方式,併產生具有設計工具管線完整精確度的 YAML。

新的 Web 平台轉換 – 存放庫設定

我們已將這兩個存放庫設定頁面轉換成升級至新 Web 平臺的單一體驗。 此升級不僅讓體驗更快速且更現代化,也會為專案層級到分支層級的所有原則提供單一進入點。

新的 Web 平台轉換。

有了這個新體驗,具有大量存放庫的項目流覽會變得更容易,因為載入時間和新增的搜尋篩選。 您也可以在 [原則] 索引卷標下檢視專案層級原則和跨存放庫原則的清單。

在 [原則] 索引卷標下檢視跨存放庫原則。

如果您按下存放庫,您可以檢視存放庫層級所設定的原則和許可權。 在 [原則] 索引標籤,您可以檢視原則設定的每個分支清單。 現在,按兩下分支即可查看所有原則,而永遠不要離開 [存放庫設定] 頁面。

選取分支以查看原則。

現在,當原則繼承自比您使用範圍更高的範圍時,我們會向您顯示原則繼承自每個個別原則旁的位置。 您也可以按下範圍名稱,流覽至已設定較高層級原則的頁面。

顯示原則繼承自何處。

原則頁面本身也已升級至具有可折迭區段的新 Web 平臺! 為了改善尋找特定組建驗證、狀態檢查或自動檢閱者原則的體驗,我們已為每個區段新增搜尋篩選。

每個區段的搜尋篩選。

ServiceNow 變更管理與 YAML 管線整合

適用於 ServiceNow 的 Azure Pipelines 應用程式可協助您整合 Azure Pipelines 和 ServiceNow 變更管理。 透過此更新,我們將瞭解 Azure Pipelines 進一步瞭解在 ServiceNow 中管理的變更管理程式至 YAML 管線。

藉由在資源上設定「ServiceNow 變更管理」檢查,您現在可以暫停變更以供核准,再將組建部署至該資源。 您可以為階段自動建立新的變更,或等候現有的變更要求。


ServiceNow 變更管理整合

您也可以在伺服器作業中新增工作 UpdateServiceNowChangeRequest ,以使用部署狀態、附注等更新變更要求。

Artifacts

能夠從UI建立組織範圍的摘要

我們讓客戶能夠透過內部部署和託管服務的 Web UI 來建立和管理集合範圍的摘要。

您現在可以透過UI建立組織範圍的摘要,方法是移至 [成品 -> 建立摘要],然後選擇 [範圍] 內的摘要類型。

選取 [成品]、[建立摘要],然後在 [範圍] 內選取摘要類型,以建立集合範圍的摘要。

雖然我們建議使用專案範圍的摘要與其餘 Azure DevOps 供應專案一致,但您可以再次透過 UI 和各種 REST API 來建立、管理及使用集合範圍摘要。 如需詳細資訊,請參閱我們的摘要檔。

更新套件版本 REST API 現在適用於 Maven 套件

您現在可以使用 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 參數

名稱 位置 必要 類型 描述
artifactId path TRUE 字串 封裝的成品標識碼
饋送 path TRUE 字串 摘要的名稱或識別碼
groupId path TRUE 字串 封裝的群組標識碼
collection path TRUE 字串 Azure DevOps 集合的名稱
version path TRUE 字串 套件的版本
project path 字串 項目識別碼或項目名稱
api-version 查詢 TRUE 字串 要使用的 API 版本。 這應該設定為 『5.1-preview.1』 以使用此版本的 API

要求本文

名稱 類型 描述
檢視 JsonPatchOperation 將新增套件版本的檢視

如需詳細資訊,請參閱 REST API 檔 ,因為它會更新。

意見反應

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


頁面頂端