開發人員社群 | 系統需求 | 授權條款 | 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 15 發行日期:2025 年 3 月 11 日
檔案 | SHA-256 雜湊 |
---|---|
devops2020.1.2patch15.exe | 66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5 |
我們已針對 Azure DevOps Server 2020 Update 1.2 發行 Patch 15,包含以下內容:
- 因 Edgio CDN 淘汰而更新任務。 如需詳細資訊,請參閱 切換 CDN 提供者部落格文章。
Azure DevOps Server 2020 Update 1.2 Patch 14 Release Date:2024 年 11 月 12 日
檔案 | SHA-256 雜湊 |
---|---|
devops2020.1.2patch14.exe | 89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420 |
我們已發行適用於 Azure DevOps Server 2020 Update 1.2 的修補程式 14,其中包含升級至存在安全漏洞的相依項。
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 的 shelvesets 可及性問題
- 客戶必須在 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身分識別未出現在安全性對話身分識別選擇器的問題。
- 修正網路鉤子設定中[群組成員請求]篩選條件的問題。
- 修正當管線的組織設定已將作業授權範圍設定為限制非發行管線目前專案的作業授權範圍時,修正網關簽入組建錯誤。
- 修正當建立經過驗證的 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 引進了許多新功能。 一些重點包括:
您也可以跳至個別區段,以查看每個服務的新功能:
板
狀態轉換限制規則
我們會繼續縮小託管 XML 與繼承進程模型之間的功能同位差距。 這個新的工作項目類型規則可讓您限制工作專案從某個狀態移至另一個狀態。 例如,您可以限制 Bug 從 [新增] 移至 [已解決]。 相反地,他們必須從 [新增 - 作用中> - 已解決]>
您也可以建立規則,以依群組成員資格限制狀態轉換。 例如,只有「核准者」群組中的使用者可以將使用者故事從「新建」移動到「核准」。
複製工作專案以複製子系
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
上述程式碼段顯示,標籤可用來設定預設的 CI(持續整合)管線版本,以在 CD(持續部署)管線的執行未被其他來源/資源或排程執行觸發時使用。
例如,如果您的 CD 管線中有一個已排程的觸發條件,並且只希望在 CI 具有生產標籤時執行,則觸發條件區段中的標籤會確保只有當 CI 完成事件符合標籤條件時,CD 管線才會被觸發。
控制管線中允許的工作
您現在可以停用 Marketplace 任務。 有些人可能允許 Marketplace 擴充功能,但不允許其帶來的 Pipeline 任務。 為了更進一步的控制,我們也允許您獨立停用所有內建工作(除了結帳,這是一個特殊動作)。 啟用這兩個設定后,唯一允許在管線中執行的工作就是使用 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 - “https://dev.azure.com/<ADO 集合>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview”
- 秘密 - 這是選擇性的。 如果您需要保護您的 JSON 承載,請提供 秘密 值
建立新的「傳入 Webhook」服務連線。 這是新引進的服務連線類型,可讓您定義三個重要資訊:
- Webhook 名稱:此名稱應與您在外部服務中建立的 Webhook 相符。
- HTTP 標頭 - 要求中 HTTP 標頭 的名稱,其中包含要求驗證的承載哈希值。 例如,在 GitHub 的情況下,要求標頭會是 “X-Hub-Signature”
- 秘密 - 秘密用來剖析用於驗證傳入要求的承載哈希(這是選擇性的)。 如果您在建立 Webhook 時使用了秘密,則必須提供相同的秘密密鑰
YAML 管線中引進名為
webhooks
的新資源類型。 若要訂閱 webhook 事件,您必須在管線中定義 webhook 資源,並將其指向 Incoming 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。 現在您可以對 https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview
執行 POST,以擷取已完成的 YAML 內容。 這個新的 API 會採用與佇列執行相同的參數,但不再需要「佇列組建」許可權。
下一步執行這項工作
您曾經有需要馬上部署的錯誤修正,但必須在CI和PR作業後面排隊等待的情況嗎? 在此版本中,我們現在可讓您提高已排入佇列作業的優先順序。 具有集區 [管理] 許可權的使用者 ,通常是集區系統管理員 ,會在作業詳細數據頁面上看到新的 [執行下一步] 按鈕。 按兩下按鈕會將作業設定為儘快執行。 (當然,您仍然需要可用的平行處理原則和適當的代理程式。
YAML resources
區塊中允許的樣板表達式
先前,編譯時間表達式(${{ }}
)是不允許出現在 Azure Pipelines YAML 檔案的 resources
區段中的。 在此版本中,我們已解除容器的這項限制。 這可讓您在資源內使用 運行時間參數 內容,例如在佇列時間挑選容器。 我們計劃隨著時間將這項支援延伸至其他資源。
控制市場中的自動任務更新
當您撰寫 YAML 管線時,通常只會指定內含工作的主要版本號碼。 這可讓您的管線自動採取最新的功能新增和錯誤修正。 有時候,您可能需要回溯到任務的先前點版本,而這次更新新增了讓您能執行此操作的功能。 您現在可以在 YAML 管線中指定完整的 major.minor.patch 工作版本。
我們不建議您經常進行此操作,僅當您發現較新的任務導致您的工作流程中斷時,才作為暫時的解決方案來使用。 此外,這將不會從市集中安裝任務的舊版本。 它必須已存在於您的集合中,否則您的管線將會失敗。
範例:
steps:
- task: MyTask@1 # a normal, major-version only reference
- task: MyOtherTask@2.3.4 # pinned to a precise version
在代理程式和任務中對 Node 10 的支援
由於不再支援 Node 6,因此我們會移轉工作以使用節點 10。 針對此更新,我們已將近 50% 的待處理任務移轉至節點 10。 代理程式現在可以執行節點 6 和節點 10 工作。 在未來的更新中,我們會從代理程式完全移除節點 6。 為了準備從代理程式移除 Node 6,我們要求您更新內部延伸模組和自定義工作,將它們也轉換為使用 Node 10。 若要將節點 10 用於您的工作,請在 的task.json
下,從 execution
更新為 Node
Node10
。
改善傳統組建設計工具中的 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
這項任務,以更新變更請求中的部署狀態、附註等信息。
文物
能夠從UI建立組織範圍的資訊流
我們正在恢復讓客戶能夠透過網站使用者介面(Web 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 | 路徑 | TRUE | 字串 | 封裝的構件識別碼 |
摘要 | 路徑 | 真實 | 字串 | 資訊源的名稱或識別碼 |
群組ID | 路徑 | TRUE | 字串 | 套件的群組標識碼 |
收藏 | 路徑 | 正確 | 字串 | Azure DevOps 集合的名稱 |
版本 | 路徑 | TRUE | 字串 | 套件的版本 |
專案 | 路徑 | 字串 | 項目識別碼或項目名稱 | |
API 版本 | 查詢 | TRUE | 字串 | 要使用的 API 版本。 這應該設定為 『5.1-preview.1』 以使用此版本的 API |
請求主體
名稱 | 類型 | 說明 |
---|---|---|
觀點 | JsonPatchOperation | 套件版本將被新增到的檢視 |
如需詳細資訊,請參閱 REST API 檔 ,因為它會更新。
意見反應
我們很希望聽聽您的意見! 您可以回報問題或提供想法,並透過 開發人員社群 追蹤問題,並取得 Stack Overflow 的建議。