在本文中，您將找到 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 0.2 Patch 6 發行日期：2023 年 11 月 14 日

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

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

安裝修補程式

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

使用 TFX 更新工作

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 日
我們已發行 Azure Pipelines 代理程式的更新，修補程式 4 於 2023 年 9 月 12 日發行。 如果您未如修補程式 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 許可權提升弱點。
請將修補程式部署到測試環境，並確定環境的管線在將修正套用至生產環境之前如預期般運作。
若要實作此修補程式的修正程式，您必須遵循許多步驟來手動更新代理程式和工作。
安裝修補程式
下載並安裝 Azure DevOps Server 2020 Update 0.2 patch 4。
更新 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 0.2 Patch 3 發行日期：2023 年 8 月 8 日
我們已發行 Azure DevOps Server 2020 Update 0.2 的 修補程式，其中包含下列的修正程式。
已修正從 2018 或更早版本升級時干擾推送套件的錯誤。
Azure DevOps Server 2020 Update 0.2 Patch 2 Release Date：2023 年 6 月 13 日
我們已發行 Azure DevOps Server 2020 Update 0.2 的 修補程式，其中包含下列的修正程式。
已修正從 2018 或更早版本升級時影響封包推送的錯誤。
Azure DevOps Server 2020 Update 0.2 Patch 1 Release Date：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 是 Bug 修正的匯總。 您可以直接安裝 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 日
我們已針對 Azure DevOps Server 2020.0.1 發行 修補程式，其中包含下列的修正程式。
使用工作專案中的 @mention 控件時，不會傳送電子郵件通知。
修正切換帳戶時發生TF400813錯誤。 從 TFS 2018 升級至 Azure DevOps Server 2020.0.1 時發生此錯誤。
修正 [專案概觀摘要] 頁面無法載入的問題。
Active Directory 使用者同步處理的改善。
藉由從log4j二進位檔中移除 jndilookup 類別來解決 Elasticsearch 弱點。
使用 Patch 9升級伺服器。
檢查 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 9升級伺服器。
檢查 HKLM:\Software\Elasticsearch\Version的登錄值。 如果登錄值不存在，請新增字串值，並將 Version 設定為 5.4.1（Name = Version， Value = 5.4.1）。
將名為 zip 的資料夾內容複製到 Elasticsearch 遠端檔案資料夾 C:\Program Files\{TFS Version Folder}\Search\zip。
在 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 的 Patch 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 修補程式 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 的 Patch 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。 Azure DevOps Server 2020.0.1 預設會安裝至 c:\Program Files\Azure DevOps Server 2020。 安裝 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。 Azure DevOps Server 2020.0.1 預設會安裝至 c:\Program Files\Azure DevOps Server 2020。 安裝 Azure DevOps Server 2020.0.1 Patch 2 之後，版本會是 18.170.31123.3。

AzureResourceGroupDeploymentV2 任務安裝
下列所有步驟都必須在 Windows 電腦上執行
將 AzureResourceGroupDeploymentV2.zip 套件解壓縮到您電腦上的新資料夾。 例如：D：\tasks\AzureResourceGroupDeploymentV2。
請根據您的電腦來下載並安裝 Node.js 14.15.1 和 npm（隨 Node.js 下載附帶）。
在系統管理員模式中開啟命令提示字元，然後執行下列命令以安裝 tfx-cli。
npm install -g tfx-cli
建立具有 完整存取權 許可權的個人存取令牌，並加以複製。 執行 tfx 登入 命令時，將會使用此個人存取令牌。
從命令提示字元執行下列命令。 出現提示時，請輸入 [服務 URL] 和 [個人存取令牌]。
~$ tfx login
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
執行以下命令將任務上傳到伺服器。 使用從步驟 1 擷取 .zip 檔案的路徑。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*
AzureResourceManagerTemplateDeploymentV3 任務安裝
下列所有步驟都必須在 Windows 電腦上執行
將 AzureResourceManagerTemplateDeploymentV3.zip 套件解壓縮到您電腦上的新資料夾。 例如：D：\tasks\AzureResourceManagerTemplateDeploymentV3。
根據您的機器需求，下載並安裝 Node.js 14.15.1 和 npm（隨 Node.js 下載一起提供）。
在系統管理員模式中開啟命令提示字元，然後執行下列命令以安裝 tfx-cli。
npm install -g tfx-cli
建立具有 完整存取權 許可權的個人存取令牌，並加以複製。 執行 tfx 登入 命令時，將會使用此個人存取令牌。
從命令提示字元執行下列命令。 出現提示時，請輸入 [服務 URL] 和 [個人存取令牌]。
~$ tfx login
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
執行下列命令以將工作上傳到伺服器。 使用從步驟 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 Patch 2中發行的修正。
Azure DevOps Server 2020 Patch 3 發行日期：2021 年 2 月 9 日
我們已針對 Azure DevOps Server 2020 發行 修補程式，以修正下列各項。 如需詳細資訊，請參閱 部落格文章。
解決在開發人員社群意見反應票證 中報告的此問題| [新增測試案例] 按鈕無法運作
Azure DevOps Server 2020.0.1 發行日期：2021 年 1 月 19 日
Azure DevOps Server 2020.0.1 是 Bug 修正的匯總。 您可以直接安裝 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 可能會在升級後停止運作。
修正升級至 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 Patch 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 發行日期：2020 年 10 月 6 日
Azure DevOps Server 2020 是 Bug 修正的匯總。 其中包含先前發行的 Azure DevOps Server 2020 RC2 中的所有功能。
Azure DevOps 2020 Server 安裝 Git 虛擬文件系統所使用的其中一個元件時出現問題。
如果您要從 Azure DevOps 2019（任何版本）或 Azure DevOps 2020 候選版升級，並安裝到與上一個版本相同的目錄，則不會安裝元件 Microsoft.TeamFoundation.Git.dll。  您可以在 <Install Dir>\Version Control Proxy\Web Services\bin、 <Install Dir>\Application Tier\TFSJobAgent 和 <Install Dir>\Tools 資料夾中尋找 Microsoft.TeamFoundation.Git.dll，以確認您已遇到問題。  如果檔案遺失，您可以執行修復來還原遺失的檔案。
若要執行修復，請移至 Azure DevOps Server 機器/VM 上的 Settings -> Apps & Features，然後在 Azure DevOps 2020 伺服器上執行修復。  修復完成後，您可以重新啟動電腦/VM。
Azure DevOps Server 2020 RC2 發行日期：2020 年 8 月 11 日
Azure DevOps Server 2020 RC2 是 Bug 修正的匯總。 其中包含先前發行的 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頁面的豐富編輯
              管道故障和時間長度報告
您也可以跳至個別區段，以查看每個服務的新功能：
              Repos
Azure DevOps CLI 正式推出
在 2 月，我們引進了適用於 Azure CLI 的 Azure DevOps 擴充功能。 延伸模組可讓您從命令行與 Azure DevOps 互動。 我們已收集您的意見反應，協助我們改善擴充功能並新增更多命令。 我們很高興地宣布擴充功能已正式推出。
若要深入瞭解 Azure DevOps CLI，請參閱這裡的檔 。

使用發佈配置檔從部署中心部署適用於 Windows 的 Azure WebApps
現在您可以使用發佈設定檔驗證，從部署中心將 Windows 版 Azure WebApps 部署。 如果您有使用其發行配置檔部署至適用於 Windows 的 Azure WebApp 的許可權，您可以在部署中心工作流程中使用此設定檔來設定管線。
將 「父工作專案」篩選新增至工作面板和短期衝刺待辦專案
我們已將新的篩選新增至Sprint看板和Sprint待辦清單。 這可讓您依父項篩選需求階層的待辦事項（最左邊的第一欄）。 例如，在下面的屏幕截圖中，我們已篩選畫面，只顯示父系為「我的大功能」的使用者故事。
從命令列管理迭代和區域路徑
您現在可以使用 az boards iteration 和 az boards area 命令，從命令行管理反覆項目和區域路徑。 例如，您可以從 CLI 以互動方式設定和管理反覆項目和區域路徑，或使用腳本將整個設定自動化。 如需命令和語法的詳細資訊，請參閱這裡的檔案 。

工作項目父欄作為欄選項
您現在可以選擇在產品待辦清單或衝刺待辦清單中查看每個工作項目的父項。 若要啟用此功能，請前往所需待辦專案的 [欄位選項]，然後新增 [父欄位]。
使用三份新的 Azure Boards 報告，取得小組健康情況的深入解析
您無法修正無法看到的內容。 因此，您想要密切關注其工作程序的狀態和健康情況。 透過這些報告，我們可讓您更輕鬆地在 Azure Boards 中追蹤重要計量。
這三個新的互動式報告包括：燒毀圖（Burndown）、累計流程圖（Cumulative Flow Diagram, CFD）和 速度。 您可以在新的分析索引標籤中看到報告。
計算指標如短衝進度圖、工作流程和團隊速度等，可提供您對團隊進度的可視性，並協助回答下列問題：
在這個短期衝刺中，我們剩下多少工作？ 我們正要完成嗎？
開發程式哪一個步驟花費的時間最長？ 我們能做點什麼嗎？
根據先前的迭代，我們應該為下一個衝刺規劃多少工作量？
之前顯示在標題中的圖表已被替換為這些增強的報告。
新的報表是完全互動式的，可讓您調整它們以符合您的需求。 您可以在每個中心的 [分析] 索引標籤中找到新的報告。
您可以在 衝刺 樞紐下找到燒毀圖表。
Sprint Burndown 和 Velocity 報表可以設定為使用工作項目計數或剩餘工作的總和。
您可以調整衝刺燃盡圖的時間框架，而不會影響專案日期。 因此，如果您的團隊通常會將每次衝刺的第一天用於規劃，您現在可以調整圖表來反映這一點。
燃燒圖現在有一個顯示週末的浮水印。
「CFD」報表讓您移除像是「設計」這樣的看板欄位，以更專注於小組可以掌控的流程。
以下是顯示過去 30 天「故事待辦專案」流程的CFD報表範例。
此功能的優先順序是根據 開發者社群 的建議。
在待辦事項列表上切換顯示或隱藏已完成的子項目
很多時候，在精簡待辦專案時，您只想看到尚未完成的專案。 現在，您可以在待辦項目上顯示或隱藏已完成的子專案。
如果切換為開啟狀態，您會看到所有子項目處於已完成狀態。 切換關閉時，所有處於已完成狀態的子項目都會從待辦項目隱藏。
新增工作專案 URL 參數
使用新的工作項目 URL 參數，將工作項目的連結與看板或待辦清單的內容分享。 您現在可以在面板、待辦專案或短期衝刺體驗上開啟工作項目對話框，方法是將 參數 ?workitem=[ID] 附加至 URL。
您與 共用連結的任何人，都會以您共用連結時擁有的相同內容登陸！
在文字欄位中提及人員、工作專案和 PR
當我們聆聽您的意見反應時，我們聽說您希望能夠在工作專案描述區域（和其他 HTML 欄位）中提及人員、工作專案和 PR，而不只是在批注中提及。 有時候您需要與某人在工作項目上協作，或者想要在工作項目描述中強調一個 PR，但卻找不到方法來新增該資訊。 現在，您可以在工作專案的所有長文字欄位中提及人員、工作專案和 PR。
您可以在這裡看到範例。
若要使用人員提及，請輸入 @ 符號和您想要提及的人員名稱。 工作專案欄位中的 @mentions 會像對評論一樣產生電子郵件通知。
若要使用工作專案提及，請輸入 # 符號，後面接著工作專案標識碼或標題。 #mentions 會建立兩個工作專案之間的連結。
若要使用PR提及，請新增 ！ 後面接著您的PR標識碼或名稱。
討論評論的反應
我們的主要目標之一是讓工作專案對小組更具共同作業性。 最近，我們在 Twitter 上進行了 民意調查，以瞭解您在工作項目的討論中想要哪些共同作業功能。 在評論中增加反應贏得了民意測驗，所以我們就加入了！ 以下是 Twitter 投票的結果。
使用面板待辦項目匯總追蹤父專案的進度
匯總欄位顯示階層內數值欄位或子項目的進度列和/或總計。 子系項目對應於層次結構中的所有子項目。 您可以將一或多個匯總欄新增至產品或組合待辦清單。
例如，我們在這裡顯示 [按工作項目顯示進度]，它根據已關閉的子代項目的百分比顯示父代工作項目的進度條。 Epics 的子代專案包括所有子功能及其子工作專案或子系工作專案。 Features 的子系專案包含所有子用戶劇本及其子工作專案。
任務板即時更新
您的工作面板現在會在發生變更時自動重新整理！ 當其他小組成員移動或重新排列工作面板上的卡片時，您的面板會自動更新這些變更。 您不再需要按 F5 來查看最新的變更。
支援彙總欄中的自定義欄位
匯總現在可以在任何欄位上完成，包括自定義欄位。 新增彙總欄時，您仍然可以從快速清單中挑選彙總欄，不過，如果您想要彙總不在預設流程範本中的數字欄位，您可以按如下方式設定您自己的欄位：
在您的待辦專案上，按兩下 [資料行選項]。 然後在面板中按下[新增匯總資料行]，設定自訂匯總。
請注意，按兩下 [確定] 之後，您無法編輯自訂資料行。 如果您需要進行變更，請移除自定義數據行，並視需要新增另一個數據行。
根據條件隱藏工作項目表單中的欄位的新規則
我們已將新規則新增至繼承的規則引擎，讓您隱藏工作項目表單中的字段。 此規則會根據使用者群組成員資格隱藏欄位。 例如，如果使用者屬於「產品擁有者」群組，則您可以隱藏開發人員特定字段。 如需詳細資訊，請參閱這裡的檔案 ，。
自訂工作專案通知設定
掌握與您或小組相關的工作專案的最新狀態非常重要。 它可協助小組共同作業並持續追蹤專案，並確保所有相關方都參與其中。 不過，不同的項目關係人在不同的工作中有不同的投資水平，我們相信應該反映在您追蹤工作項目狀態的能力中。
先前，如果您想要追蹤工作專案並取得任何變更的通知，您會收到任何和對工作專案所做的所有變更的電子郵件通知。 考慮您的意見反應之後，我們將使所有相關人員更靈活地跟進工作項目。 現在，您會看到工作項目右上角 [遵循] 按鈕旁的一個新的設定按鈕。 這會帶您前往彈出視窗，讓您設定下列選項。
使用關鍵詞透過提交解決工作項目
您現在可以使用像 修正、修復或 修正這樣的關鍵詞，透過提交到預設分支來解決工作項目。 例如，您可以在提交訊息中撰寫「此變更已修正 #476」，當提交被推送或合併至預設分支時，工作專案 #476 將會完成。
如需詳細資訊，請參閱這裡的檔案 ，。
自動檢閱者的粒度
先前，將群組層級的檢閱者新增至拉取請求時，只需要來自該群組的單一批准。 現在，您可以在新增自動檢閱者時，設定需要小組中的多個檢閱者核准提取要求的原則。 此外，您可以新增原則，以防止要求者核准自己的變更。
使用服務帳戶型驗證來連線到 AKS
先前，從 AKS 部署中心設定 Azure Pipelines 時，我們使用 Azure Resource Manager 連線。 此連線可存取整個叢集，而不只是設定管線的命名空間。 透過此更新，我們的管線會使用服務帳戶型驗證來連線到叢集，使其只能存取與管線相關聯的命名空間。
預覽提取要求中的 Markdown 檔案並存差異
您現在可以使用新的 Preview 按鈕來查看 Markdown 檔案的外觀預覽。 此外，您可以從並排差異中查看檔案的完整內容，只需選取 [檢視] 按鈕。
此功能的優先順序是根據開發人員社群  建議來提供類似的體驗。 我們將繼續開放問題單，並鼓勵使用者告訴我們您想要查看的其他推送策略類型。

在提取要求中將檔案標示為已檢閱
有時候，您需要檢閱包含大量檔案變更的提取要求，而且很難追蹤您已檢閱的檔案。 現在您可以在提取要求中將檔案標示為已檢閱。
您可以使用檔名旁的下拉功能表，或暫留並按下檔名，將檔案標示為已檢閱。
這項功能只會在您檢閱提取要求時追蹤進度。 它並不代表對提取要求進行投票，因此檢閱者只會看到這些標記。
此功能的優先順序是根據 開發人員社群的建議。
適用於 Azure Repos 登陸頁面的新 Web UI
您現在可以試用 Azure Repos 內新的新式、快速和行動裝置型登陸頁面。 這些頁面 新的 Repos 登陸頁面。  著陸頁面包括除了拉取請求詳細資訊、提交詳細資訊和分支比較之外的所有頁面。
改善 PR 的實用性和效能
當您有許多提取要求要檢閱時，瞭解您應該先採取動作的位置可能會很困難。 若要改善提取要求可採取動作性，您現在可以在提取要求清單頁面上建立多個自定義查詢，其中包含數個新選項來篩選，例如草稿狀態。 除了「由我建立」和「指派給我」之外，這些查詢還會在您的提取要求頁面上建立個別且可折疊的區段。 您也可以拒絕檢閱透過 [投票] 選單或在拉取請求清單頁面上的內容選單中將您新增至的拉取請求。 在自定義區段中，您現在會看到已提供檢閱或拒絕檢閱之提取要求的個別索引標籤。 這些自定義查詢會在集合首頁的「我的提取要求」標籤上跨存放庫運作。 如果您想返回某個拉取請求，可以將其加上標記，這樣它們會顯示在清單頂端。 最後，已設定為自動完成的拉取請求將會在清單中以「自動完成」標籤標示。
多階段管線
我們一直在努力開發 新的用戶體驗， 以便管理您的管線。 這些更新可讓管線體驗現代化且與 Azure DevOps 的方向一致。 此外，這些更新會將傳統組建管線和多階段 YAML 管線整合成單一體驗。 它適用於行動裝置，併為您管理管線的方式帶來各種改善。 您可以深入分析並檢視管線詳細資訊、執行詳細資訊、管線分析、作業詳細資訊、日誌等等。
新的體驗包含下列功能：
檢視和管理多個階段
核准作業流程運行
在管線仍在進行中時，一路捲動回記錄
管線的每個分支健康情況。
YAML 中的持續部署
我們很高興提供 Azure Pipelines YAML CD 功能。 我們現在提供統一的 YAML 體驗，您可以將每個管線設定為執行 CI 或 CD，或同時執行 CI 和 CD。 YAML CD 功能引進數個新的進階功能，可供所有使用多階段 YAML 管線的集合使用。 部分重點包括：
              多階段 YAML 管線 （適用於 CI 和 CD）
              核准和檢查資源
              環境 和 部署策略
              Kubernetes 和 虛擬機 環境中的資源
              檢閱共同作業 的應用程式
              重新整理服務連線的UX
YAML 管線中的 資源
如果您已準備好開始建置，請參閱建置多階段 CI/CD 管線的 檔 或 部落格。
在 YAML 編輯器中管理管線變數
我們已更新在 YAML 編輯器中管理管線變數的體驗。 您不再需要移至傳統編輯器，即可在 YAML 管線中新增或更新變數。
關於如何開始使用管線的改進
使用入門向導的一個常見需求是能夠重新命名生成的文件。 目前，它會以存放庫根目錄的 azure-pipelines.yml 的形式簽入。 您現在可以在儲存管線之前，將此更改為不同的檔名或位置。
最後，當您將 azure-pipelines.yml 檔案簽入至不同的分支時，您將會有更多控制權，因為您可以選擇略過從該分支建立拉取請求。
預覽完整剖析的 YAML 文件，而不提交或執行管線。
我們已新增 預覽，但未針對 YAML 管線執行 模式。 現在，您可以試用 YAML 流程，而不需要將它提交至存放庫或執行它。 假設現有的管線和選擇性的新 YAML 承載，這個新的 API 會為您提供完整的 YAML 管線。 在未來的更新中，此 API 將會用於新的編輯器功能。
請開發人員將 POST 發送到 dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview，並附上如下的 JSON 主體：
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
回應會包含轉譯的 YAML。
YAML 中的 Cron 排程
以前，您可以使用 UI 編輯器來指定 YAML 管線的排程觸發器。 在此版本中，您可以使用 YAML 檔案中的 cron 語法來排程組建，並利用下列優點：




    

設定即程式碼：您可以將排程與管線一起追蹤作為程式碼的一部分。
表達力：在排程定義方面，您擁有比使用UI更強的表達能力。 例如，指定每小時執行一次的單一排程會比較容易。
業界標準：許多開發人員和系統管理員已經熟悉 cron 語法。
schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true
我們也使您更容易診斷 cron 排程的問題。 [執行管線] 功能表中的 [排程執行] 可讓您預覽管線即將進行的一些排程執行，以協助您診斷 cron 排程的錯誤。
略過 YAML 管線中的階段
當您開始手動執行時，有時可能會想要略過管線中的幾個階段。 例如，如果您不想將系統部署到生產環境，或想要略過生產環境中的某些部署。 您現在可以使用 YAML 管線來執行此動作。
更新的執行管線面板會顯示 YAML 檔案中的階段清單，而且您可以選擇略過其中一或多個階段。 略過階段時，您必須謹慎行事。 例如，如果您的第一個階段會產生後續階段所需的特定成品，則不應該略過第一個階段。 每當您略過具有下游相依性的階段時，執行面板就會顯示泛型警告。 是否將這些相依性視為真正的成果相依性，或僅僅是為了部署的排序而存在，由您決定。
Azure Pipelines 的 az 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 叢集命名空間的環境。
使用多階段 YAML 管線連結工作專案
目前，您可以自動連結工作專案與傳統組建。 然而，這對於 YAML 管線來說是不可能的。 透過此更新，我們已解決此差距。 當您使用指定分支的程式代碼成功執行管線時，Azure Pipelines 會自動將該執行與所有工作項目產生關聯（透過該程式碼中的提交推斷）。 當您開啟工作專案時，您將可以看到建立該工作專案的程式代碼執行。 若要進行此設定，請使用管線的設定面板。
取消多階段 YAML 管線執行中的階段
執行多階段 YAML 管線時，您現在可以在某個階段進行中時取消該階段。 如果您知道階段將會失敗，或者您有另一個想要啟動的運行，那麼這會很有説明。
重試失敗的步驟
多階段管線中最要求的功能之一，就是能夠重試失敗的階段，而不需要從頭開始。 透過此更新，我們會新增大部分的功能。
您現在可以在執行失敗時重試管道階段。 在第一次嘗試中失敗的任何作業，以及那些間接依賴於這些失敗作業的作業，都會重新嘗試。
這可協助您以數種方式節省時間。 例如，當您在階段中執行多個作業時，您可能會希望每個階段在不同的平臺上執行測試。 如果某個平臺上的測試在其他人通過時失敗，您可以藉由不重新執行通過的作業來節省時間。 另一個範例是，部署階段可能因為網路連線不穩定而失敗。 重新嘗試該階段可以幫助您節省時間，因為不需要再產生另一個建置。
這項功能有一些已知的差距。 例如，您無法重試明確取消的階段。 我們正在努力在未來更新中縮小這些差距。
多階段 YAML 管線中的核准
您的 YAML CD 管道可能包含手動核准。 基礎設施擁有者可以在任何管線的部署階段之前，保護其環境並尋求手動核准。
透過基礎結構（環境）和應用程式（管線）擁有者之間角色的完整隔離，您將確保在特定管線中的部署獲得手動批准，並取得集中權限，以將相同的檢查套用至所有環境中的部署。
增加門禁逾時限制和頻率
先前，發行流程中的閘道逾時限制是三天。 透過此更新，逾時限制已增加到 15 天， 允許持續時間較長的閘道。 我們也將閘口的頻率提高到 30 分鐘。
Dockerfile 的新組建映像範本
先前，在新管線建立中建立 Dockerfile 的新管線時，範本建議將映像推送至 Azure Container Registry 並部署至 Azure Kubernetes Service。 我們新增了範本，可讓您使用代理程式建置映像，而不需要推送至容器登錄。
Azure App Service 現在支援含預覽功能的交換
Azure App Service 現在支援 Swap，並在其部署插槽上使用預覽。 這是在應用程式實際從預備位置交換至生產位置之前，使用生產設定來驗證應用程式的好方法。 這也可確保目標/生產時段不會發生中斷。
Azure App Service 工作現在可透過下列新動作支援此多階段交換：
              開啟具有預覽的交換 - 啟動具有預覽功能的交換（多階段的交換），並將目標槽位（例如生產槽位）的配置套用到來源槽位。
              完成預覽交換 - 當您準備好完成擱置交換時，請選取 [使用預覽完成交換] 動作。
              取消預覽交換 - 若要取消擱置交換，請選取 [取消與預覽交換]。
YAML 管線中審核功能的增強
我們已啟用核准設定功能，適用於服務連線和代理程式集區。
如需核准，我們會遵循基礎結構擁有者和開發人員之間角色的隔離。 藉由在您的資源上設定核准，例如環境、服務連線和代理程式集區，您就能確保所有使用資源的管線執行都需要先核准。
此體驗類似於設定環境的核准。 當流程階段所引用的資源待核准時，管線的執行會暫停，直到手動核准管線為止。
Azure Pipelines 中的容器結構測試支援
應用程式中的容器使用量正在增加，因此需要強固測試和驗證。 Azure Pipelines 現在支援 容器結構測試。 此架構提供方便且功能強大的方法來驗證容器的內容和結構。
您可以根據可以一起執行的四種測試類別來驗證影像的結構：命令測試、檔案存在測試、檔案內容測試和元數據測試。 您可以使用管線中的結果來做出是否進行的決策。 測試數據可在管道執行中取得，並提供錯誤訊息，以協助您更好地排除故障。
輸入組態檔和映像詳細數據
發行管線的管線裝飾器
管道裝飾器允許將步驟新增至每個作業的開頭和結尾。 這與將步驟新增至單一定義不同，因為它會套用至集合中的所有管線。
我們一直在為建置和 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 策略，此策略會循序執行步驟。 在多階段管線中支援金絲雀策略時，您現在可以藉由緩慢地將變更推出給小部分來降低風險。 當您對新版本更有信心時，您可以開始將其推出至基礎結構中的更多伺服器，並將更多使用者路由傳送至該版本。
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...  
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...
Kubernetes 的 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
從管線收集自動和使用者指定的元數據
現在，您可以在管線任務中啟用自動和使用者指定的元數據收集。 您可以使用元數據透過 評估工件檢查，在環境上強制執行工件政策。
滾動部署會將舊版應用程式的實例取代為每個反覆專案中一組機器上新版應用程式的實例（滾動集）。
例如，以下滾動部署會在每次迭代中更新最多五個目標。 
              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...  
        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 檔案現在可以使用 關鍵詞 擴充，表示可以在另一個檔案中找到主要管線結構。 這可讓您控制可以擴充或改變哪些區段，以及哪些區段是固定的。 我們也已使用資料類型增強管道參數，以清楚說明您可以提供的掛鉤。
此範例說明如何為管線作者提供簡單的鉤子。 範本一律會執行組建、選擇性地執行管線所提供的其他步驟，然後執行選擇性的測試步驟。
# 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 checkout 。 現在，除了用來儲存 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 任務 的 bake 動作 下新增了 Kustomize 的選項，因此任何包含 kustomization.yaml 檔案的資料夾均可用於生成 KubernetesManifest 工作部署動作中使用的 manifest 文件。

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 叢集的互動式登入提示和失敗的管線。 為了解決此問題，我們新增了一個複選框，可讓您使用叢集管理員認證，而不是叢集用戶認證。
開源政策代理器安裝器任務
開放原則代理程式是開放原始碼、一般用途的原則引擎，可強制執行統一的內容感知原則。 我們已新增 [開放性政策代理] 安裝任務。 對於基礎設施即代碼提供者來說，在管道中強制執行策略特別有用。
例如，開放式原則代理程式可以評估管線中 Rego 原則檔案和 Terraform 計劃。
task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'
支援 Azure CLI 工作中的 PowerShell 腳本
先前，您可以在 Azure CLI 工作中執行批次和 bash 腳本。 透過此更新，我們已將PowerShell和PowerShell核心腳本的支援新增至工作。
KubernetesManifest 工作中以服務網格介面為基礎的 Canary 部署
先前，當在 KubernetesManifest 任务中指定金絲雀策略時，該任務會建立基準線和金絲雀工作負載，其副本數相當於用於穩定工作負載的副本數的百分比。 這與在請求層級上將流量切分到所需百分比並不完全相同。 為了解決此問題，我們已將 Service Mesh 介面的支援 型 Canary 部署新增至 KubernetesManifest 工作。
服務網格介面的抽象化允許透過服務網格提供者，例如 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 呼叫。 系統會為每個作業產生新的存取令牌，並在作業完成之後到期。 透過此更新，我們新增了下列增強功能。
              防止令牌存取小組專案外部的資源

到目前為止，所有管線的預設範疇都是團隊專案集合。 您可以將範圍變更為傳統組建管線中的小組專案。 不過，對於經典版發布或 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 中的發佈測試結果工作可讓您在執行測試時發佈測試結果，以提供完整的測試報告和分析體驗。 到目前為止，無論是測試執行還是測試結果，其測試附件的限制都是100MB。  這會限制上傳大型檔案，例如當機傾印或影片。 透過此更新，我們新增了大型測試附件的支援，讓您擁有所有可用的數據來針對失敗的測試進行疑難解答。
您可能會在記錄中看到 VSTest 工作或發佈測試結果工作傳回 403 或 407 錯誤。 如果您使用防火牆後方的自我裝載組建或發行代理程式來篩選輸出要求，您必須進行一些設定變更，才能使用這項功能。
只有在您使用自我裝載的 Azure Pipelines 代理程式，且您位於篩選輸出流量的防火牆後方時，才需要這樣做。 如果您在雲端中使用Microsoft裝載的代理程式，或未篩選輸出網路流量，則不需要採取任何動作。
顯示每個工作的正確集區資訊
先前，當您使用矩陣來展開工作或變數來識別集區時，我們有時會在記錄頁上解析到不正確的集區資訊。 這些問題已經解決。
新分支的 CI 觸發機制
一個長期以來的要求，就是在建立新分支且該分支沒有變更時，不要觸發 CI 組建。 請考慮下列範例：
您可以使用 Web 介面，根據現有的分支建立新的分支。 如果您的分支篩選符合新分支的名稱，這會立即觸發新的 CI 組建。 這是不必要的，因為與現有分支相比，新分支的內容相同。
您有一個存放庫，其中包含兩個資料夾 - 應用程式和檔案。您可以設定 CI 的路徑篩選條件，以符合 「應用程式」。 換句話說，如果變更已推送至檔，您就不想建立新的組建。您會在本機建立新的分支、對文件進行一些變更，然後將該分支推送至伺服器。 我們過去常常觸發新的 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 擴充功能 ，。
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 建立 Azure Pipelines
我們已將新功能新增至適用於 VSCode 的 Azure Pipelines 擴充功能。 現在，您將能夠直接從 VSCode 建立 Azure Pipelines，而不需要離開 IDE。
不穩定的 Bug 管理和解決方式
我們引入了不穩定測試管理，以支持從偵測、報告到解決的端對端生命週期。 為了進一步增強功能，我們正在新增不穩定測試錯誤的管理和解決方法。
在調查不穩定測試時，您可以使用 Bug 操作來建立 Bug，然後指派給開發人員，以進一步調查不穩定測試的根本原因。 Bug 報告包含管線的相關信息，例如錯誤訊息、堆疊追蹤和其他與測試相關聯的資訊。
當錯誤報告解決或關閉時，我們會自動將測試解除標記為不不穩定的。
如果未執行最少的測試數目，請將 VSTest 工作設定為失敗
VSTest 工作會使用使用者輸入來探索和執行測試（測試檔案、篩選準則等等），以及所使用之測試架構特有的測試配接器。 使用者輸入或測試配接器的變更可能會導致測試未被找到的情況，並且僅執行部分預期的測試。 這可能會導致管線運行成功的情況，因為測試被略過，而不是因為程式碼質量足夠高。 為了協助避免這種情況，我們在 VSTest 工作中新增了一個新選項，可讓您指定必須執行的測試數目下限，才能讓工作通過。
使用管線裝飾器自動在部署作業中注入步驟
您現在可以將 管線裝飾專案新增至部署作業。 您可以將任何自定義步驟（例如弱點掃描器）自動插入每個 生命周期攔截， 執行每個部署作業。 由於管線裝飾器可以套用到某集合中的所有管線，因此這可用來作為強制執行安全部署實務的一部分。
此外，如果已定義，部署作業可以當作 容器作業 以及 服務側車 來執行。
新增測試計劃頁面
新的測試計劃頁面 （Test Plans *） 可供所有 Azure DevOps 集合使用。 新頁面提供簡化的檢視，可協助您專注於手邊的工作 - 測試規劃、撰寫或執行。 它也與 Azure DevOps 供應項目的其餘部分不雜亂且一致。
我們建議為每個 sprint/版本建立新的測試計劃。 在這樣做時，一般而言，可以複製先前週期的測試計劃，並經過少量修改後，複製的測試計劃即可用於新的週期。 為了簡化此程式，我們已在新頁面上啟用「複製測試計劃」功能。 利用它，您可以複製或克隆測試計劃。 這裡介紹其支援的 REST API 和，且該 API 也可讓您在不同專案間複製或複寫測試計劃。

如需測試計劃使用方式的詳細資訊，請參閱這裡 。

              2. 測試套件樹狀結構

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

在測試套件樹狀結構上的右鍵選單提供下列選項：
              建立新套件：您可以建立 3 種不同類型的套件，如下所示：

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

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

              開啟/編輯測試案例工作專案表單：此選項可讓您使用工作專案窗體編輯測試案例，在其中編輯工作專案字段，包括測試步驟。
              編輯測試案例：此選項可讓您大量編輯測試案例工作專案欄位。 不過，您無法使用此選項大量編輯測試步驟。
              在方格中編輯測試案例：此選項可讓您大量編輯選取的測試案例，包括使用方格檢視的測試步驟。
              設定組態：此選項可讓您使用測試個案層級設定覆寫套件層級設定。
              移除測試案例：此選項可讓您從指定的套件中移除測試案例。 不過，它不會變更基礎測試案例的工作項目。
              建立測試案例的複本/複製：此選項可讓您建立所選測試案例的複本/複製。 如需詳細資訊，請參閱下方。
              檢視連結的專案：此選項可讓您查看指定測試案例的連結專案。 如需詳細資訊，請參閱下方。
              複製/克隆測試案例（新功能）

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

測試成品、需求和 Bug 之間的可追蹤性是 Test Plans 產品的重要價值主張。 使用 [檢視連結的專案] 選項，您可以輕鬆地查看此測試案例所連結的所有需求項目、使用此測試案例的所有測試組合/測試計畫，以及所有在測試執行過程中提交的錯誤。
              4.執行索引標籤

              什麼是測試點？ 測試案例本身不是可執行的。 當您將測試案例新增至測試套件時，會產生測試點。。 測試點是測試案例、測試套件、組態和測試人員的唯一組合。 範例：如果您有測試案例作為「測試登入功能」，並將 2 個設定新增至它作為 Edge 和 Chrome，則會產生 2 個測試點。 現在可以執行這些測試點。 在執行時，會產生測試結果。 透過測試結果檢視（執行歷程記錄），您可以看到測試點的所有執行。 測試點的最新執行是您在 [執行] 索引標籤中看到的內容。

因此，測試案例是可重複使用的實體。 藉由將它們包含在測試計劃或套件中，會產生測試點。 藉由執行測試點，您可以判斷所開發的產品或服務品質。

新頁面的主要優點之一是針對主要執行與追蹤測試的使用者（只需基本存取權限），他們不會被套件管理的複雜性弄得不知所措（對於這類使用者，「定義」標籤會被隱藏）。
[定義] 標籤和特定作業僅適用於具有 基本 + 測試計劃 存取層級或相等權限的使用者。 其他所有專案，包括 [執行] 索引標籤，都應該由具有 'Basic' 存取層級的用戶執行。
[執行] 索引標籤可讓您執行下列工作：
              大量標記測試點：此選項可讓您快速標記測試點的結果 - 通過、失敗、封鎖或不適用，而不需要透過測試執行器執行測試案例。 結果可以一次性標記一個或多個測試點。
              執行測試點：此選項可讓您個別執行每個測試步驟，並使用測試執行器將它們標示為通過/失敗，以執行測試案例。 根據您測試的應用程式，您可以使用「Web 執行器」來測試「Web 應用程式」或「桌面執行器」以測試桌面和/或 Web 應用程式。 您也可以調用「使用選項執行」，以指定要進行測試的目標建置。
              資料列選項：您可以使用 [資料行選項] 來管理 [執行] 索引標籤中顯示的數據列清單。 可供選取的數據行清單與測試點相關聯，例如執行者、指派的測試人員、組態等等。
              全螢幕檢視：您可以使用此選項，在全螢幕模式中檢視整個 [執行] 索引卷標的內容。
              篩選：使用篩選列，您可以使用「測試案例標題」、「指派給」、「狀態」、「測試結果」、「測試人員」和「組態」字段來篩選測試點清單。 您也可以按下資料列標頭來排序列表。
              內容選單選項

              將測試重設為使用中：此選項可讓您將測試結果重設為作用中，從而忽略測試點的最後一個結果。
              開啟/編輯測試案例工作專案表單：此選項可讓您使用工作專案窗體編輯測試案例，在其中編輯工作專案字段，包括測試步驟。
              指派測試人員：此選項可讓您將測試點指派給測試人員以進行測試執行。
              檢視測試結果：此選項可讓您檢視最新的測試結果詳細數據，包括每個測試步驟的結果、新增的批注或已提交的 Bug。
              檢視執行歷程記錄：此選項可讓您檢視所選測試點的整個執行歷程記錄。 它會開啟新的頁面，您可以在其中調整篩選條件，以檢視不僅選取的測試點的執行歷程記錄，還能檢視整個測試案例的執行歷程記錄。
測試計劃進度報告
此現成的報表可協助您追蹤專案中一或多個測試計劃的執行和狀態。 請瀏覽測試計劃 > 進度報告* 以開始使用報告。
Azure DevOps Server 2020 不會在數據匯入期間匯入回收站中的摘要。 如果您想要匯入回收站中的摘要，請在開始數據匯入之前，先從回收站還原它們。
授權表達式和內嵌授權
現在，您可以在 Visual Studio 中瀏覽套件時，查看儲存在 Azure Artifacts 中的 NuGet 套件授權資訊詳細數據。 這適用於使用授權表達式或內嵌授權表示的授權。 現在，您可以在 Visual Studio 套件詳細數據頁面中看到授權資訊的連結（下圖中的紅色箭號）。
在此圖中，使用 「ci」 和 「publish」 命令是任意的，您可以使用 Azure Pipelines YAML 支援的任何命令。 這可讓您完全控制命令調用，並讓您輕鬆地在管線設定中使用共用腳本。 如需詳細資訊，請參閱 NuGet、npm、PIP、Twine和 Maven 驗證工作檔。
改善動態頁面的載入時間
我們很高興宣布，我們已加速動態消息頁面的載入時間。 平均而言，動態消息頁面的載入時間已經減少了 10%。 最大的摘要已經看到最大的改善第99個百分位數摘要頁面載入時間（所有摘要中最高的99個% 的載入時間）減少了75%。
公開發佈你的套件並使用公用內容更新
您現在可以在公共資訊流內建立和儲存套件。 儲存在公用資訊來源中的套件可供所有網際網路上的人使用，無需驗證，不論它們是否在您的集合中，甚至無需登入 Azure DevOps 集合。 在 資料文件中深入瞭解公用訊息源， 或直接開始我們公開分享套件的 教學課程。
在 AAD 租使用者內的不同集合中設定上游
您現在可以將與 Azure Active Directory (AAD) 租戶相關聯的另一個集合中的饋送新增為您 Artifacts 饋送的上游來源。 您的資訊源可以從設定為上游來源的資訊源中尋找和使用套件，讓套件可在與 AAD 租用戶相關聯的集合之間輕鬆共用。 請參閱如何在檔 中設定此專案。
使用 Python 憑證提供者來驗證 pip 和 twine 的使用，以連接 Azure Artifacts 的饋送
您現在可以安裝和使用 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 的來源推送和擷取套件的資訊。 我們已更新對話框，以新增詳細的設定資訊，並擴充我們提供使用指導的工具。
公用供稿現已正式提供，上游整合支援
公共訊息源的公開預覽已受到廣泛的採用和回饋。 在此版本中，我們已將額外功能擴展至一般可用性。 現在，您可以將公用饋送設定為私人饋送的上游來源。 您可以通過上傳和下載組態至私人和專案範圍的饋送，來讓您的組態檔保持簡單。
從入口網站建立專案範圍的供稿來源
當我們發行公用摘要時，我們也會發行 專案範圍的摘要。 到目前為止，專案範圍的饋送可以透過 REST API 或建立公用饋送，然後將專案設為私用來建立。 現在，您可以在任何專案中直接在平台建立專案範圍的訊息源，只要您有相關的許可權。 您也可以在資訊流選擇器中查看哪些資訊流屬於專案範疇，哪些屬於集合範疇。
npm 效能改善
我們已變更核心設計，以改善我們在 Azure Artifacts 摘要中儲存和傳遞 npm 套件的方式。 這協助我們將 npm 的某些使用最頻繁的 API 的延遲最多降低至十分之一。
輔助功能改善
我們已部署修正程式，以解決動態消息頁面上的輔助功能問題。 修正程式包括下列各項：
建立資訊流體驗
全域信息流設定使用專案
連接至動態體驗
程式代碼 Wiki 頁面的豐富編寫
先前，編輯程式代碼Wiki頁面時，系統會將您重新導向至 Azure Repos 中樞進行編輯。 目前，存放庫中樞並未針對 Markdown 編輯進行優化。
現在，您可以在Wiki內的並存編輯器中編輯程式代碼Wiki頁面。 這可讓您使用豐富的 Markdown 工具列來建立內容，讓編輯體驗與專案 Wiki 中的內容相同。 您仍然可以選擇在存放庫中編輯，方法是在內容功能表中選取 在 Repos 中編輯 選項。
從Wiki頁面建立和內嵌工作專案
當我們聆聽您的意見反應時，我們聽說您使用Wiki來擷取腦力激蕩檔、規劃檔、功能的想法、規格檔、會議分鐘數。 現在，您可以直接從規劃檔建立功能和用戶劇本，而不需要離開Wiki頁面。
若要建立工作專案，請在Wiki頁面中選取您要內嵌工作專案的文字，然後選取 [[新增工作專案]。 這可節省您的時間，因為您不需要先建立工作專案，請移至編輯，然後尋找要內嵌的工作專案。 當您不離開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頁面的頁面訪問情況。 REST API 可讓您存取頁面在過去 30 天內瀏覽資訊。 您可以使用此資料來建立Wiki頁面的報告。 此外，您可以將此資料儲存在資料來源中，並建立儀錶板以獲得特定的洞見，例如 最多瀏覽的頁面。
您也會在每個頁面中看到過去 30 天的匯總頁面流覽計數。
              前導時間和週期時間 由小組用來查看工作流經其開發管線所需的時間，並最終為客戶創造價值。

到目前為止，領導和週期時間小工具 都不支援進階篩選準則來提出這樣的問題，例如：「我的小組需要多久才能關閉較高優先級的項目？」
藉由這次更新，這類問題可以透過篩選版面泳道來解決。
使用故事點的即時衝刺燃盡圖
你的衝刺燒毀現在可以被故事燒毀。 這是針對 開發人員社群的回饋而做的回應。
從 Sprint 中樞頁面選取 [分析] 索引標籤。然後，按如下所示設定您的報告：
選擇故事待辦事項
選擇用於燃盡圖的 故事點總和
按兩下縮圖會立即顯示較大的圖表版本，並可選擇在 [分析] 索引標籤下檢視完整報表。對完整報表所做的任何變更都會反映在標題中顯示的圖表中。 因此，您現在可以將它設定為根據故事、故事點或依工作計數進行燒毀，而不只是剩餘的工作量。
建立不屬於任何團隊的儀表板
您現在可以建立儀錶板，而不需與團隊關聯。 建立儀錶板時，請選取 [項目儀錶板] 類型。