Azure DevOps Server 2020 版本資訊

| 開發人員社群 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 會根據管線層級保留原則，以不同的方式處理組建保留。 某些原則設定會導致在升級后刪除管線執行。 升級之後，不會刪除已手動保留或由發行保留的管線執行。

如需如何安全地從 2019 Azure DevOps Server 升級至 2020 Azure DevOps Server 的詳細資訊，請參閱我們的部落格文章。

Azure DevOps Server 2020 Update 0.2 Patch 6 發行日期：2023 年 11 月 14 日

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

• 擴充 PowerShell 工作允許 啟用殼層工作自變數參數驗證的字元清單。

注意

若要實作此修補程式的修正程式，您必須遵循數個步驟來手動更新工作。

安裝修補程式

重要

我們在 2023 年 9 月 12 日發行的 Azure Pipelines 代理程式發行了修補程式 4 的更新。 如果您未如 修補程式 4 的版本資訊中所述安裝代理程式更新，建議您先安裝這些更新，再安裝 Patch 6。 安裝 Patch 4 之後的新版本代理程式將會是 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 0.2 Patch 5 發行日期：2023 年 10 月 10 日

重要

我們在 2023 年 9 月 12 日發行的 Azure Pipelines 代理程式發行了修補程式 4 的更新。 如果您未如 修補程式 4 的版本資訊中所述安裝代理程式更新，建議您先安裝這些更新，再安裝 Patch 5。 安裝 Patch 4 之後的新版本代理程式將會是 3.225.0。

我們已發行 Azure DevOps Server 2020 Update 0.2 的修補程式，其中包含下列的修正程式。

• 已修正「分析擁有者」身分識別在修補程式升級計算機上顯示為非使用中身分識別的錯誤。

Azure DevOps Server 2020 Update 0.2 Patch 4 發行日期：2023 年 9 月 12 日

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

• CVE-2023-33136：Azure DevOps Server 遠端程式代碼執行弱點。
• CVE-2023-38155：Azure DevOps Server 和 Team Foundation Server 提高許可權弱點。

重要

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

注意

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

安裝修補程式

1. 下載並安裝 Azure DevOps Server 2020 Update 0.2 修補程式 4。

更新 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 0.2 Patch 3 發行日期：2023 年 8 月 8 日

我們已發行 Azure DevOps Server 2020 Update 0.2 的修補程式，其中包含下列的修正程式。

• 已修正從 2018 或更早版本升級時干擾推送套件的錯誤。

Azure DevOps Server 2020 Update 0.2 Patch 2 發行日期：2023 年 6 月 13 日

我們已發行 Azure DevOps Server 2020 Update 0.2 的修補程式，其中包含下列的修正程式。

• 已修正從 2018 或更早版本升級時干擾推送套件的錯誤。

Azure DevOps Server 2020 Update 0.2 Patch 1 發行日期：2022 年 10 月 18 日

我們已發行 Azure DevOps Server 2020 Update 0.2 的修補程式，其中包含下列的修正程式。

• 解決新增的 AD 身分識別未出現在安全性對話方塊身分識別選擇器的問題。
• 修正 Web 攔截設定中群組成員要求的問題。
• 修正當管線的組織設定已將作業授權範圍設定為將非發行管線的作業授權範圍限製為目前專案時，修正閘道簽入組建錯誤。

Azure DevOps Server 2020.0.2 發行日期：2022 年 5 月 17 日

Azure DevOps Server 2020.0.2 是錯誤修正的匯總。 您可以直接安裝 Azure DevOps Server 2020.0.2 或從 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更新版本升級。

注意

此版本之後，數據遷移工具將可供 Azure DevOps Server 2020.0.2 約三周使用。 您可以在這裡查看我們目前支援匯入的版本清單。

此版本包含下列專案的修正：

• 無法使用 [執行下一步] 按鈕略過建置佇列。 先前，僅針對專案集合管理員啟用 [執行下一步] 按鈕。

• 停用使用者的 Active Directory 帳戶之後，撤銷所有個人存取令牌。

Azure DevOps Server 2020.0.1 修補程式 9 發行日期：2022 年 1 月 26 日

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

• 使用工作專案中的控件時@mention，不會傳送 Email 通知。
• 修正切換帳戶時發生TF400813錯誤。 從 TFS 2018 升級至 Azure DevOps Server 2020.0.1 時發生此錯誤。
• 修正無法載入 [專案概觀摘要] 頁面的問題。
• Active Directory 使用者同步的改善。
• 從log4j二進位檔中移除 jndilookup 類別，以解決 Elasticsearch 弱點。

安裝步驟

1. 使用 Patch 9 升級伺服器。
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 9 升級伺服器。
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 哈希： B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Azure DevOps Server 2020.0.1 修補程式 8 發行日期：2021 年 12 月 15 日

Azure DevOps Server 2020.0.1 的修補程式 8 包含下列的修正程式。

• 自訂工作專案版面配置狀態的當地語系化問題。
• 電子郵件通知範本中的當地語系化問題。
• 當數據列中有多個相同的連結時，控制台記錄會遭到截斷的問題。
• 針對欄位定義多個 NOTSAMEAS 規則時，NOTSAMEAS 規則評估的問題。

Azure DevOps Server 2020.0.1 修補程式 7 發行日期：2021 年 10 月 26 日

Azure DevOps Server 2020.0.1 的修補程式 7 包含下列的修正程式。

• 先前，Azure DevOps Server 只能建立 GitHub Enterprise Server 的連線。 透過此修補程式，專案管理員可以在 GitHub.com 上建立 Azure DevOps Server 與存放庫之間的連線。 您可以在 [項目設定] 下的 [GitHub 連線] 頁面中找到此設定。
• 解決測試計劃小工具的問題。 測試執行報告在結果上顯示不正確的使用者。
• 修正無法載入 [專案概觀摘要] 頁面的問題。
• 修正未傳送電子郵件以確認產品升級的問題。

Azure DevOps Server 2020.0.1 Patch 6 發行日期：2021 年 9 月 14 日

Azure DevOps Server 2020.0.1 的修補程式 6 包含下列的修正程式。

• 修正成品下載/上傳失敗。
• 解決測試結果數據不一致的問題。

Azure DevOps Server 2020.0.1 修補程式 5 發行日期：2021 年 8 月 10 日

Azure DevOps Server 2020.0.1 的修補程式 5 包含下列的修正程式。

• 修正組建定義UI錯誤。
• 已變更瀏覽歷程記錄以顯示檔案，而不是根存放庫。
• 修正某些工作專案類型的電子郵件傳遞工作問題。

Azure DevOps Server 2020.0.1 修補程式 4 發行日期：2021 年 6 月 15 日

Azure DevOps Server 2020.0.1 的修補程式 4 包含下列的修正程式。

• 修正數據匯入的問題。 數據匯入對於有許多過時測試案例的客戶而言，花費很長的時間。 這是因為參考會增加數據表的大小 tbl_testCaseReferences 。 在此修補程式中，我們已移除過時測試案例的參考，以協助加速數據匯入程式。

Azure DevOps Server 2020.0.1 Patch 3 發行日期：2021 年 5 月 11 日

我們已發行修正下列專案的 Azure DevOps Server 2020.0.1 修補程式。

• 使用 Microsoft.TeamFoundation.TestManagement.Client 時的測試結果數據不一致。

如果您有 Azure DevOps Server 2020.0.1，您應該安裝 Azure DevOps Server 2020.0.1 Patch 3。

驗證安裝

• 選項 1：執行 devops2020.0.1patch3.exe CheckInstall，devops2020.0.1patch3.exe 是從上述鏈接下載的檔案。 命令的輸出會指出已安裝修補程式，或未安裝。

• 選項 2：檢查下列檔案的版本： [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll。 預設會安裝 c:\Program Files\Azure DevOps Server 2020 Azure DevOps Server 2020.0.1。 安裝 Azure DevOps Server 2020.0.1 Patch 3 之後，版本將會是 18.170.31228.1。

Azure DevOps Server 2020.0.1 修補程式 2 發行日期：2021 年 4 月 13 日

注意

如果您有 Azure DevOps Server 2020，您應該先更新為 Azure DevOps Server 2020.0.1 。 在 2020.0.1 上之後，請安裝 Azure DevOps Server 2020.0.1 Patch 2

我們已發行修正下列專案的 Azure DevOps Server 2020.0.1 修補程式。

• CVE-2021-27067：資訊洩漏
• CVE-2021-28459：提高許可權

若要實作此修補程式的修正程式，您必須遵循下列步驟進行 一般修補程式安裝、 AzureResourceGroupDeploymentV2 和 AzureResourceManagerTemplateDeploymentV3 工作安裝。

一般修補程式安裝

如果您有 Azure DevOps Server 2020.0.1，您應該安裝 Azure DevOps Server 2020.0.1 Patch 2。

驗證安裝

• 選項 1：執行 devops2020.0.1patch2.exe CheckInstall，devops2020.0.1patch2.exe 是從上述鏈接下載的檔案。 命令的輸出會指出已安裝修補程式，或未安裝。

• 選項 2：檢查下列檔案的版本： [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll。 預設會安裝 c:\Program Files\Azure DevOps Server 2020 Azure DevOps Server 2020.0.1。 安裝 Azure DevOps Server 2020.0.1 Patch 2 之後，版本會是 18.170.31123.3。

AzureResourceGroupDeploymentV2 工作安裝

注意

下列所有步驟都必須在 Windows 電腦上執行

安裝

1. 將 AzureResourceGroupDeploymentV2.zip 套件解壓縮到您電腦上的新資料夾。 例如： D：\tasks\AzureResourceGroupDeploymentV2。

2. 下載並安裝 Node.js 14.15.1 和 npm (，Node.js 根據您的計算機下載) 。

3. 在系統管理員模式中開啟命令提示字元，然後執行下列命令以安裝 tfx-cli。

npm install -g tfx-cli

4. Create 具有完整訪問許可權的個人存取令牌，並加以複製。 執行 tfx 登入 命令時，將會使用此個人存取令牌。

5. 從命令提示字元執行下列命令。 出現提示時，請輸入 [服務 URL] 和 [個人存取令牌]。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. 執行下列命令，在伺服器上上傳工作。 使用步驟 1 中擷取 .zip 檔案的路徑。

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

AzureResourceManagerTemplateDeploymentV3 工作安裝

注意

下列所有步驟都必須在 Windows 電腦上執行

安裝

1. 將 AzureResourceManagerTemplateDeploymentV3.zip 套件解壓縮到您電腦上的新資料夾。 例如：D：\tasks\AzureResourceManagerTemplateDeploymentV3。

2. 下載並安裝 Node.js 14.15.1 和 npm (隨附於 Node.js 下載) ，適用於您的電腦。

3. 在系統管理員模式中開啟命令提示字元，然後執行下列命令以安裝 tfx-cli。

npm install -g tfx-cli

4. Create 具有完整訪問許可權的個人存取令牌，並加以複製。 執行 tfx 登入 命令時，將會使用此個人存取令牌。

5. 從命令提示字元執行下列命令。 出現提示時，請輸入服務 URL 和個人存取令牌。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. 執行下列命令，在伺服器上上傳工作。 使用從步驟 1 擷取 .zip 檔案的路徑。

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2020.0.1 修補程式 1 發行日期：2021 年 2 月 9 日

我們已針對修正下列各項的 Azure DevOps Server 2020.0.1 發行修補程式。 如需詳細資訊，請參閱部落格文章。

• 解決此 開發人員社群 意見反應票證中回報的問題 |[新增測試案例] 按鈕無法運作
• 包含 Azure DevOps Server 2020 修補程式 2 發行的修正程式。

Azure DevOps Server 2020 修補程式 3 發行日期：2021 年 2 月 9 日

我們已針對修正下列各項的 Azure DevOps Server 2020 發行修補程式。 如需詳細資訊，請參閱部落格文章。

• 解決此 開發人員社群 意見反應票證中回報的問題 |[新增測試案例] 按鈕無法運作

Azure DevOps Server 2020.0.1 發行日期：2021 年 1 月 19 日

Azure DevOps Server 2020.0.1 是錯誤修正的匯總。 您可以直接安裝 Azure DevOps Server 2020.0.1 或從現有的安裝升級。 升級的支援版本 Azure DevOps Server 2020、Azure DevOps Server 2019 和 Team Foundation Server 2012 或更新版本。

此版本包含下列 Bug 的修正：

• 解決從 Azure DevOps Server 2019 升級的問題，其中 Git Proxy 可能會在升級后停止運作。
• 在 Team Foundation Server 2017 升級至 Azure DevOps Server 2020 時，修正 Team Foundation Server 2017 之前非 ENU 集合的 System.OutOfMemoryException 例外狀況。 解決此 開發人員社群 意見反應票證中回報的問題。
• 因為遺漏 Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll 所造成的服務失敗。 解決此 開發人員社群 意見反應票證中回報的問題。
• 在升級至 Azure DevOps Server 2020 時，修正 Analytics 中無效的數據行名稱錯誤。 解決此 開發人員社群 意見反應票證中回報的問題。
• 在測試案例結果中顯示測試案例步驟時，儲存的 XSS。
• 將點數結果數據遷移至 TCM 時，升級步驟失敗。

Azure DevOps Server 2020 修補程式 2 發行日期：2021 年 1 月 12 日

我們已針對修正下列各項的 Azure DevOps Server 2020 發行修補程式。 如需詳細資訊，請參閱部落格文章。

• 測試回合詳細數據不會針對使用 OpsHub 移轉所移轉的測試數據顯示測試步驟詳細數據
• 'Microsoft.TeamFoundation.TestManagement.Server.TCMLogger' 初始化表達式的例外狀況
• 移轉至 Azure DevOps Server 2020 之後，會立即刪除未執行的組建
• 修正數據提供者例外狀況

Azure DevOps Server 2020 修補程式 1 日期：2020 年 12 月 8 日

我們已針對修正下列各項的 Azure DevOps Server 2020 發行修補程式。 如需詳細資訊，請參閱部落格文章。

• CVE-2020-17145：Azure DevOps Server 和 Team Foundation Services 詐騙弱點

Azure DevOps Server 2020 年 10 月 6 日發行日期：2020 年 10 月 6 日

Azure DevOps Server 2020 是錯誤修正的匯總。 其中包含先前發行 Azure DevOps Server 2020 RC2 中的所有功能。

注意

Azure DevOps 2020 Server 安裝 Git 虛擬文件系統所使用的其中一個元件 (GVFS) 時發生問題。

如果您要從 Azure DevOps 2019 升級 (任何版本) 或 Azure DevOps 2020 候選版本，並安裝至與先前版本相同的目錄，則不會安裝元件 Microsoft.TeamFoundation.Git.dll 。 您可以在和 <Install Dir>\Application Tier\TFSJobAgent<Install Dir>\Tools 資料夾中尋找 Microsoft.TeamFoundation.Git.dll<Install Dir>\Version Control Proxy\Web Services\bin，以確認已達到問題。 如果檔案遺失，您可以執行修復來還原遺失的檔案。

若要執行修復，請移至 Settings -> Apps & Features Azure DevOps Server 部機器/VM，然後在 Azure DevOps 2020 伺服器上執行修復。 修復完成後，您可以重新啟動機器/VM。

Azure DevOps Server 2020 RC2 發行日期：2020 年 8 月 11 日

Azure DevOps Server 2020 RC2 是錯誤修正的匯總。 其中包含先前發行的 Azure DevOps Server 2020 RC1 中的所有功能。

Azure DevOps Server 2020 RC1 重新發行日期：2020 年 7 月 10 日

我們已重新發行 Azure DevOps Server 2020 RC1，以修正此 開發人員社群 意見反應票證。

之前，從 Azure DevOps Server 2019 Update 1.1 升級至 Azure DevOps Server 2020 RC1 之後，您無法在 Web UI 的 Repos、Pipelines 和 Wiki 中檢視檔案。 發生錯誤訊息，指出 頁面的這個區域內發生未預期的錯誤。您可以嘗試重載此元件或重新整理整個頁面。 在此版本中，我們已修正此問題。 如需詳細資訊，請參閱部落格文章。

Azure DevOps Server 2020 RC1 發行日期：2020 年 6 月 30 日

Azure DevOps Server 2020 的新功能摘要

Azure DevOps Server 2020 引進許多新功能。 一些重點包括：

• 多階段管線
• YAML 中的持續部署
• 使用面板待辦項目匯總來追蹤父項目的進度
• 將 「父工作專案」篩選新增至工作面板和短期衝刺待辦專案
• Azure Repos 登陸頁面的新 Web UI
• 跨存放庫分支原則管理
• 新增測試計劃頁面
• 程式代碼Wiki頁面的豐富編輯
• 管線失敗和持續時間報告

您也可以跳到個別區段，以查看每個服務的新功能：

• 一般
• Boards
• Repos
• 管線
• Test Plans
• 成品
• Wiki
• 報告

---

一般

Azure DevOps CLI 正式運作

在 2 月，我們引進了適用於 Azure CLI 的 Azure DevOps 擴充功能。 擴充功能可讓您從命令行與 Azure DevOps 互動。 我們已收集您的意見反應，協助我們改善擴充功能並新增更多命令。 我們現在很滿意地宣佈擴充功能已正式推出。

若要深入瞭解 Azure DevOps CLI，請參閱 這裡的檔。

使用發佈配置檔從部署中心部署適用於 Windows 的 Azure WebApps

現在，您可以使用發佈配置檔型驗證，從部署中心部署適用於 Windows 的 Azure WebApps。 如果您有權使用其發佈配置檔部署至適用於 Windows 的 Azure WebApp，您可以在部署中心工作流程中使用此設定檔來設定管線。

Boards

將 「父工作專案」篩選新增至工作面板和短期衝刺待辦專案

我們已將新的篩選新增至短期衝刺面板和短期衝刺待辦專案。 這可讓您依父系篩選需求層級待辦專案 (左側) 的第一個數據行。 例如，在下面的螢幕快照中，我們已篩選檢視，只顯示父系為「我的大功能」的用戶劇本。

改善錯誤處理體驗 – 錯誤/任務的必要欄位

在過去，從 Kanban 面板將工作專案從一個數據行移至另一個數據行，其中狀態變更觸發欄位規則，卡片只會顯示紅色錯誤訊息，以強制開啟工作專案以瞭解根本原因。 在短期衝刺 170 中，我們已改善體驗，讓您現在可以按兩下紅色錯誤訊息來查看錯誤的詳細數據，而不需要開啟工作專案本身。

工作項目即時重載

先前，更新工作專案，而第二個小組成員對相同的工作專案進行變更時，第二位使用者將會失去其變更。 現在，只要您同時編輯不同的欄位，您就會看到對工作專案所做的變更即時更新。

從命令行管理反覆項目和區域路徑

您現在可以使用 和 az boards area 命令，從命令行az boards iteration管理反覆專案和區域路徑。 例如，您可以從 CLI 以互動方式設定和管理反覆項目和區域路徑，或使用腳本將整個設定自動化。 如需命令和語法的詳細資訊，請參閱 這裡的檔。

工作專案父數據行做為數據行選項

您現在可以選擇在產品待辦專案或短期衝刺待辦專案中查看每個工作專案的父代。 若要啟用此功能，請移至所需待辦專案的數據行 選項 ，然後新增 父數據 行。

變更專案所使用的程式

您的工具應該隨著小組所做的變更，您現在可以將專案從任何現成可用的進程範本切換至任何其他現成的處理程式。 例如，您可以將專案從使用 Agile 變更為 Scrum，或將基本變更為 Agile。 您可以 在這裡找到完整的逐步檔。

隱藏版面配置中的自定義欄位

您現在可以在自定義程式時，從表單配置中隱藏自訂欄位。 欄位仍可從查詢和 REST API 取得。 當您與其他系統整合時，這很適合用來追蹤額外的欄位。

使用三個新的 Azure Boards 報告，深入瞭解小組的健康情況

您無法修正無法看到的內容。 因此，您想要密切注意其工作程序的狀態和健康情況。 透過這些報告，我們會讓您更輕鬆地追蹤重要計量，並盡可能減少 Azure Boards。

這三個新的互動式報告包括： 待處理、 累積流程圖 (CF) 和 速度。 您可以在新的分析索引標籤中看到報告。

短期衝刺待用、工作流程和小組速度等計量可讓您瞭解小組的進度，並協助回答下列問題：

• 我們在此短期衝刺中留下多少工作？ 我們正在追蹤完成嗎？
• 開發程式哪一個步驟需要最長的時間？ 我們可以執行一些動作嗎？
• 根據先前的反覆項目，我們應該規劃下一個短期衝刺多少工作？

注意

先前顯示在標頭中的圖表已取代為這些增強報表。

新的報表是完全互動式的，可讓您針對您的需求進行調整。 您可以在每個中樞的 [ 分析 ] 索引標籤下找到新的報告。

• 您可以在 Sprints 中樞底下找到待用圖表。

  [分析] 索引標籤螢幕快照。

• 您可以按下相關的卡片，從 [面板] 和 [待辦專案] 底下的 [分析] 索引卷標存取CFD 和速度報告。

  [分析] 索引標籤

有了新的報表，您就有更多關於小組的控制與資訊。 這裡有一些範例：

• Sprint Burndown 和 Velocity 報表可以設定為使用工時項目計數或剩餘工時的總和。
• 您可以調整短期衝刺待用的時間範圍，而不會影響專案日期。 因此，如果您的小組通常會在每個短期衝刺規劃的第一天花費，您現在可以比對圖表來反映這一點。
• [待用] 圖表現在有顯示週末浮水印。
• CF 報表可讓您移除設計等面板數據行，以更專注於小組所控制流程。

以下是顯示過去 30 天劇本待辦專案流程之CFP 報表的範例。

現在可追蹤所有待處理專案層級的速度圖表。 例如，您現在可以同時新增 Features 和 Epics，而先前圖表之前僅支援 Requirements。 以下是功能待辦項目最後 6 個反覆專案的速度報告範例。

自訂任務板數據行

我們很高興宣佈我們新增了選項，讓您自定義Taskboard上的數據行。 您現在可以新增、移除、重新命名及重新排序數據行。

若要在任務面板上設定資料行，請移至 [ 資料行選項]。

這項功能是根據 開發人員社群 的建議來排定優先順序。

切換以顯示或隱藏待辦專案上已完成的子工作專案

許多時候，調整待辦專案時，您只想看到尚未完成的專案。 現在，您能夠顯示或隱藏待辦專案上已完成的子專案。

如果切換開啟，您會看到所有處於已完成狀態的子專案。 當切換關閉時，所有處於已完成狀態的子項目都會從待辦項目隱藏。

標記工作項目時顯示的最新標記

標記工作專案時，自動完成選項現在會顯示最多五個您最近使用的標記。 這可讓您更輕鬆地將正確的資訊新增至您的工作專案。

群組成員資格的唯讀和必要規則

工作項目規則可讓您設定工作專案欄位的特定動作，以自動化其行為。 您可以建立規則，根據群組成員資格將字段設定為唯讀或必要。 例如，您可能想要授與產品擁有者設定功能優先順序的能力，同時讓其他人成為唯讀功能。

自訂系統選擇清單值

您現在可以自定義任何系統選擇清單的值 (，但原因欄位) 例如嚴重性、活動、優先順序等。挑選清單自定義的範圍為 ，因此您可以針對每個工作項目類型管理相同欄位的不同值。

新增工作專案 URL 參數

使用我們的新工作專案 URL 參數，與面板或待辦專案內容共用工作項目的連結。 您現在可以在面板、待辦專案或短期衝刺體驗上開啟工作項目對話框，方法是將 參數 ?workitem=[ID] 附加至 URL。

您與 共用連結的任何人，都會與您共用連結時擁有的相同內容登陸！

提及文字欄位中的人員、工作專案和PR

當我們聆聽您的意見反應時，我們聽到您想要在工作專案描述區域中提及人員、工作專案和 PR 的能力， (和其他 HTML 字段) 工作專案，而不只是在批注中。 有時候您會與工作專案上的某人共同作業，或想要在工作專案描述中反白顯示 PR，但沒有方法可以新增該資訊。 現在，您可以在工作專案的所有長文字欄位中提及人員、工作專案和 PR。

您可以參閱這裡的範例。

• 若要使用人員提及，請輸入 @ 要提及的符號和人員名稱。 @mentions 在工作專案欄位中，會產生電子郵件通知，例如其對批註所做的動作。
• 若要使用工作專案提及，請輸入 # 後面接著工作專案標識碼或標題的符號。 #mentions 會建立兩個工作專案之間的連結。
• 若要使用PR提及，請新增 ！ ，後面接著您的PR標識碼或名稱。

討論批注反應

我們的主要目標之一是讓工作專案更共同作業小組。 我們最近在 Twitter 上進行了投票 ，以瞭解您想要討論工作專案的共同作業功能。 將意見反應帶入投票，因此我們會新增意見！ 以下是 Twitter 投票的結果。

您可以將反應新增至任何批註，而且有兩種方式可以新增您的反應 – 任何批註右上角的笑臉圖示，以及任何現有反應旁的批註底部。 您可以視需要新增所有六個反應，或只新增一或兩個反應。 若要移除您的反應，請按兩下批注底部的反應，並將其移除。 您可以在下方查看新增反應的體驗，以及反應在批注上的外觀。

將 Azure Boards 報表釘選到儀錶板

在短期衝刺 155 更新中，我們包含了 更新的版的CFD 和速度報告。 這些報告可在 [面板] 和 [待辦專案] 的 [分析] 索引標籤下取得。 現在您可以將報表直接釘選到儀錶板。 若要釘選報表，請將滑鼠停留在報表上，選取省略號 “...”功能表和 [複製到儀錶板]。

使用上層待辦項目匯總來追蹤父項目的進度

匯總數據行會顯示階層中數值欄位或子系項目的進度列和/或總計。 子系項目會對應至階層中所有子項目。 您可以將一或多個匯總數據行新增至產品或組合待辦專案。

例如，我們在這裡顯示 [依工作專案的進度 ]，它會根據已關閉的子代專案百分比，顯示遞增工作專案的進度列。 Epic 的子系專案包括所有子功能及其子工作專案或子系工作專案。 Features 的子系專案包含所有子用戶劇本及其子工作專案。

工作面板即時更新

您的工作面板現在會在發生變更時自動重新整理！ 當其他小組成員在工作面板上移動或重新排序卡片時，您的面板會自動更新這些變更。 您不再需要按 F5 來查看最新的變更。

支援匯總數據行中的自定義欄位

匯總現在可以在任何欄位上完成，包括自定義欄位。 新增匯總數據行時，您仍然可以從 [快速] 清單中挑選匯總數據行，不過如果您想要匯總不是現成進程範本一部分的數值欄位，您可以設定您自己的欄位，如下所示：

1. 在您的待辦專案上，按兩下 [資料行選項]。 然後在面板中按兩下 [新增匯總數據行] 並 設定自定義匯總。

   

2. 在進度列與總計之間挑選。
3. 選取工作項目類型或待辦專案層級 (通常會匯總數個工作項目類型) 。
4. 選取匯總類型。 工作專案 或 總和的計數。 針對 [總和]，您必須選取要摘要的欄位。
5. [ 確定 ] 按鈕會帶您回到數據行選項面板，您可以在其中重新排序新的自訂數據行。

請注意，按兩下 [確定] 之後，您無法編輯自訂資料行。 如果您需要進行變更，請移除自定義數據行，並視需要新增另一個數據行。

根據條件隱藏工作項目表單中欄位的新規則

我們已將新規則新增至繼承的規則引擎，讓您隱藏工作項目表單中的字段。 此規則會根據使用者群組成員資格隱藏欄位。 例如，如果使用者屬於「產品擁有者」群組，則可以隱藏開發人員特定欄位。 如需詳細資訊，請參閱 這裡的檔。

自訂工作專案通知設定

保持與您或小組相關工作專案的最新狀態非常重要。 它可協助小組共同作業並持續追蹤專案，並確保所有相關方都參與。 不過，不同的項目關係人在不同工作中有不同的投資層級，我們相信應該反映在您追蹤工作項目狀態的能力中。

之前，如果您想要追蹤工作專案並取得任何變更的通知，您會收到任何變更的電子郵件通知，以及對工作專案所做的所有變更。 考慮您的意見反應之後，我們會為所有項目關係人提供更彈性的工作專案。 現在，您會在工作專案右上角的 [ 追蹤 ] 按鈕旁邊看到新的設定按鈕。 這會帶您前往彈出視窗，讓您設定追蹤選項。

您可以從 [通知設定] 中選擇三個通知選項。 首先，您可以完全取消訂閱。 其次，您可以完整訂閱，您可以在其中取得所有工作專案變更的通知。 最後，您可以選擇取得一些最上層和重要工作專案變更事件的通知。 您可以只選取一個選項，或全部三個選項。 這可讓小組成員遵循較高層級的工作專案，而不會因為每個所做的變更而分心。 有了這項功能，我們將消除不必要的電子郵件，並讓您專注於手邊的重要工作。

將工作項目連結至部署

我們很高興在工作項目窗體上釋放部署控制件。 此控制項會將您的工作專案連結至發行，並可讓您輕鬆地追蹤工作專案已部署的位置。 若要深入瞭解，請參閱 這裡的檔。

從 CSV 檔案匯入工作專案

到目前為止，從 CSV 檔案匯入工作專案相依於使用 Excel 外掛程式。 在此更新中，我們會直接從 Azure Boards 提供第一級匯入體驗，以便匯入新的或更新現有的工作專案。 若要深入瞭解，請參閱 這裡的檔。

將父欄位新增至工作專案卡片

您的工作流程看板內現在提供父內容，作為工作專案卡片的新欄位。 您現在可以將 [父代] 字段新增至卡片，略過使用標籤和前置詞等因應措施的需求。

將父欄位新增至待辦項目和查詢

檢視待辦項目和查詢結果時，現在可以使用父欄位。 若要新增父欄位，請使用 [ 資料行選項 ] 檢視。

Repos

提取要求的程式代碼涵蓋範圍計量和分支原則

您現在可以查看提取要求 (PR) 檢視內變更的程式代碼涵蓋範圍計量。 這可確保您已透過自動化測試充分測試變更。 涵蓋範圍狀態會顯示為PR概觀中的批注。 您可以檢視檔案差異檢視中變更之每個程式代碼行的涵蓋範圍資訊詳細數據。

此外，存放庫擁有者現在可以設定程式代碼涵蓋範圍原則，並防止大型未經測試的變更合併至分支。 想要的涵蓋範圍閾值可以在儲存機制根目錄簽入的配置檔中azurepipelines-coverage.yml定義，而涵蓋範圍原則可以使用現有設定分支原則來定義 Azure Repos 中的其他服務功能。

從提取要求篩選批注通知

提取要求中的批注通常可能會因為通知而產生許多雜訊。 我們新增了自定義訂用帳戶，可讓您依批注年齡、批注器、已刪除的批註、提及的使用者、提取要求作者、目標分支和線程參與者篩選您訂閱的批注通知。 您可以按下右上角的使用者圖示並流覽至 [ 使用者設定] 來建立這些通知訂閱。

螢幕快照。

提取要求批注的服務勾點

您現在可以根據存放庫和目標分支，在提取要求中建立批注的服務勾點。

使用指定模式封鎖檔案的原則

系統管理員現在可以設定原則，以防止根據檔類型和路徑將認可推送至存放庫。 檔名驗證原則會封鎖符合所提供模式的推送。

使用關鍵詞透過認可解決工作專案

您現在可以使用 修正、 修正或 修正等關鍵詞，透過對預設分支所做的認可來解決工作專案。 例如，您可以在認可訊息中撰寫 「此變更已修正 #476」，而工作專案 #476 會在認可推送或合併至預設分支時完成。 如需詳細資訊，請參閱 這裡的檔。

自動檢閱者的數據粒度

先前，將群組層級檢閱者新增至提取要求時，新增的群組只需要一個核准。 現在，您可以設定需要小組多個檢閱者的原則，以在新增自動檢閱者時核准提取要求。 此外，您可以新增原則，以防止要求者核准自己的變更。

使用服務帳戶型驗證連線至 AKS

先前，從 AKS 部署中心設定 Azure Pipelines 時，我們使用 Azure Resource Manager 連線。 此連線可以存取整個叢集，而不只是設定管線的命名空間。 透過此更新，我們的管線會使用服務帳戶型驗證來連線到叢集，使其只能存取與管線相關聯的命名空間。

預覽提取要求中的 Markdown 檔案並存差異

您現在可以使用新的 [預覽 ] 按鈕，查看 Markdown 檔案的外觀預覽。 此外，您可以選取 [ 檢視 ] 按鈕，從並存差異查看檔案的完整內容。

手動組建的建置原則到期日

分支原則會針對小組強制執行程式碼品質和變更管理方面的標準。 先前，您可以設定自動化組建的組建到期原則。 現在，您也可以將組建到期原則設定為手動組建。

新增原則以根據認可作者電子郵件封鎖認可

系統管理員現在可以設定推送原則，以防止認可推送至認可作者電子郵件不符合所提供模式的存放庫。

這項功能是根據 開發人員社群 提供類似體驗的建議來排定優先順序。 我們會繼續讓票證保持開啟狀態，並鼓勵用戶告訴我們您想要查看的其他類型的推播原則。

將檔案標示為提取要求中檢閱

有時候，您需要檢閱包含大量檔案變更的提取要求，而且很難追蹤您已檢閱的檔案。 現在，您可以將檔案標示為提取要求中檢閱的檔案。

您可以使用檔名旁的下拉功能表，或暫留並按下檔名，將檔案標示為已檢閱。

注意

這項功能只是為了在您檢閱提取要求時追蹤進度。 它不代表對提取要求進行投票，因此檢閱者只會看到這些標記。

這項功能是根據 開發人員社群 的建議來排定優先順序。

Azure Repos 登陸頁面的新 Web UI

您現在可以在 Azure Repos 內試用我們新的新式、快速且行動裝置易用登陸頁面。 這些頁面可作為 新的存放庫登陸頁面。 登陸頁面包含提取要求詳細數據、認可詳細數據和分支比較以外的所有頁面。

Web

行動

跨存放庫分支原則管理

分支原則是 Azure Repos 功能之一，可協助您保護重要分支。 雖然在專案層級設定原則的能力存在於 REST API 中，但沒有任何使用者介面可供使用。 現在，系統管理員可以在其專案中的所有存放庫上，在特定分支或預設分支上設定原則。 例如，系統管理員可以針對在其專案中每個存放庫的每個主要分支中提出的所有提取要求，需要兩個最低檢閱者。 您可以在 Repos 項目設定中找到 [新增分支保護 ] 功能。

新的 Web 平台轉換登陸頁面

我們已更新 Repos 登陸頁面用戶體驗，使其成為現代化、快速且方便行動裝置使用。 以下是兩個已更新的頁面範例，我們將在未來的更新中繼續更新其他頁面。

Web 體驗：

行動體驗：

Kotlin 語言的支援

我們很高興宣布，我們現在支援檔案編輯器中的 Kotlin 語言醒目提示。 醒目提示可改善 Kotlin 文字檔的可讀性，並協助您快速掃描以尋找錯誤。 我們會根據 開發人員社群 的建議，排定此功能的優先順序。

草稿提取要求的自定義通知訂閱

為了協助減少提取要求的電子郵件通知數目，您現在可以為提取要求建立或更新 草稿狀態的提取要求建立或更新自定義通知訂閱。 您可以特別取得草稿提取要求的電子郵件，或從草稿提取要求篩選出電子郵件，讓您的小組在提取要求準備好檢閱之前不會收到通知。

改善 PR 可採取動作性

當您有許多提取要求要檢閱時，請先瞭解應該採取哪些動作可能很困難。 若要改善提取要求可採取動作性，您現在可以在提取要求清單頁面上建立多個自定義查詢，其中包含數個新選項來篩選，例如草稿狀態。 除了「由我建立」和「指派給我」之外，這些查詢還會在提取要求頁面上建立個別和可折疊的區段。 您也可以拒絕檢閱您透過 [投票] 功能表或提取要求清單頁面上的操作功能表新增的提取要求。 在自定義區段中，您現在會看到已開啟或拒絕檢閱之提取要求的個別索引卷標。 這些自定義查詢可在集合首頁的 [我的提取要求] 索引卷標上，跨存放庫運作。 如果您想要回到提取要求，您可以將其加上旗標，而且它們會顯示在清單頂端。 最後，已設定為自動完成的提取要求將會標示為清單中的「自動完成」。

Pipelines

多階段管線

我們已致力於 更新的用戶體驗 ，以管理您的管線。 這些更新讓管線體驗現代化且與 Azure DevOps 的方向一致。 此外，這些更新會將傳統組建管線和多階段 YAML 管線結合成單一體驗。 它適用於行動裝置，併為您管理管線的方式帶來各種改善。 您可以向下切入並檢視管線詳細數據、執行詳細數據、管線分析、作業詳細數據、記錄等等。

新體驗包含下列功能：

• 檢視和管理多個階段
• 核准管線執行
• 在管線仍在進行中時，一路捲動回記錄
• 管線的每個分支健康情況。

YAML 中的持續部署

我們很高興提供 Azure Pipelines YAML CD 功能。 我們現在提供統一的 YAML 體驗，讓您可以設定每個管線一起執行 CI、CD 或 CI 和 CD。 YAML CD 功能引進數個新的進階功能，可供所有使用多階段 YAML 管線的集合使用。 一些重點包括：

• CI 和 CD) 的多階段 YAML 管線 (
• 資源的核准和檢查
• 環境和部署策略
• 環境中的 Kubernetes 和虛擬機資源
• 檢閱應用程式以進行共同作業
• 已重新整理服務連線的UX
• YAML 管線中的資源

如果您已準備好開始建置，請參閱建置多階段 CI/CD 管線 的檔 或 部落格 。

在 YAML 編輯器中管理管線變數

我們已更新在 YAML 編輯器中管理管線變數的體驗。 您不再需要移至傳統編輯器，即可在 YAML 管線中新增或更新變數。

直接從發行中樞核准發行

對擱置核准採取行動已變得更容易。 之前，您可以從發行的詳細數據頁面核准發行。 您現在可以直接從 Releases 中樞核准發行。

開始使用管線的改善

開始使用精靈的常見要求是能夠重新命名產生的檔案。 目前，它會簽入為 azure-pipelines.yml 存放庫的根目錄。 您現在可以先將此更新為不同的檔名或位置，再儲存管線。

最後，當您將檔案簽入 azure-pipelines.yml 至不同的分支時，我們將有更多控制權，因為您可以選擇略過從該分支建立提取要求。

預覽完全剖析的 YAML 檔，而不認可或執行管線

我們已新增 預覽版，但未 針對 YAML 管線執行模式。 現在，您可以試用 YAML 管線，而不需要將它認可至存放庫或執行它。 假設現有的管線和選擇性的新 YAML 承載，這個新的 API 會為您提供完整的 YAML 管線。 在未來的更新中，此 API 將用於新的編輯器功能。

針對開發人員：使用 JSON 本文進行 POST， dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview 如下所示：

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

回應將包含轉譯的 YAML。

YAML 中的Cron排程

先前，您可以使用 UI 編輯器來指定 YAML 管線的排程觸發程式。 透過此版本，您可以在 YAML 檔案中使用 cron 語法來排程組建，並利用下列優點：

1. 設定為程式代碼：您可以將排程與管線一起追蹤為程式代碼的一部分。
2. 表達：您在定義排程時更具表達能力，比使用UI更能表達。 例如，您可以更輕鬆地指定每小時啟動執行的單一排程。
3. 業界標準：許多開發人員和系統管理員都已經熟悉 cron 語法。

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

我們也可讓您輕鬆地診斷cron排程的問題。 [執行管線] 功能表中的 [排程執行] 可讓您預覽管線即將推出的幾個排程執行，以協助您診斷 cron 排程的錯誤。

服務連線 UI 的 匯報

我們正致力於更新的用戶體驗來管理您的服務連線。 這些更新可讓服務連線體驗現代化，並與 Azure DevOps 的方向保持一致。 我們在此年稍早引進了服務連線的新UI作為預覽功能。 感謝您嘗試新體驗的每個人，並提供其寶貴的意見反應給我們。

除了用戶體驗重新整理之外，我們也新增了兩項功能，這對於在 YAML 管線中使用服務連線至關重要：管線授權和核准和檢查。

此更新 預設會開啟 新的用戶體驗。 您仍然可以退出宣告預覽。

注意

我們計劃引進跨專案共享服務 Connections 作為新功能。 您可以 在這裡找到有關共享體驗和安全性角色的詳細資訊。

略過 YAML 管線中的階段

當您啟動手動執行時，有時可能會想要略過管線中的幾個階段。 例如，如果您不想部署至生產環境，或想要略過部署到生產環境中的幾個環境。 您現在可以使用 YAML 管線來執行此動作。

更新的執行管線面板會顯示 YAML 檔案中的階段清單，而且您可以選擇略過其中一或多個階段。 在略過階段時，您必須小心。 例如，如果您的第一個階段會產生後續階段所需的特定成品，則您不應該略過第一個階段。 每當您略過具有下游相依性的階段時，執行面板就會顯示泛型警告。 不論這些相依性是真正的成品相依性，還是只是為了排序部署而存在，您還是會留下這些相依性。

略過階段相當於重新使用階段之間的相依性。 任何略過階段的直接下游相依性，都會根據略過階段的上游父系而定。 如果執行失敗，而且您嘗試重新執行失敗的階段，該嘗試也會有相同的略過行為。 若要變更略過哪些階段，您必須啟動新的執行。

服務連線新UI作為預設體驗

有新的服務連線 UI。 這個新的UI是以新式設計標準為基礎，其隨附各種重要功能，可支援多階段YAML CD管線，例如核准、授權和跨項目共用。

在這裡深入瞭解服務連線。

[建立執行] 對話框中的管線資源版本選擇器

我們已新增在 [建立執行] 對話框中手動挑選管線資源版本的功能。 如果您在另 一個管線中使用管線作為資源 ，您現在可以在建立執行時挑選該管線的版本。

az Azure Pipelines 的 CLI 改善

管線變數群組和變數管理命令

當您需要手動設定管線變數和變數群組時，將 YAML 型管線從某個專案移植到另一個專案可能很困難。 不過，使用管線 變數群組 和 變數 管理命令，您現在可以編寫管線變數和變數群組的設定和管理腳本，進而進行版本控制，讓您可以輕鬆地共用指示，以將管線從一個專案移至另一個專案。

執行PR分支的管線

建立PR時，驗證變更是否可能會中斷目標分支上的管線執行，可能會很困難。 不過，透過觸發管線執行或將PR分支的組建排入佇列的功能，您現在可以針對目標管線執行變更，以驗證和可視化進行中的變更。 如需詳細資訊 ，請參閱 az pipelines run 和 az pipelines build queue 命令檔。

略過第一個管線執行

建立管線時，有時候您想要建立並認可 YAML 檔案，而不是觸發管線執行，因為它可能會因為各種原因而造成錯誤執行 - 基礎結構尚未就緒，或需要建立和更新變數/變數群組等。使用 Azure DevOps CLI，您現在可以在建立管線時略過第一個自動化管線執行，方法是包含 --skip-first-run 參數。 如需詳細資訊，請參閱 az pipeline create 命令檔 。

服務端點命令增強功能

服務端點 CLI 命令僅支援 azure rm 和 github 服務端點的設定和管理。 不過，在此版本中，服務端點命令可讓您透過檔案提供組態來建立任何服務端點，並提供優化命令 - az devops service-endpoint github 和 az devops service-endpoint azurerm，其提供建立這些類型服務端點的第一級支援。 如需詳細資訊，請參閱 命令檔 。

部署作業

部署作業是一種特殊類型的 作業 ，可用來將應用程式部署至環境。 透過此更新，我們已新增部署作業中的 步驟參考 支援。 例如，您可以在一個檔案中定義一組步驟，並在部署作業中加以參考。

我們也已將其他屬性的支援新增至部署作業。 例如，以下是您現在可以設定之部署作業的幾個屬性。

• timeoutInMinutes - 自動取消之前執行作業的時間長度
• cancelTimeoutInMinutes - 在終止工作之前，提供「一律執行一律」的時間
• 條件 - 有條件地執行作業
• 變數 - 可以直接新增硬式編碼值，也可以直接新增 變數群組，或是參考 Azure 金鑰保存庫支援的變數群組 ，或者您可以參考 檔案中定義的一組變數。
• continueOnError - 如果未來的工作應該執行，即使此部署作業失敗也一樣;預設值為 'false'

如需部署作業和指定部署作業的完整語法的詳細資訊，請參閱 部署作業。

在 CI 管線中顯示相關聯的 CD 管線資訊

我們已將支援新增至CD YAML管線詳細數據，其中 CI 管線稱為管線資源。 在您的 CI 管線執行檢視中，您現在會看到新的 [相關聯的管線] 索引卷標，您可以在其中找到取用管線和成品的所有管線執行。

支援 YAML 管線中的 GitHub 套件

我們最近引進了稱為 套件 的新資源類型，可新增從 GitHub 取用 NuGet 和 npm 套件的支持，作為 YAML 管線中的資源。 在此資源中，您現在可以指定要從 GitHub 取用的套件類型 (NuGet 或 npm) 。 您也可以在新的套件版本發行時啟用自動化管線觸發程式。 目前支援僅適用於從 GitHub 取用套件，但未來我們計劃擴充支援，以從 NuGet、 npm、 AzureArtifacts 等其他套件存放庫取用套件。 如需詳細資訊，請參閱下列範例：

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

注意

現今 GitHub 套件僅支援 PAT 型驗證，這表示套件資源中的 GitHub 服務連線應為 PAT 類型。 一旦提高這項限制，我們將支援其他類型的驗證。

根據預設，不會在您的作業中自動下載套件，因此為什麼我們引進 了 getPackage 宏，可讓您取用資源中定義的套件。 如需詳細資訊，請參閱下列範例：

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

在 Kubernetes 環境資源檢視中 Azure Kubernetes Service 叢集連結

我們已新增 Kubernetes 環境資源檢視的連結，以便瀏覽至對應叢集的 Azure 刀鋒視窗。 這適用於對應至 Azure Kubernetes Service 叢集中命名空間的環境。

在通知訂閱中釋放資料夾篩選

資料夾允許組織管線，以便更容易探索和安全性控制。 您通常想要為所有發行管線設定自定義電子郵件通知，這些通知是由資料夾下的所有管線所代表。 之前，您必須在訂用帳戶中設定多個訂用帳戶，或有複雜的查詢，才能取得焦點電子郵件。 透過此更新，您現在可以將 release 資料夾子句新增至 部署已完成 並 核准擱 置的事件，並簡化訂用帳戶。

使用多階段 YAML 管線連結工作專案

目前，您可以自動連結工作專案與傳統組建。 不過，YAML 管線無法這樣做。 透過此更新，我們已解決此差距。 當您使用指定分支的程式代碼成功執行管線時，Azure Pipelines 會自動將執行與所有工作專案產生關聯， (透過該程式代碼中的認可推斷) 。 當您開啟工作專案時，您將可以看到建置該工作專案的程式代碼執行。 若要進行此設定，請使用管線的設定面板。

多階段 YAML 管線執行的取消階段

執行多階段 YAML 管線時，您現在可以在階段進行時取消執行階段。 如果您知道階段將會失敗，或者您是否有另一個想要啟動的執行，這會很有説明。

重試失敗階段

多階段管線中最要求的功能之一，就是能夠重試失敗的階段，而不需要從頭開始。 透過此更新，我們會新增此功能的一大部分。

您現在可以在執行失敗時重試管線階段。 在第一次嘗試中失敗的任何作業，以及依賴這些失敗作業的作業，都會重新嘗試。

這可協助您以數種方式節省時間。 例如，當您在階段中執行多個作業時，可能會希望每個階段在不同的平臺上執行測試。 如果某個平臺上的測試在其他人通過時失敗，您可以藉由不重新執行通過的作業來節省時間。 另一個範例是，部署階段可能會因為網路連線不穩定而失敗。 重試該階段可協助您節省時間，因為不需要產生另一個組建。

這項功能有一些已知的差距。 例如，您無法重試明確取消的階段。 我們正在在未來更新中關閉這些差距。

多階段 YAML 管線中的核准

您的 YAML CD 管線可能包含手動核准。 基礎結構擁有者可以保護其環境，並在任何管線部署至它們的階段之前，先尋求手動核准。 在基礎結構 (環境) 與應用程式 (管線) 擁有者之間完全隔離角色時，您將確保手動註銷特定管線中的部署，並取得集中控制，以在所有部署套用至環境之間的相同檢查。

部署至開發人員的管線執行將會在階段開始時停止核准。

增加閘道逾時限制和頻率

先前，發行管線中的閘道逾時限制是三天。 透過此更新，逾時限制已增加到 15天 ，以允許持續時間較長的閘道。 我們也將閘道的頻率增加到 30分鐘。

Dockerfile 的新組建映像範本

先前，在新管線建立中建立 Dockerfile 的新管線時，範本建議將映像推送至 Azure Container Registry，並部署到 Azure Kubernetes Service。 我們新增了範本，可讓您使用代理程式建置映像，而不需要推送至容器登錄。

設定 Azure App 服務 應用程式設定的新工作

Azure App 服務 允許透過各種設定進行設定，例如應用程式設定、連接字串和其他一般組態設定。 我們現在有新的 Azure Pipelines 工作 Azure App 服務 設定，其支援在 Web 應用程式或其任何部署位置上使用 JSON 語法大量設定這些設定。 此工作可以與其他 App Service 工作一起使用，以 部署、 管理和 設定 Web 應用程式、函式應用程式或任何其他容器化 App Services。

Azure App 服務 現在支援使用預覽交換

Azure App 服務 現在支援在部署位置上使用預覽交換。 這是在應用程式實際從預備位置交換到生產位置之前，使用生產設定來驗證應用程式的好方法。 這也可確保目標/生產位置不會經歷停機。

Azure App 服務 工作現在可透過下列新動作支援此多階段交換：

• 使用預覽開始交換 - 使用預覽 (多階段交換起始交換) ，並套用目標位置 (例如，生產位置) 設定至來源位置。
• 使用預覽完成交換 - 當您準備好完成擱置的交換時，請選取 [使用預覽完成交換] 動作。
• 取消與預覽 交換 - 若要取消擱置的交換，請選取 [取消具有預覽的交換]。

Azure Container Registry 和 Docker Hub成品的階段層級篩選

先前，Azure Container Registry 和 Docker Hub 成品的正則表達式篩選僅適用於發行管線層級。 它們現在也已在階段層級新增。

YAML 管線中核准的增強功能

我們已針對服務連線和代理程式集區啟用核准。 針對核准，我們會遵循基礎結構擁有者和開發人員之間角色的隔離。 藉由在您的資源上設定核准，例如環境、服務連線和代理程式集區，您可確保所有使用資源的管線執行都需要先核准。

體驗類似於設定環境的核准。 在階段中參考的資源上擱置核准時，管線的執行會等到手動核准管線為止。

Azure Pipelines 中的容器結構測試支援

應用程式中的容器使用量會增加，因此需要強固測試和驗證。 Azure Pipelines 現在支援 容器結構測試。 此架構提供方便且功能強大的方法來驗證容器的內容和結構。

您可以根據四種可一起執行的測試類別來驗證影像的結構：命令測試、檔案存在測試、檔案內容測試和元數據測試。 您可以使用管線中的結果來進行 go/no go 決策。 測試數據可在管線執行中取得，並出現錯誤訊息，以協助您更妥善地針對失敗進行疑難解答。

輸入組態檔和映像詳細數據

測試數據和摘要

發行管線的管線裝飾專案

管線裝飾項目允許將步驟新增至每個作業的開頭和結尾。 這與將步驟新增至單一定義不同，因為它會套用至集合中的所有管線。

我們支援建置和 YAML 管線的裝飾專案，讓客戶使用它們集中控制其作業中的步驟。 我們現在也會擴充發行管線的支援。 您可以建立延伸模組，以新增以新貢獻點為目標的步驟，而且它們將會新增至發行管線中的所有代理程序作業。

將 Azure Resource Manager (ARM) 部署至訂用帳戶和管理群組層級

我們先前僅支援將部署部署到資源群組層級。 透過此更新，我們新增了將ARM範本部署至訂用帳戶和管理群組層級的支援。 這可協助您在一起部署一組資源，但將它們放在不同的資源群組或訂用帳戶中。 例如，將 Azure 的備份虛擬機部署至個別的資源群組和位置 Site Recovery。

多階段 YAML 管線的 CD 功能

您現在可以取用 CI 管線所發佈的成品，並啟用管線完成觸發程式。 在多階段 YAML 管線中，我們會引進 pipelines 作為資源。 在您的 YAML 中，您現在可以參考另一個管線，並啟用 CD 觸發程式。

以下是管線資源的詳細 YAML 架構。

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

此外，您可以使用工作下載管線資源 - download 所發佈的成品。

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

如需詳細資訊，請參閱 這裡的下載成品檔。

在 Kubernetes 環境上協調 Canary 部署策略

持續傳遞應用程式更新的主要優點之一，就是能夠快速將更新推送至特定微服務的生產環境。 這可讓您快速響應商務需求變更。 環境 引進為第一級概念，可協調部署策略，並加速零停機時間發行。 先前，我們支援 runOnce 策略，該策略會循序執行步驟一次。 透過支援多階段管線中的 Canary 策略，您現在可以藉由將變更緩慢推出至小型子集來降低風險。 當您更有信心新版本時，您可以開始將它推出至基礎結構中的更多伺服器，並將更多使用者路由至該版本。

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Kuberenetes 的 Canary 策略會先部署 10% Pod 的變更，後面接著 20%，同時監視 PostRouteTraffic 期間的健全狀況。 如果一切順利，它將會提升為100%。

我們正在尋找在環境中支援 VM 資源的早期意見反應，以及跨多部電腦執行滾動部署策略。 請與我們連絡 以註冊。

YAML 管線的核准原則

在 YAML 管線中，我們會遵循資源擁有者控制的核准設定。 資源擁有者會在資源上設定核准，以及所有使用資源暫停的管線，以在取用資源的階段開始之前暫停核准。 SOX 型應用程式擁有者通常會限制部署的要求者核准自己的部署。

您現在可以使用 進階核准選項 來設定核准原則，例如要求者不應該核准、需要使用者子集核准，以及核准逾時。

ACR 作為第一級管線資源

如果您需要取用發佈至 ACR 的容器映像 (Azure Container Registry) 作為管線的一部分，並在發佈新映射時觸發管線，您可以使用 ACR 容器資源。

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

此外，您可以使用預先定義的變數來存取 ACR 映射元數據。 下列清單包含可用來定義管線中 ACR 容器資源的 ACR 變數。

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

評估管線中成品檢查原則的增強功能

我們已增強 評估成品檢查 ，讓您更輕鬆地從現成的原則定義清單中新增原則。 原則定義會自動產生，並新增至 檢查組態 ，視需要更新。

支援部署作業中的輸出變數

您現在可以在部署作業的 生命週期勾點 中定義輸出變數，並在相同階段內的其他下游步驟和作業中使用這些變數。

在執行部署策略時，您可以使用下列語法，跨作業存取輸出變數。

• 針對 runOnce 策略： $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• 針對 Canary 策略： $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• 針對 滾動 策略： $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

深入瞭解如何 設定多作業輸出變數

避免復原重大變更

在傳統發行管線中，通常會依賴排程的部署來進行定期更新。 但是，當您有重大修正時，您可以選擇啟動頻外手動部署。 這樣做時，較舊的版本會繼續排程。 這會造成挑戰，因為根據排程繼續部署時，會回復手動部署。 許多您回報此問題，我們現在已修正此問題。 透過修正，當您手動啟動部署時，會取消環境的所有舊版排程部署。 只有在選取佇列選項為 [部署最新並取消其他人] 時才適用。

YAML 管線中的簡化資源授權

資源是管線外部管線所使用的任何專案。 資源必須先獲得授權，才能使用資源。 先前，在 YAML 管線中使用未經授權的資源時，失敗並出現資源授權錯誤。 您必須從失敗執行的摘要頁面授權資源。 此外，如果管線使用參考未經授權的資源的變數，管線就會失敗。

我們現在可讓您更輕鬆地管理資源授權。 執行不會讓執行失敗，而是會在取用資源的階段開始等候資源的許可權。 資源擁有者可以從 [安全性] 頁面檢視管線並授權資源。

評估成品檢查

您現在可以定義一組原則，並將原則評估新增為容器映像成品環境的檢查。 當管線執行時，執行會在啟動使用環境的階段之前暫停。 系統會根據所部署映像的可用元數據來評估指定的原則。 此檢查會在原則成功時通過，並在檢查失敗時將階段標示為失敗。

匯報 至 ARM 範本部署工作

之前，我們並未篩選 ARM 範本部署工作中的服務連線。 如果您選取較低的範圍服務連線，以對更廣泛的範圍執行ARM範本部署，這可能會導致部署失敗。 現在，我們新增了服務連線的篩選，以根據您選擇的部署範圍篩選出較低的範圍服務連線。

在環境中檢閱應用程式

ReviewApp 會將每個提取要求從 Git 存放庫部署到動態環境資源。 檢閱者可以在合併到主要分支並部署到生產環境之前，查看這些變更的外觀，以及與其他相依服務搭配運作的方式。 這可讓您輕鬆地建立和管理 reviewApp 資源，並受益於環境功能的所有可追蹤性和診斷功能。 藉由使用 reviewApp 關鍵詞，您可以建立資源的複本， (根據環境中的現有資源動態建立新的資源，) 並將新資源新增至環境。

以下是在環境中使用 reviewApp 的範例 YAML 代碼段。

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

從管線收集自動和使用者指定的元數據

現在，您可以從管線工作啟用自動和使用者指定的元數據集合。 您可以使用元數據，使用 評估成品檢查在環境上強制執行成品原則。

使用環境的 VM 部署

環境中最要求的功能之一是 VM 部署。 透過此更新，我們會在環境中啟用虛擬機資源。 您現在可以跨多部計算機協調部署，並使用 YAML 管線執行 滾動 更新。 您也可以直接在每部目標伺服器上安裝代理程式，並將滾動部署驅動至這些伺服器。 此外，您可以在目標計算機上使用完整的工作目錄。

輪流部署會將舊版應用程式的實例取代為一組計算機上新版應用程式的實例， (每次反覆專案中) 滾動集。

例如，以下滾動部署會在每個反覆專案中更新最多五個目標。 maxParallel 會決定可以平行部署的目標數目。 選取專案會考慮隨時必須維持可用的目標數目，但不包括要部署的目標。 這也可用來判斷部署期間的成功和失敗狀況。

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

注意

透過此更新，所有來自目前管線和相關聯管線資源的可用成品只會在生命週期勾點中 deploy 下載。 不過，您可以選擇藉由指定 [下載管線成品] 工作來下載。 這項功能有一些已知的間距。 例如，當您重試階段時，它會在所有 VM 上重新執行部署，而不只是失敗的目標。 我們正努力在未來的更新中關閉這些差距。

進一步控制您的部署

Azure Pipelines 現在支援使用手動核准來控制的部署。 有了最新的增強功能，您現在可以對部署進行額外的控制。 除了核准之外，資源擁有者現在可以新增自動化 checks 來驗證安全性和質量原則。 這些檢查可用來觸發作業，然後等候它們完成。 使用額外的檢查，您現在可以根據多個來源定義健康情況準則，並確保以資源為目標的所有部署都是安全的，不論執行部署的 YAML 管線為何。 根據檢查的指定 重試間隔 ，可以定期重複評估每個檢查。 現已提供下列其他檢查：

• 叫用任何 REST API，並根據回應本文或外部服務的回呼執行驗證
• 叫用 Azure 函式，並根據來自函式的回應或回呼來執行驗證
• 查詢作用中警示的 Azure 監視器規則
• 確定管線會擴充一或多個 YAML 範本

核准通知

當您將核准新增至環境或服務連線時，所有使用資源的多階段管線都會在階段開始時自動等候核准。 指定的核准者必須先完成核准，才能繼續管線。

透過此更新，核准者會收到擱置核准的電子郵件通知。 使用者和小組擁有者可以使用 通知設定選擇退出或設定自訂訂用帳戶。

從 Azure 入口網站 設定部署策略

有了這項功能，我們可讓您更輕鬆地設定管線，以使用您選擇的部署策略，例如 滾動、 Canary 或 Blue-Green。 使用這些現成的策略，您可以以安全的方式推出更新，並降低相關聯的部署風險。 若要存取此專案，請按兩下 Azure 虛擬機中的 [持續傳遞] 設定。 在組態窗格中，系統會提示您選取要在其中建立管線的 Azure DevOps 專案詳細數據、部署群組、建置管線，發佈要部署的套件，以及您選擇的部署策略。 接下來會設定功能完整的管線，以將選取的套件部署至此虛擬機。

如需詳細資訊，請參閱設定 部署策略的檔。

運行時間參數

運行時間參數可讓您更充分掌控哪些值可以傳遞至管線。 不同於變數，運行時間參數具有數據類型，而且不會自動成為環境變數。 使用執行時間參數，您可以：

• 在運行時間為腳本和工作提供不同的值
• 控制參數類型、允許的範圍和預設值
• 使用範本表示式動態選取作業和階段

若要深入瞭解運行時間參數，請參閱 這裡的檔。

在管線中使用 extends 關鍵詞

目前，管線可以分解成範本，以提升重複使用和減少重複使用。 管線的整體結構仍由根 YAML 檔案定義。 透過此更新，我們新增了更結構化的方式來使用管線範本。 根 YAML 檔案現在可以使用 關鍵詞 extends 來指出可以在另一個檔案中找到主要管線結構。 這可讓您控制可以擴充或改變哪些區段，以及哪些區段是固定的。 我們也已使用數據類型增強管線參數，以清除您可以提供的勾點。

此範例說明如何為管線作者提供簡單的勾點以供使用。 範本一律會執行組建、選擇性地執行管線所提供的其他步驟，然後執行選擇性的測試步驟。

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

控制可在佇列時間覆寫的變數

之前，您可以使用 UI 或 REST API 來更新任何變數的值，再啟動新的執行。 雖然管線的作者可以將特定變數標示為 _settable at queue time_，但系統不會強制執行此動作，也不會防止設定其他變數。 換句話說，設定只會用來在啟動新的執行時提示輸入其他輸入。

我們已新增會強制執行 _settable at queue time_ 參數的新集合設定。 這可讓您控制啟動新執行時可以變更的變數。 接下來，您無法變更作者未標示為 _settable at queue time_的變數。

注意

此設定預設會在現有集合中關閉，但當您建立新的 Azure DevOps 集合時，預設會開啟此設定。

YAML 管線中新的預先定義變數

變數可讓您方便將關鍵數據位放入管線的各個部分。 透過此更新，我們已將一些預先定義的變數新增至部署作業。 系統會自動設定這些變數，範圍設定為特定部署作業，而且是只讀的。

• Environment.Id - 環境的識別碼。
• Environment.Name - 部署作業的目標環境名稱。
• Environment.ResourceId - 部署作業目標環境中的資源識別符。
• Environment.ResourceName - 部署作業目標環境中的資源名稱。

簽出多個存放庫

管線通常依賴多個存放庫。 您可以有不同的存放庫，其中包含建置程式代碼所需的來源、工具、腳本或其他專案。 之前，您必須將這些存放庫新增為子模組或手動腳本，才能執行 git 簽出。 現在除了您用來儲存 YAML 管線的存放庫之外，您還可以擷取和取出其他存放庫。

例如，如果您有名為 MyCode 的存放庫與 YAML 管線，而第二個名為 Tools 的存放庫，您的 YAML 管線看起來會像這樣：

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

第三個步驟會顯示來源目錄中的兩個目錄 MyCode 和 Tools 。

支援 Azure Repos Git 存放庫。 如需詳細資訊，請參閱 多存放庫簽出。

在運行時間取得多個存放庫的詳細數據

當管線執行時，Azure Pipelines 會新增觸發執行之存放庫、分支和認可的相關信息。 現在 YAML 管線支援取出多個存放庫，您可能也想要知道已取出給其他存放庫的存放庫、分支和認可。 此資料可透過運行時間表示式取得，您現在可以對應至變數。 例如：

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

允許其他 Azure Repos 集合的存放庫參考

先前，當您在 YAML 管線中參考存放庫時，所有 Azure Repos 存放庫都必須位於與管線相同的集合中。 現在，您可以使用服務連線指向其他集合中的存放庫。 例如：

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection 指向另一個 Azure DevOps 集合，並具有可存取另一個專案中存放庫的認證。 存放庫 self 和 otherrepo最後都會取出。

重要

MyServiceConnection必須是 Azure Repos/Team Foundation Server 服務連線，請參閱下圖。

管線資源元數據作為預先定義的變數

我們已為管線中的 YAML 管線資源新增預先定義的變數。 以下是可用的管線資源變數清單。

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize 和 kompose 作為 KubernetesManifest 工作中的製作選項

kustomize (Kubernetes sig-cli) 可讓您針對多個用途自定義原始、無範本的 YAML 檔案，並讓原始 YAML 保持不變。 已在 KubernetesManifest 工作的製作動作下新增 kustomize 的選項，因此任何包含 kustomization.yaml 檔案的資料夾都可以用來產生 KubernetesManifest 工作部署動作中使用的指令清單檔案。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose 會將 Docker Compose 檔案轉換成 Kubernetes 資源。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

支援 HelmDeploy 工作中叢集管理員認證

之前， HelmDeploy 工作使用叢集使用者認證進行部署。 這會導致已啟用 Azure Active Directory 型 RBAC 叢集的互動式登入提示和失敗的管線。 為了解決此問題，我們新增了一個複選框，可讓您使用叢集管理員認證，而不是叢集用戶認證。

Docker Compose 工作中自變數輸入

Docker Compose 工作中引進了新的欄位，可讓您新增自變數，例如 --no-cache。 執行建置之類的命令時，工作會關閉自變數。

GitHub 發行工作增強功能

我們已對 GitHub 發行工作進行數個增強功能。 您現在可以藉由指定標籤則表示式來更妥善地控制發行建立，而且只有在觸發認可以相符字串標記時，才會建立發行。

我們也新增了自定義變更記錄建立和格式化的功能。 在變更記錄組態的新區段中，您現在可以指定應該比較目前版本的版本。 [比較發行] 可以是最後一個完整版本， (排除發行前版本) 、最後一個非草稿版本或任何符合您提供發行卷標的舊版。 此外，工作會提供變更記錄類型字段來格式化變更記錄。 根據選取專案，變更記錄會顯示認可清單，或根據標籤分類的問題/PR 清單。

開啟原則代理程式安裝程式工作

開放式原則代理程式是一種 開放原始碼、一般用途的原則引擎，可強制執行統一、內容感知的原則。 我們已新增開啟原則代理程式安裝程式工作。 對於基礎結構即程序代碼提供者，在管線內原則強制執行特別有用。

例如，開啟原則代理程式可以在管線中評估 Rego 原則檔案和 Terraform 方案。

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Azure CLI 工作中 PowerShell 腳本的支援

先前，您可以在 Azure CLI 工作中執行批次和 Bash 腳本。 透過此更新，我們已將PowerShell和PowerShell核心腳本的支援新增至工作。

KubernetesManifest 工作中以 Service Mesh 介面為基礎的 Canary 部署

先前在 KubernetesManifest 工作中指定 Canary 策略時，工作會建立基準和 Canary 工作負載，其復本等於用於穩定工作負載的複本百分比。 這與將流量分割至要求層級所需的百分比不同。 為了解決此問題，我們已將 Service Mesh 介面 型 Canary 部署的支援新增至 KubernetesManifest 工作。

Service Mesh 介面抽象概念允許使用 Service Mesh 提供者的隨插即用設定，例如 Linkerd 和 Istio。 現在 KubernetesManifest 工作會佔用在部署策略生命週期期間，將 SMI 的 TrafficSplit 物件對應至穩定、基準和 Canary 服務的困難工作。 穩定、基準和 Canary 之間所需流量的分割百分比更精確，因為流量分割的百分比是在服務網格平面的要求上控制。

以下是以滾動方式執行 SMI 型 Canary 部署的範例。

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Azure 檔案複製工作現在支援 AzCopy V10

Azure 檔案複製工作可用於組建或發行管線，將檔案複製到 Microsoft 記憶體 Blob 或虛擬機， (VM) 。 此工作會使用 AzCopy，命令行公用程式建置來快速將數據從 Azure 記憶體帳戶複製到 Azure 記憶體帳戶。 透過此更新，我們已新增 AzCopy V10 的支援，這是 最新版的 AzCopy。

此命令 azcopy copy 僅支援與其相關聯的 自變數 。 由於 AzCopy 語法的變更，AzCopy V10 中無法使用某些現有的功能。 其中包括：

• 指定記錄位置
• 在複製之後清除記錄檔和計劃檔案
• 作業失敗時繼續複製

此工作版本所支援的其他功能如下：

• 來源檔名/路徑中的通配符符號
• 未提供自變數時，根據擴展名推斷內容類型
• 傳遞自變數，以定義記錄檔的記錄詳細資訊

藉由限制存取令牌的範圍來改善管線安全性

在 Azure Pipelines 中執行的每個作業都會取得存取令牌。 存取令牌是由工作和腳本用來回呼 Azure DevOps。 例如，我們使用存取令牌來取得原始程式碼、上傳記錄、測試結果、成品，或對 Azure DevOps 進行 REST 呼叫。 系統會為每個作業產生新的存取令牌，並在作業完成之後到期。 透過此更新，我們新增了下列增強功能。

• 防止令牌存取Team專案外部的資源

  到目前為止，所有管線的預設範圍都是 Team 專案集合。 您可以將範圍變更為傳統組建管線中的小組專案。 不過，您沒有傳統發行或 YAML 管線的控制權。 透過此更新，我們會引進集合設定，以強制每個作業取得專案範圍的令牌，而不論管線中設定的內容為何。 我們也在專案層級新增了設定。 現在，您建立的每個新專案和集合都會自動開啟此設定。

  注意

  集合設定會覆寫項目設定。

  如果您的管線使用存取令牌存取小組專案外部的資源，請在現有專案和集合中開啟此設定可能會導致某些管線失敗。 若要減輕管線失敗，您可以明確授與 專案建置服務帳戶 對所需資源的存取權。 強烈建議您開啟這些安全性設定。

• 限制組建服務存放庫範圍存取

  藉由限制存取令牌的範圍來改善管線安全性，Azure Pipelines 現在可以將其存放庫存取範圍縮小至 YAML 型管線所需的存放庫。 這表示，如果管線的存取令牌流失，它只會看到存放庫 (管線中使用的) 。 先前，存取令牌適用於專案中任何 Azure Repos 存放庫，或可能是整個集合。

  新專案和集合預設會開啟這項功能。 對於現有的集合，您必須在 [集合設定>管線>設定] 中啟用它。 使用此功能時，建置所需的所有存放庫 (即使是使用腳本複製的存放庫，) 也必須包含在管線的 存放庫資源 中。

• 拿掉存取令牌的特定許可權

  根據預設，我們會將一些許可權授與存取令牌，其中一個許可權是 佇列組建。 透過此更新，我們已移除存取令牌的這個許可權。 如果您的管線需要此許可權，您可以根據您使用的令牌，明確地將它授與 專案建置服務帳戶 或 專案集合建置服務帳戶 。

服務連線的項目層級安全性

我們已新增服務連線的中樞層級安全性。 現在，您可以新增/移除使用者、指派角色和管理所有服務連線集中位置的存取權。

步驟目標與命令隔離

Azure Pipelines 支援在容器或代理程式主機上執行作業。 先前，整個作業已設定為這兩個目標的其中一個。 現在，個別步驟 (工作或腳本) 可以在您選擇的目標上執行。 步驟也可能以其他容器為目標，因此管線可以在特製化、用途建置的容器中執行每個步驟。

容器可以做為隔離界限，以防止程式代碼在主計算機上進行非預期的變更。 步驟 與代理程式通訊和存取服務 的方式，不會受到容器中隔離步驟的影響。 因此，我們也引進了命令限制模式，您可以搭配步驟目標使用。 開啟此選項會限制步驟可從代理程式要求的服務。 它將不再能夠附加記錄、上傳成品，以及某些其他作業。

以下是完整的範例，其中顯示作業容器和另一個容器中主機上的執行步驟：

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

唯讀變數

系統變數記載為不可變，但實際上，工作可能會覆寫這些變數，而下游工作會挑選新的值。 透過此更新，我們會強化管線變數的安全性，讓系統和佇列時間變數變成只讀。 此外，您可以將 YAML 變數標示為唯讀，如下所示。

variables:
- name: myVar
  value: myValue
  readonly: true

服務連線的角色型存取

我們已新增服務連線的角色型存取。 先前，服務連線安全性只能透過預先定義的 Azure DevOps 群組來管理，例如端點管理員和端點建立者。

在這項工作中，我們引進了讀者、使用者、建立者和系統管理員的新角色。 您可以透過專案中的服務連線頁面來設定這些角色，這些角色是由個別連線繼承。 而在每個服務連線中，您可以選擇開啟或關閉繼承，並在服務連線的範圍內覆寫角色。

在這裡深入瞭解服務連線安全性。

服務連線的跨項目共用

我們啟用了跨專案共用服務連線的支援。 您現在可以安全地與專案共用服務連線。

在這裡深入瞭解服務連線共用。

管線和 ACR 資源的可追蹤性

當管線和 ACR 容器資源用於管線時，我們可確保完整的 E2E 可追蹤性。 針對 YAML 管線所耗用的每個資源，您可以追蹤認可、工作專案和成品。

在管線執行摘要檢視中，您可以看到：

• 觸發執行的資源版本。 現在，您可以在完成另一個 Azure 管線執行或將容器映射推送至 ACR 時觸發您的管線。

  

• 管線所取用的認可。 您也可以找到管線所耗用之每個資源的認可明細。

  

• 與管線所耗用之每個資源相關聯的 工作專案 。

• 可供執行使用的 成品 。

  

在環境的部署檢視中，您可以看到部署至環境的每個資源的認可和工作專案。

支援大型測試附件

Azure Pipelines 中的發佈測試結果工作可讓您在執行測試時發佈測試結果，以提供完整的測試報告和分析體驗。 到目前為止，測試回合和測試結果的測試附件限制為100 MB。 這會限制上傳大型檔案，例如損毀傾印或影片。 透過此更新，我們新增了大型測試附件的支援，可讓您擁有所有可用的數據，以針對失敗的測試進行疑難解答。

您可能會在記錄中看到 VSTest 工作或發佈測試結果工作傳回 403 或 407 錯誤。 如果您使用防火牆後方的自我裝載組建或發行代理程式來篩選輸出要求，您必須進行一些組態變更，才能使用這項功能。 ​

若要修正此問題，我們建議您將輸出 要求的 防火牆更新為 https://*.vstmrblob.vsassets.io。 您可以 在這裡找到檔中的疑難解答資訊。 ​

注意

只有在您使用自我裝載的 Azure Pipelines 代理程式，而且您位於篩選輸出流量的防火牆後方時，才需要這樣做。 如果您在雲端中使用 Microsoft 裝載的代理程式，或未篩選輸出網路流量，則不需要採取任何動作。

顯示每個作業的正確集區資訊

之前，當您使用矩陣來展開作業或變數來識別集區時，我們有時會解析記錄頁面中不正確的集區資訊。 這些問題已解決。

新分支的 CI 觸發程式

建立新分支時，以及該分支沒有變更時，它已經是長時間擱置的要求，不會觸發 CI 組建。 請思考一下下列範例：

• 您可以使用 Web 介面，根據現有的分支建立新的分支。 如果您的分支篩選符合新分支的名稱，這會立即觸發新的 CI 組建。 這是不必要的，因為與現有分支相比，新分支的內容相同。
• 您有一個存放庫，其中包含兩個資料夾 - 應用程式和檔案。您可以設定 CI 的路徑篩選條件，以符合 「app」。 換句話說，如果變更已推送至檔，您就不想建立新的組建。您會在本機建立新的分支、對文件進行一些變更，然後將該分支推送至伺服器。 我們用來觸發新的 CI 組建。 這是不必要的，因為您明確要求不要在 docs 資料夾中尋找變更。 不過，由於我們處理新的分支事件的方式，似乎也已經變更應用程序資料夾。

現在，我們有更好的方法可處理 CI，讓新的分支解決這些問題。 當您發佈新的分支時，我們會在該分支中明確尋找新的認可，並檢查它們是否符合路徑篩選條件。

作業可以存取先前階段的輸出變數

輸出變數現在可以跨 YAML 型管線中的階段使用。 這可協助您傳遞有用的資訊，例如從一個階段到下一個階段的go/no-go決策或產生的輸出標識符。 先前階段的結果 (狀態) ，而且其作業也可供使用。

輸出變數仍會由作業內的步驟所產生。 階段會參考 ，而不是參考 dependencies.jobName.outputs['stepName.variableName']stageDependencies.stageName.jobName.outputs['stepName.variableName']。

注意

根據預設，管線中的每個階段都相依於 YAML 檔案中的階段之前。 因此，每個階段都可以使用先前階段的輸出變數。 您可以改變相依性圖形，這也會改變可用的輸出變數。 例如，如果階段 3 需要階段 1 的變數，則必須在階段 1 上宣告明確的相依性。

停用集區層級的自動代理程序升級

目前，管線代理程式會在需要時自動更新為最新版本。 這通常會發生在有新功能或工作需要較新的代理程式版本才能正常運作時。 透過此更新，我們會新增在集區層級停用自動升級的功能。 在此模式中，如果沒有正確版本的代理程式連線到集區，管線將會失敗，並出現清楚的錯誤訊息，而不是要求代理程式進行更新。 這項功能大多對具有自我裝載集區的客戶感興趣，以及非常嚴格的變更控制需求。 自動更新預設為啟用，我們不建議大部分的客戶停用它們。

代理程序診斷

我們已針對許多常見的代理程式相關問題新增診斷，例如許多網路問題，以及升級失敗的常見原因。 若要開始使用診斷，請在 Windows 上使用 run.sh --diagnostics 或 run.cmd --diagnostics 。

YAML 管線的服務勾點

將服務與 YAML 管線整合變得更容易。 使用 YAML 管線的服務勾點事件，您現在可以根據管線執行的進度，驅動自定義應用程式或服務中的活動。 例如，您可以在需要核准時建立技術服務人員票證、在階段完成後起始監視工作流程，或在階段失敗時將推播通知傳送至小組的行動裝置。

所有事件都支援篩選管線名稱和階段名稱。 您也可以針對特定環境篩選核准事件。 同樣地，狀態變更事件也可以依管線執行或階段的新狀態進行篩選。

優化整合

Optimizely 是功能強大的 A/B 測試和功能標記平臺，適用於產品小組。 Azure Pipelines 與 Optimizely 測試平臺整合可讓產品小組以加速步調進行測試、學習和部署，同時獲得 Azure Pipelines 的所有 DevOps 權益。

適用於 Azure DevOps 的 Optimizely 擴充功能會將實驗和功能旗標推出步驟新增至組建和發行管線，讓您可以持續逐一查看、推出功能，並使用 Azure Pipelines 加以復原。

在這裡深入瞭解 Azure DevOps Optimizely 擴充功能。

將 GitHub 版本新增為成品來源

現在，您可以在 Azure DevOps 發行管線中將 GitHub 版本連結為成品來源。 這可讓您使用 GitHub 版本作為部署的一部分。

當您在發行管線定義中按兩下 [ 新增成品 ] 時，您會發現新的 GitHub 發行 來源類型。 您可以提供服務連線和 GitHub 存放庫，以取用 GitHub 版本。 您也可以選擇 GitHub 版本的預設版本，以取用為最新的特定標籤版本，或在發行建立時選取 。 連結 GitHub 版本之後，它會自動下載，並在您的發行作業中提供。

Terraform 與 Azure Pipelines 整合

Terraform 是開放原始碼工具，可用來安全地且有效率地開發、變更和版本設定基礎結構。 Terraform 會將 API 編碼成宣告式組態檔，可讓您使用高階設定語言來定義和布建基礎結構。 您可以使用 Terraform 擴充功能，跨所有主要基礎結構提供者建立資源：Azure、Amazon Web Services (AWS) 和 Google Cloud Platform (GCP) 。

若要深入瞭解 Terraform 延伸模組，請參閱 這裡的檔。

與Google Analytics整合

Google Analytics 實驗架構可讓您測試網站或應用程式幾乎任何變更或變化，以測量其對特定目標的影響。 例如，您可能有想要讓使用者完成 (的活動，例如進行購買、註冊您想要改善 (的電子報) 和/或計量，例如營收、會話持續時間、退回率) 。 這些活動可讓您根據對功能效能的直接影響，找出值得實作的變更。

適用於 Azure DevOps 的 Google Analytics 實驗延伸模組會將實驗步驟新增至建置和發行管線，讓您可以持續逐一查看、學習和部署，方法是持續管理實驗，同時從 Azure Pipelines 獲得所有 DevOps 權益。

您可以從 Marketplace 下載 Google Analytics 實驗延伸模組 。

已更新 ServiceNow 與 Azure Pipelines 的整合

適用於 ServiceNow 的 Azure Pipelines 應用程式可協助整合 Azure Pipelines 和 ServiceNow 變更管理。 透過此更新，您可以與紐約版本的 ServiceNow 整合。 這兩個服務之間的驗證現在可以使用 OAuth 和基本身份驗證進行。 此外，您現在可以設定進階成功準則，以便使用任何變更屬性來決定網關結果。

從 VSCode Create Azure Pipelines

我們已將新功能新增至適用於 VSCode 的 Azure Pipelines 擴充功能。 現在，您將可以直接從 VSCode 建立 Azure Pipelines，而不需要離開 IDE。

Flaky Bug 管理和解決方式

我們引進了 Flaky 測試管理，以支援使用偵測、報告和解決的端對端生命週期。 為了進一步增強，我們要新增 Flaky 測試 Bug 管理和解決方式。

調查 Flaky 測試時，您可以使用 Bug 動作來建立 Bug ，然後指派給開發人員進一步調查 Flaky 測試的根本原因。 錯誤報告包含管線的相關信息，例如錯誤訊息、堆疊追蹤，以及與測試相關聯的其他資訊。

當錯誤報告解決或關閉時，我們會自動將測試取消標示為不模糊。

如果未執行最少的測試數目，請將 VSTest 工作設定為失敗

VSTest 工作會使用使用者輸入來探索和執行測試 (測試檔案、篩選準則等) ，以及所使用測試架構特定的測試配接器。 使用者輸入或測試配接器的變更可能會導致未探索到測試的情況，而且只會執行預期的測試子集。 這可能會導致管線成功的情況，因為會略過測試，而不是因為程式代碼具有足夠的高品質。 為了協助避免這種情況，我們在 VSTest 工作中新增了一個新選項，可讓您指定必須執行以讓工作通過的測試數目下限。

VSTest TestResultsDirectory 選項可在工作 UI 中使用

VSTest 工作會將測試結果和相關聯的檔案儲存在 $(Agent.TempDirectory)\TestResults 資料夾中。 我們已將選項新增至工作 UI，讓您設定不同的資料夾來儲存測試結果。 現在，任何需要特定位置檔案的後續工作都可以使用這些工作。

自動化測試錯誤訊息中的 Markdown 支援

我們已將 Markdown 支援新增至自動化測試的錯誤訊息。 現在，您可以輕鬆地將測試回合和測試結果的錯誤訊息格式化，以改善可讀性，並簡化 Azure Pipelines 中的測試失敗疑難解答體驗。 您可以 在這裡找到支援的 Markdown 語法。

使用管線裝飾項目自動插入部署作業中的步驟

您現在可以將 管線裝飾專案 新增至部署作業。 您可以將任何自定義步驟 (例如弱點掃描器) 自動插入至每個部署作業的每個 生命週期勾點 執行。 由於管線裝飾專案可以套用至集合中的所有管線，因此可以在強制執行安全部署做法的過程中運用此裝飾專案。

此外，如果已定義，部署作業可以當做 容器作業 以及 服務側車 來執行。

Test Plans

新增測試計劃頁面

新的 Test Plans Page (Test Plans *) 適用於所有 Azure DevOps 集合。 新頁面提供簡化的檢視，可協助您專注於手邊的工作 - 測試規劃、撰寫或執行。 它也是無雜亂且與 Azure DevOps 供應項目的其餘部分一致。

協助我了解新頁面

新的 Test Plans 頁面總共有 6 個區段，前 4 個區段是新的，而 [圖表] & [擴充性] 區段是現有的功能。

1. 測試計劃標頭：使用此標頭來尋找、我的最愛、編輯、複製或複製測試計劃。
2. 測試套件樹狀結構：使用此樹狀結構來新增、管理、匯出或訂購測試套件。 利用此功能來指派設定並執行使用者驗收測試。
3. 定義索引標籤：透過此索引標籤，在所選的測試套件中建立、新增及管理測試案例。
4. 執行索引標籤：透過此索引標籤指派和執行測試，或找出要鑽研的測試結果。
5. 圖表索引標籤：透過也可以釘選到儀錶板的圖表追蹤測試執行和狀態。
6. 擴充性：支持 產品內目前的擴充點 。

讓我們檢視以下這些新區段的廣泛筆劃。

1. 測試計劃標頭

工作

測試計劃標頭可讓您執行下列工作：

• 將測試計劃標示為我的最愛
• 取消標記我的最愛測試計劃
• 輕鬆瀏覽您最愛的測試計劃
• 檢視測試計劃的反覆項目路徑，清楚指出測試計劃是否為 [目前] 或 [過去]
• 檢視 [測試進度] 報表的快速摘要，其中包含流覽至報表的連結
• 流覽回 All/Mine Test Plans 頁面

操作功能表選項

測試計劃標頭上的操作功能表提供下列選項：

• 複製測試計劃：這是一個新選項，可讓您快速複製目前的測試計劃。 請參閱下列詳細資訊。
• 編輯測試計劃：此選項可讓您編輯 [測試計劃] 工作項目表單，以管理工作專案欄位。
• 測試計劃設定：此選項可讓您設定 [測試回合] 設定 (建立組建或發行管線) 和 [測試結果] 設定

複製測試計劃 (新功能)

建議您為每個短期衝刺/版本建立新的測試計劃。 這樣做時，通常可以複製先前週期的測試計劃，而且複製的測試計劃有幾個變更可供新週期使用。 為了簡化此程式，我們已在新頁面上啟用「複製測試計劃」功能。 您可以利用它來複製或複製測試計劃。 其支援 REST API 也涵蓋 在這裡 ，而 API 也可讓您跨專案複製/複製測試計劃。
如需 Test Plans 使用方式的更多指導方針，請參閱這裡。

2. 測試套件樹狀結構

工作

Test suite 標頭可讓您執行下列工作：

• 展開/折疊：此工具列選項可讓您展開或折疊套件階層樹狀結構。
• 顯示子套件中的測試點：只有在您位於 [執行] 索引卷標時，才會顯示此工具列選項。這可讓您在一個檢視中檢視給定套件及其子系的所有測試點，以便更輕鬆地管理測試點，而不需要一次流覽至個別套件。
• 訂單套件：您可以將套件拖放至重新排列套件階層，或將套件從一個套件階層移至測試計劃內的另一個套件階層。

操作功能表選項

[測試套件] 樹狀結構上的操作功能表提供下列選項：

• Create 新套件：您可以建立 3 種不同類型的套件，如下所示：
  • 使用靜態套件或資料夾套件來組織測試。
  • 使用需求型套件，直接連結至需求/用戶劇本，以取得順暢的可追蹤性。
  • 使用查詢型來動態組織符合查詢準則的測試案例。
• 指派設定：您可以指派套件的設定 (範例：Chrome、Firefox、EdgeChromium) ，然後這些設定適用於您稍後新增至此套件的所有現有測試案例或新的測試案例。
• 匯出為 pdf/電子郵件：匯出測試計劃屬性、測試套件屬性，以及測試案例和測試點的詳細數據，以做為「電子郵件」或「列印至 pdf」。
• 開啟測試套件工作專案：此選項可讓您編輯 Test suite 工作專案表單來管理工作專案字段。
• 指派測試人員執行所有測試：此選項非常適用於使用者驗收測試 (UAT) 案例，其中多個測試人員必須執行/執行相同的測試，通常屬於不同的部門。
• 重新命名/刪除：這些選項可讓您管理套件名稱，或從測試計劃中移除套件及其內容。

3.定義索引標籤

[定義] 索引標籤可讓您定序、新增及管理測試套件的測試案例。 [執行] 索引標籤用於指派測試點並加以執行。

[定義] 索引標籤和特定作業僅適用於具有基本 + Test Plans 存取層級或同等許可權的使用者。 其他所有項目都應該由具有「基本」存取層級的用戶執行。

工作

[定義] 索引標籤可讓您執行下列工作：

• 使用工作項目表單新增測試案例：此選項可讓您使用工作項目表單建立新的測試案例。 建立的測試案例會自動新增至套件。
• 使用方格新增測試案例：此選項可讓您使用測試案例方格檢視建立一或多個測試案例。 建立的測試案例會自動新增至套件。
• 使用查詢新增現有的測試案例：此選項可讓您藉由指定查詢，將現有的測試案例新增至套件。
• 依拖放順序測試案例：您可以藉由在指定的套件中拖曳/卸除一或多個測試案例來重新排序測試案例。 測試案例的順序僅適用於手動測試案例，不適用於自動化測試。
• 將測試案例從一個套件移到另一個套件：使用拖放，您可以將測試案例從一個測試套件移至另一個測試套件。
• 顯示方格：您可以使用方格模式來檢視/編輯測試案例以及測試步驟。
• 全螢幕檢視：您可以使用此選項，在全螢幕模式中檢視整個 [定義] 索引卷標的內容。
• 篩選：使用篩選列，您可以使用 「測試案例標題」、「指派給」和「狀態」的欄位來篩選測試案例清單。 您也可以按下資料列標頭來排序列表。
• 資料列選項：您可以使用 [資料行選項] 來管理 [定義] 索引標籤中可見的數據行清單。 可供選取的數據行清單主要是來自測試案例工作項目表單的欄位。

操作功能表選項

[定義] 索引標籤內 [測試案例] 節點的操作選單提供下列選項：

• 開啟/編輯測試案例工作項目表單：此選項可讓您使用工作專案表單編輯測試案例，在其中編輯工作專案欄位，包括測試步驟。
• 編輯測試案例：此選項可讓您大量編輯 [測試案例工作專案] 字段。 不過，您無法使用此選項來大量編輯測試步驟。
• 在方格中編輯測試案例：此選項可讓您大量編輯選取的測試案例，包括使用方格檢視的測試步驟。
• 指派組態：此選項可讓您使用測試案例層級組態覆寫套件層級設定。
• 拿掉測試案例：此選項可讓您從指定的套件中移除測試案例。 但不會變更基礎測試案例工作專案。
• Create 測試案例的複製/複製：此選項可讓您建立所選測試案例的複製/複製。 詳細資訊請見下文。
• 檢視連結的專案：此選項可讓您查看指定測試案例的連結專案。 詳細資訊請見下文。

複製/複製測試案例 (新功能)

如果您想要複製/複製測試案例的案例，您可以使用 [複製測試案例] 選項。 您可以指定要在其中建立複製/複製測試案例的目的地專案、目的地測試計劃和目的地測試套件。 此外，您也可以指定是否要包含現有的連結/附件，以流向複製的複本。

檢視 (新功能) 的連結專案

測試成品、需求和 Bug 之間的可追蹤性是 Test Plans 產品的重要價值主張。 使用 [檢視連結的專案] 選項，您可以輕鬆地查看此測試案例連結的所有連結需求、已使用此測試案例的所有測試套件/測試計劃，以及已提出作為測試執行一部分的所有 Bug。

4. 執行索引標籤

[定義] 索引標籤可讓您定序、新增及管理測試套件的測試案例。 [執行] 索引標籤用於指派測試點並加以執行。

什麼是測試點？ 測試案例本身不是可執行的。 當您將測試案例新增至測試套件時，會產生測試點 () 。 測試點是測試案例、測試套件、設定和測試人員的唯一組合。 範例：如果您有測試案例作為「測試登入功能」，並將 2 個設定新增至它作為 Edge 和 Chrome，則這會產生 2 個測試點。 現在可以執行這些測試點。 在執行時，會產生測試結果。 透過測試結果檢視 (執行歷程記錄) 您可以看到測試點的所有執行。 測試點的最新執行是您在 [執行] 索引標籤中看到的內容。
因此，測試案例是可重複使用的實體。 藉由將它們包含在測試計劃或套件中，會產生測試點。 藉由執行測試點，您可以判斷正在開發的產品或服務品質。

新頁面的其中一個主要優點是，主要執行/追蹤 (需要只有 「基本」存取層級) 的使用者，這些使用者不會因為套件管理 (定義索引卷標的複雜度而感到無法負荷) 。

[定義] 索引標籤和特定作業僅適用於具有基本 + Test Plans 存取層級或同等許可權的使用者。 其他所有專案，包括 [執行] 索引標籤，應該由具有 [基本] 存取層級的用戶執行。

工作

[執行] 索引標籤可讓您執行下列工作：

• 大量標記測試點：此選項可讓您快速標記測試點的結果 - 通過、失敗、封鎖或不適用，而不需要透過測試執行器執行測試案例。 結果可以一次標示一或多個測試點。
• 執行測試點：此選項可讓您個別執行每個測試步驟，並使用測試執行器將它們標示為通過/失敗，以執行測試案例。 根據您測試的應用程式，您可以使用「Web 執行器」來測試「Web 應用程式」或「桌面執行器」來測試桌面和/或 Web 應用程式。 您也可以叫用「使用選項執行」，以指定要對其執行測試的組建。
• 資料列選項：您可以使用 [資料行選項] 來管理 [執行] 索引標籤中可見的數據行清單。 可供選取的數據行清單與測試點相關聯，例如執行者、指派的測試人員、設定等。
• 全螢幕檢視：您可以使用此選項，在全螢幕模式中檢視整個 [執行] 索引卷標的內容。
• 篩選：使用篩選列，您可以使用 「測試案例標題」、「指派給」、「狀態」、「測試結果」、「測試人員」和「設定」的欄位來篩選測試點清單。 您也可以按下資料列標頭來排序列表。

操作功能表選項

[執行] 索引標籤內 [測試點] 節點的操作選單提供下列選項：

• 標示測試結果：與上述相同，可讓您快速標示測試點的結果 - 通過、失敗、封鎖或不適用。
• 執行測試點：與上述相同，可讓您透過測試執行器執行測試案例。
• 將測試重設為使用中：此選項可讓您將測試結果重設為使用中，藉此忽略測試點的最後一個結果。
• 開啟/編輯測試案例工作項目表單：此選項可讓您使用工作專案表單編輯測試案例，在其中編輯工作專案欄位，包括測試步驟。
• 指派測試人員：此選項可讓您將測試點指派給測試人員以進行測試執行。
• 檢視測試結果：此選項可讓您檢視最新的測試結果詳細數據，包括每個測試步驟的結果、新增的批注或所提出 Bug。
• 檢視執行歷程記錄：此選項可讓您檢視所選測試點的整個執行歷程記錄。 它會開啟新的頁面，您可以在其中調整篩選條件，以檢視不只是所選測試點的執行歷程記錄，也可以檢視整個測試案例的執行歷程記錄。

Test Plans 進度報表

此現成報表可協助您追蹤專案中一或多個 Test Plans的執行和狀態。 請流覽 Test Plans > 進度報表* 以開始使用報表。

報表的三個區段包含下列各項：

1. 摘要：顯示所選測試計劃的合併檢視。
2. 結果趨勢：轉譯每日快照集，為您提供執行和狀態趨勢線。 它可以顯示 14 天的數據， (預設) 、30 天或自定義範圍。
3. 詳細數據：本節可讓您依每個測試計劃向下切入，並提供每個測試套件的重要分析。

Artifacts

注意

Azure DevOps Server 2020 不會在數據匯入期間匯入回收站中的摘要。 如果您想要匯入回收站中的摘要，請在開始數據匯入之前，從回收站還原它們。

授權表達式和內嵌授權

現在，您可以在流覽 Visual Studio 中的套件時，查看儲存在 Azure Artifacts 中的 NuGet 套件授權資訊詳細數據。 這適用於使用授權表達式或內嵌授權表示的授權。 現在，您可以在 Visual Studio 套件詳細數據頁面中看到授權資訊的連結， (下圖中的紅色箭號) 。

按兩下連結會帶您前往網頁，您可以在其中檢視授權的詳細數據。 此體驗適用於授權表達式和內嵌授權，因此您可以在一個地方看到儲存在 Azure Artifacts 中的套件授權詳細數據， (指定授權資訊且 Visual Studio) 所支援的套件。

輕量型驗證工作

您現在可以使用輕量驗證工作，向 Azure Pipelines 的熱門套件管理員進行驗證。 這包括 NuGet、npm、PIP、Twine 和 Maven。 之前，您可以使用提供大量功能的工作來向這些套件管理員進行驗證，包括發佈和下載套件的能力。 不過，這需要針對與封裝管理員互動的所有活動使用這些工作。 如果您有執行自己的腳本來執行像是發佈或下載套件等工作，則無法在管線中使用它們。 現在，您可以在管線 YAML 中使用自己的設計腳本，並使用這些新的羽量型工作執行驗證。 使用 npm 的範例：

此圖中使用 「ci」 和 「publish」 命令是任意的，您可以使用 Azure Pipelines YAML 支援的任何命令。 這可讓您完全控制命令調用，並讓您輕鬆地在管線設定中使用共用腳本。 如需詳細資訊，請參閱 NuGet、 npm、 PIP、 Twine 和 Maven 驗證工作檔。

摘要頁面載入時間的改善

我們很高興宣布，我們已改善摘要頁面載入時間。 平均而言，摘要頁面載入時間已減少10%。 最大的摘要已看到最大百分位數摘要頁面載入時間， (所有摘要中最高 99% 的載入時間，) 減少 75%。

使用公用摘要公開共用您的套件

您現在可以在公用摘要內建立和儲存您的套件。 儲存在公用摘要內的套件可供因特網上的所有人使用，而不需要驗證、不論是在您的集合中，還是甚至登入 Azure DevOps 集合。 深入瞭解摘要 檔中 的公用摘要，或直接進入我們的 教學課程，以公開共用套件。

在 AAD 租使用者內的不同集合中設定上游

您現在可以將摘要新增至與 Azure Active Directory 相關聯的另一個集合， (AAD) 租用戶作為成品摘要的上游來源。 您的摘要可以從設定為上游來源的摘要中尋找和使用套件，讓套件可在與 AAD 租使用者相關聯的集合之間輕鬆共用。 請參閱如何在 文件中設定此專案。

使用 Python 認證提供者向 Azure Artifacts 摘要驗證 pip 和 twine

您現在可以安裝和使用 Python 認證提供者 (artifacts-keyring) 來自動設定驗證，以在 Azure Artifacts 摘要中發行或取用 Python 套件。 使用認證提供者時，您不需要設定任何組態檔 (pip.ini/pip.conf/.pypirc) ，您只會在第一次呼叫 pip 或 twine 時，透過網頁瀏覽器中的驗證流程來取得。 請參閱 檔中的詳細資訊。

Visual Studio 套件管理員中的 Azure Artifacts 摘要

我們現在會在 Visual Studio NuGet 套件管理員中顯示套件圖示、描述和作者，以取得從 Azure Artifacts 摘要提供的套件。 先前，大部分的元數據並未提供給 VS。

已更新連線至摘要體驗

[聯機至摘要] 對話框是使用 Azure Artifacts 的進入方式;其中包含如何設定用戶端和存放庫，以從 Azure DevOps 中的摘要推送和提取套件的相關信息。 我們已更新對話框，以新增詳細的設定資訊，並擴充我們提供相關指示的工具。

公用摘要現已正式推出上游支援

公開摘要的公開預覽已獲得絕佳的採用和意見反應。 在此版本中，我們已將其他功能延伸至正式運作。 現在，您可以從私人摘要將公用摘要設定為上游來源。 您可以讓組態檔保持簡單，方法是能夠從私人和專案範圍的摘要中上游。

從入口網站 Create 專案範圍的摘要

當我們發行公用摘要時，我們也會發行 專案範圍的摘要。 到目前為止，專案範圍的摘要可以透過 REST API 或建立公用摘要，然後開啟專案私用來建立。 現在，如果您有所需的許可權，您可以直接從入口網站中建立專案範圍的摘要。 您也可以查看哪些摘要是專案，哪些是摘要選擇器中的集合範圍。

npm 效能改善

我們已變更核心設計，以改善我們在 Azure Artifacts 摘要中儲存和傳遞 npm 套件的方式。 這可協助我們針對 npm 的一些最高使用 API 達到最多 10 倍的延遲降低。

協助工具增強功能

我們已部署修正，以解決摘要頁面上的輔助功能問題。 修正包括下列各項：

• Create 摘要體驗
• 全域摘要設定體驗
• 聯機到摘要體驗

Wiki

程式代碼Wiki頁面的豐富編輯

先前，編輯程式代碼Wiki頁面時，系統會將您重新導向至 Azure Repos 中樞進行編輯。 目前，存放庫中樞未針對 Markdown 編輯進行優化。

現在您可以在Wiki內的並存編輯器中編輯程式代碼Wiki頁面。 這可讓您使用豐富的 Markdown 工具列來建立內容，讓編輯體驗與專案 Wiki 中的編輯體驗相同。 您仍然可以選擇在存放庫中編輯，方法是選取操作功能表中的 [ 在 Repos 中編輯 ] 選項。

從Wiki頁面 Create和內嵌工作專案

當我們聆聽您的意見反應時，我們聽到您使用Wiki來擷取腦力激蕩檔、規劃檔、功能的想法、規格檔、會議分鐘數。 現在您可以直接從規劃檔建立功能和用戶劇本，而不需要離開Wiki頁面。

若要建立工作專案，請選取您要內嵌工作專案之Wiki頁面中的文字，然後選取[ 新增工作專案]。 這可節省您的時間，因為您不需要先建立工作專案，請移至編輯，然後尋找要內嵌的工作專案。 當您未離開Wiki範圍時，它也會減少內容切換。

若要深入瞭解如何從Wiki建立和內嵌工作專案，請參閱 這裡的檔。

Wiki 頁面中的批注

之前，您沒有辦法與Wiki內的其他Wiki用戶互動。 這讓內容共同作業並回答問題，因為交談必須透過郵件或聊天頻道進行。 有了批注，您現在可以直接在Wiki中與其他人共同作業。 您可以利用 @mention 批注內的使用者功能來吸引其他小組成員的注意力。 這項功能已根據 此建議票證設定優先順序。 如需有關批注的詳細資訊，請參閱 這裡的檔。

從 「開始隱藏資料夾和檔案」。 在Wiki樹狀結構中

到目前為止，Wiki 樹狀結構會顯示所有資料夾和檔案，從wiki樹狀結構中的點 (.) 開始。 在程式代碼Wiki案例中，這會導致 .vscode 之類的資料夾隱藏在Wiki樹狀結構中。 現在，以點開頭的所有檔案和資料夾都會隱藏在Wiki樹狀結構中，因而減少不必要的雜亂。

這項功能已根據 此建議票證設定優先順序。

簡短且可讀取的Wiki頁面URL

您不再需要使用多行 URL 來共用 Wiki 頁面連結。 我們會利用 URL 中的頁面標識碼來移除參數，因此 URL 較短且更容易閱讀。

URL 的新結構看起來會像這樣：

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

這是 歡迎使用 Azure DevOps Wiki 頁面的新 URL 範例：

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

這會根據 開發人員社群 的這項功能建議票證來排定優先順序。

用於編輯Wiki頁面的同步捲動

編輯Wiki頁面現在更容易在編輯與預覽窗格之間同步捲動。 在一端捲動會自動捲動另一端，以對應對應的區段。 您可以使用切換按鈕來停用同步捲動。

注意

同步捲動切換的狀態會儲存每位用戶和帳戶。

Wiki 頁面的頁面流覽

您現在可以深入瞭解Wiki頁面的頁面流覽。 REST API 可讓您存取過去 30 天內的資訊頁面。 您可以使用此資料來建立Wiki頁面的報表。 此外，您可以將此資料儲存在數據源中，並建立儀錶板以取得特定見解，例如 前 n 個最常檢視的頁面。

您也會在每個頁面中看到過去 30 天的匯總頁面流覽計數。

注意

頁面流覽是以 15 分鐘間隔定義為指定使用者的頁面檢視。

報表

管線失敗和持續時間報告

計量和深入解析可協助您持續改善管線的輸送量和穩定性。 我們新增了兩個新的報告，讓您深入了解管線。

1. 管線失敗報告會顯示組建通過率和失敗趨勢。 此外，它也會顯示工作失敗趨勢，以提供管線中哪些工作造成失敗數目上限的深入解析。

2. 管線持續時間報告會顯示管線執行所花費的時間趨勢。 它也會顯示管線中的哪些工作花費最多時間。

查詢結果小工具的改善

查詢結果小工具是我們最受歡迎的小工具之一，基於良好理由。 小工具會直接在您的儀錶板上顯示查詢的結果，而且在許多情況下很有用。

透過此更新，我們包含許多長時間等候的改善：

• 您現在可以選取您想要在小工具中顯示的數據行數目。 沒有超過 5 欄的限制！
• 小工具 支援各種大小，從 1x1 到 10x10。
• 當您調整數據行的大小時， 將會儲存數據行寬度。
• 您可以將 小工具展開為全螢幕檢視。 展開時，它會顯示查詢所傳回的所有數據行。

潛在客戶和週期時間小工具進階篩選

小組會使用潛在客戶和週期時間來查看工作流程流經其開發管線所需的時間，最終將價值傳遞給客戶。

到目前為止， 潛在客戶和週期時間小工具 不支援進階篩選準則來詢問問題：「我的小組關閉較高優先順序的專案需要多久？」

透過這項更新問題，您可以藉由篩選面板的泳道來回答。

我們也包含工作專案篩選條件，以限制出現在圖表中的工作專案。

使用本文點的內嵌短期衝刺待用

您的短期衝刺待處理現在可以依劇本進行待處理。 這可解決來自 開發人員社群 的意見反應。

從 Sprint 中樞選取 [分析] 索引標籤。然後設定您報告，如下所示：

1. 選取 [劇本待辦專案]
2. 選取以在劇本點總和上進行待用

Sprint Burndown 小工具，其中包含您要求的所有專案

新的短期衝刺待處理小工具可透過分鏡點、工作計數或加總自定義字段來減少。 您甚至可以建立功能或 Epic 的短期衝刺待用。 小工具會顯示平均待用、完成百分比和範圍增加。 您可以設定小組，讓您在同一個儀錶板上顯示多個小組的短期衝刺待處理。 為了顯示這項絕佳的信息，我們可讓您在儀錶板上將它大小調整為 10x10。

若要試用，您可以從小工具類別目錄新增它，或編輯現有Sprint待處理小工具的設定，然後核取 [ 立即試用新版本 ] 方塊。

注意

新的小工具會使用 Analytics。 如果您無法存取 Analytics，我們會保留舊版短期衝刺待用。

內嵌短期衝刺待用縮圖

Sprint Burndown 已返回！ 在幾個短期衝刺之前，我們已從短期衝刺待用和Taskboard標頭中移除內容中的短期衝刺待處理。 根據您的意見反應，我們已改善並重新引入短期衝刺待用縮圖。

按兩下縮圖會立即顯示較大的圖表版本，並可選擇在 [分析] 索引標籤下檢視完整報表。對完整報表所做的任何變更都會反映在標題中顯示的圖表中。 因此，您現在可以根據劇本、劇本點或工作計數來設定它，而不只是剩餘的工作量。

在沒有小組的情況下 Create 儀錶板

您現在可以建立儀錶板，而不與小組建立關聯。 建立儀錶板時，請選取 [項目儀錶板 ] 類型。

項目儀錶板就像小組儀錶板，不同之處在於它與小組沒有關聯，而且您可以決定誰可以編輯/管理儀錶板。 就像小組儀錶板一樣，專案中的每個人都可以看到它。

所有需要小組內容的 Azure DevOps 小工具都已更新，讓您在其設定中選取小組。 您可以將這些小工具新增至 [項目儀錶板]，然後選取您想要的特定小組。

注意

針對自定義或第三方小工具，專案儀錶板會將預設小組的內容傳遞至這些小工具。 如果您有依賴小組內容的自定義小工具，您應該更新設定，以讓您選取小組。

---

意見反應

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

---

頁面頂端