Azure DevOps Server 2020 版本資訊

| 開發人員社群系統需求 | 授權條款 | 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 安全地升級至 Azure DevOps Server 2020 的詳細資訊,請參閱我們的部落格文章

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 控制項時,不會傳送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 Patch 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 修補程式。

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

一般修補程式安裝

如果您有 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
  1. 建立具有 完整存取權限 的個人存取權杖,並加以複製。 執行 tfx 登入 命令時,將會使用此個人存取權杖。

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

~$ tfx login
Copyright Microsoft Corporation

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

  1. 執行下列命令,在伺服器上上傳工作。 使用步驟 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
  1. 建立具有 完整存取權限 的個人存取權杖,並加以複製。 執行 tfx 登入 命令時,將會使用此個人存取權杖。

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

~$ tfx login
Copyright Microsoft Corporation

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

  1. 執行下列命令,在伺服器上上傳工作。 使用步驟 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 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 可能會在升級後停止運作。
  • 在升級至 2020 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 虛擬檔案系統所使用的其中一個元件 (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 是 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 引進許多新功能。 一些重點包括:

您也可以跳至個別區段,以查看每個服務的新功能:


一般

Azure DevOps CLI 正式運作

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

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

使用發佈設定檔從部署中心部署適用于 Windows 的 Azure WebApps

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

Boards

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

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

顯示新父工作專案篩選的螢幕擷取畫面。

改善錯誤處理體驗 – 錯誤/工作的必要欄位

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

顯示當您按一下紅色錯誤訊息時所顯示 [遺漏欄位] 對話方塊的螢幕擷取畫面。

工作專案即時重載

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

顯示工作專案即時重載運作方式的短片。

從命令列管理反復專案和區域路徑

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

工作專案父資料行作為資料行選項

您現在可以選擇在產品待辦專案或短期衝刺待辦專案中查看每個工作專案的父項。 若要啟用這項功能,請移至所需待辦專案上的 [ 資料行選項 ],然後新增 [父 資料行]。

待辦專案的螢幕擷取畫面,其中已指出 [資料行選項] 選項。

變更專案所使用的程式

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

[專案] 索引標籤的螢幕擷取畫面,其中已指出 [變更程式] 選項。

隱藏版面配置中的自訂欄位

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

顯示 [隱藏配置] 選項的螢幕擷取畫面。

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

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

這三個新的互動式報告包括: 待用累積流程圖 () 和 速度。 您可以在 [新增分析] 索引標籤中看到報告。

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

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

注意

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

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

  • 您可以在 短期衝刺 中樞底下找到待用圖表。

    [分析] 索引標籤上待用圖表的螢幕擷取畫面。

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

    [分析] 索引標籤上 [累計流程圖] 報表和 [速度] 報告的螢幕擷取畫面。

有了新的報表,您就有更多關於小組的控制權和資訊。 以下是一些範例:

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

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

[分析] 索引標籤上 [累計流程圖] 的螢幕擷取畫面。

現在可以追蹤所有待辦專案層級的速度圖表。 例如,您現在可以同時新增 Features 和 Epics,而在上一張圖表之前只支援需求。 以下是功能待辦專案最後 6 次反復專案的速度報告範例。

[分析] 索引標籤上 [速度] 圖表的螢幕擷取畫面。

自訂任務板資料行

我們很高興宣佈,我們新增了一個選項,讓您自訂 Taskboard 上的資料行。 您現在可以新增、移除、重新命名及重新排序資料行。

若要在 Taskboard 上設定資料行,請移至 [ 資料行選項]。

[任務面板] 的螢幕擷取畫面,其中已指出 [資料行選項] 選項。

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

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

許多時候,調整待辦專案時,您只想查看尚未完成的專案。 現在,您可以顯示或隱藏待處理專案上已完成的子專案。

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

顯示如何在待辦專案上顯示或隱藏子專案的短片。

標記工作專案時顯示的最新標記

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

顯示標記工作專案時所顯示最近使用標記的螢幕擷取畫面。標記標記

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

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

[新增工作專案規則] 對話方塊的螢幕擷取畫面,其中顯示 [條件] 區段和 [動作] 區段。

自訂系統挑選清單值

您現在可以自訂任何系統挑選清單的值 (,但 [原因] 欄位) 例如 [嚴重性]、[活動]、[優先順序] 等。挑選清單自訂的範圍是限定範圍,因此您可以針對每個工作專案類型管理相同欄位的不同值。

示範如何自訂系統挑選清單值的短片。

新增工作專案 URL 參數

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

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

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

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

您可以參閱這裡的範例。

顯示您可以在工作專案 [描述] 區域中提及人員、工作專案和 PR 的螢幕擷取畫面。

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

討論批註反應

我們的其中一個主要目標是讓工作專案對小組更具共同作業性。 我們最近在 Twitter 上進行了投票 ,以瞭解您在工作專案的討論中想要哪些共同作業功能。 將意見反應帶入投票,因此我們新增了意見! 以下是 Twitter 投票的結果。

Azure DevOps Twitter 投票的螢幕擷取畫面,其中顯示 35% 的回應者想要意見反應功能。

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

此螢幕擷取畫面顯示您可以將回應新增至兩種不同方式的批註。

將Azure Boards報表釘選到儀表板

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

顯示 [複製到儀表板] 選項的螢幕擷取畫面。

使用上層待辦專案匯總來追蹤父專案的進度

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

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

待辦專案中工作專案的螢幕擷取畫面。

工作面板即時更新

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

支援匯總資料行中的自訂欄位

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

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

    [新增匯總資料行] 下拉式清單的螢幕擷取畫面。

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

資料行選項面板的螢幕擷取畫面,其中顯示新的自訂資料行。

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

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

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

自訂工作專案通知設定

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

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

工作專案右上角的螢幕擷取畫面,其中游標停留在齒輪圖示上。

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

[通知設定] 對話方塊的螢幕擷取畫面,其中顯示已選取的 [自訂] 選項按鈕,以及 [狀態變更] 選項和 [反復專案變更] 選項。

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

顯示工作專案表單上 [部署] 控制項的螢幕擷取畫面。

從 CSV 檔案匯入工作專案

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

示範如何從 CSV 檔案匯入工作專案的短片。

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

您的 Kanban 面板現在已提供父內容,作為工作專案卡片的新欄位。 您現在可以將父欄位新增至卡片,略過使用標籤和前置詞等因應措施的需求。

顯示已呼叫 [父專案] 選項的工作專案卡片螢幕擷取畫面。

將父欄位新增至待辦專案和查詢

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

[資料行選項] 區段的螢幕擷取畫面,其中已指出 [父] 選項。

Repos

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

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

此螢幕擷取畫面顯示您可以在提取要求 (PR) 檢視內查看變更的程式碼涵蓋範圍計量。

提取要求差異的螢幕擷取畫面,其中顯示新增至檔案的新程式程式碼。

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

顯示 [新增狀態原則] 選項的螢幕擷取畫面,以及選取選項時出現的 [新增狀態原則] 區段。

從提取要求篩選批註通知

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

顯示如何從提取要求篩選批註通知的螢幕擷取畫面。

顯示 [篩選準則] 頁面和 [欄位] 下拉式清單內容的螢幕擷取畫面。

提取要求批註的服務勾點

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

新增服務勾點訂用帳戶精靈的螢幕擷取畫面。

封鎖具有指定模式之檔案的原則

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

顯示 [原則] 區段的螢幕擷取畫面,其中 [檔案名驗證] 選項設定為 [開啟]。

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

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

自動檢閱者的資料細微性

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

顯示 [自動包含檢閱者] 對話方塊的螢幕擷取畫面。

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

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

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

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

顯示專案中 Markdown 檔案的螢幕擷取畫面,其中已標注 [檢視和預覽] 選項。

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

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

[新增建置原則] 對話方塊的螢幕擷取畫面,其中包含 [組建到期] 區段。

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

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

此螢幕擷取畫面顯示 [原則] 索引標籤上所有 Git 存放庫的原則,其中 [認可作者電子郵件驗證] 選項設定為 [開啟]。

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

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

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

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

注意

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

此螢幕擷取畫面顯示檔案總管中的 [檢視] 和 [標示為檢閱的選項] 可見的專案。

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

Azure Repos登陸頁面的新 Web UI

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

Web

Azure Repos登陸頁面的新 Web UI 螢幕擷取畫面。

行動

Azure Repos登陸頁面的新行動 UI 螢幕擷取畫面。

跨存放庫分支原則管理

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

[新增分支保護] 對話方塊的螢幕擷取畫面。

新的 Web 平臺轉換登陸頁面

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

Web 體驗:

Web 平臺轉換登陸頁面的螢幕擷取畫面。

行動體驗:

行動平臺轉換檔案頁面的螢幕擷取畫面。

行動平臺轉換認可頁面的螢幕擷取畫面。

Kotlin 語言的支援

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

UI 中顯示的 Kotlin 檔案螢幕擷取畫面。

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

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

[新增訂用帳戶] 對話方塊的螢幕擷取畫面,其中顯示 [草稿] 已新增為 [篩選準則] 功能的選項。

改善 PR 可採取動作性

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

Pipelines

多階段管線

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

新體驗包含下列功能:

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

YAML 中的持續部署

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

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

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

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

顯示 [變數] 對話方塊的螢幕擷取畫面。

直接從版本中樞核准發行

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

顯示如何直接從發行中樞核准發行的螢幕擷取畫面。

Bitbucket 整合和其他開始使用管線的改善

管線的快速入門精靈體驗已更新為使用 Bitbucket 存放庫。 Azure Pipelines 現在會分析您的 Bitbucket 存放庫內容,並建議 YAML 範本供您進行。

開始使用精靈的常見要求是能夠重新命名產生的檔案。 目前,它會簽入為 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 管線中使用服務連線非常重要:管線授權和核准和檢查。

顯示 YAML 管線中 [編輯] 功能表的螢幕擷取畫面,其中會顯示 [核准和檢查] 選項。

這項更新 預設會開啟 新的使用者體驗。 您仍然可以退出宣告預覽。

注意

我們計畫引進 跨專案共用服務 連線作為新功能。 您可以 在這裡找到更多有關共用體驗和安全性角色的詳細資料。

略過 YAML 管線中的階段

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

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

顯示 [執行管線] 區段的螢幕擷取畫面,其中已指出 [要執行的階段] 選項。

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

顯示 [執行階段] 區段的螢幕擷取畫面,其中已選取 [開發] 選項和 [部署] 選項。

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

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

[執行管線] 對話方塊的螢幕擷取畫面。

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

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

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

[要執行的階段] 對話方塊的螢幕擷取畫面。

az Azure Pipelines 的 CLI 改善

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

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

執行 PR 分支的管線

建立 PR 時,驗證變更是否可能會中斷目標分支上的管線執行,可能會很困難。 不過,透過觸發管線執行或將 PR 分支的組建排入佇列的功能,您現在可以針對目標管線執行變更,以驗證和視覺化進行中的變更。 如需詳細資訊 ,請參閱 az pipelines runaz 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 管線執行檢視中,您現在會看到新的 [相關聯的管線] 索引標籤,您可以在其中找到取用管線和成品的所有管線執行。

顯示 CI 管線中相關聯 CD 管線資訊的螢幕擷取畫面。

支援 YAML 管線中的 GitHub 套件

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

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 刀鋒視窗。 這適用于對應至Azure Kubernetes Service叢集中命名空間的環境。

Kubernetes 環境資源檢視的螢幕擷取畫面,其中已指出 [Azure Kubernetes Service叢集] 連結。

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

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

通知訂閱中發行資料夾篩選的螢幕擷取畫面。

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

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

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

重試失敗階段

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

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

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

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

多階段 YAML 管線中的核准

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

[新增資源] 功能表的螢幕擷取畫面,其中已加上底線的 [檢查] 選項。

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

顯示部署正在等候核准的螢幕擷取畫面。

增加閘道逾時限制和頻率

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

Dockerfile 的新組建映射範本

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

Docker 對話方塊的螢幕擷取畫面。

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

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

顯示 [Azure App 服務設定] 對話方塊的螢幕擷取畫面。

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

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

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

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

顯示 [動作] 下拉式清單中具有新多階段交換設定之 [Azure App 服務管理] 對話方塊的螢幕擷取畫面。

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

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

顯示您可以在預備層級使用正則運算式的螢幕擷取畫面。

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 策略,該策略會循序執行步驟一次。 透過支援多階段管線中的 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: MasterNamespace

從管線收集自動和使用者指定的中繼資料

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

開啟 [從管線發佈中繼資料] 選項的 [一般] 對話方塊螢幕擷取畫面。

具有環境的 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 入口網站設定部署策略

透過這項功能,我們可讓您更輕鬆地設定管線,以使用您選擇的部署策略,例如 滾動CanaryBlue-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 簽出。 現在,除了用來儲存 YAML 管線的存放庫之外,您還可以擷取並取出其他存放庫。

例如,如果您有名為 MyCode 的存放庫,其中包含 YAML 管線,而第二個存放庫稱為 [工具],您的 YAML 管線看起來會像這樣:

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

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

第三個步驟會顯示來原始目錄中的兩個目錄 MyCodeTools

Azure Repos支援 Git、GitHub 和 Bitbucket 雲端存放庫。 如需詳細資訊,請參閱 多存放庫簽出

取得執行時間有關多個存放庫的詳細資料

當管線執行時,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 集合,並具有可存取另一個專案中存放庫的認證。 存放庫 selfotherrepo 都會簽出。

重要事項

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

[專案設定] 頁面的螢幕擷取畫面,其中已醒目提示 [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 叢集的互動式登入提示和失敗管線。 為了解決此問題,我們新增了一個核取方塊,可讓您使用叢集管理員認證,而不是叢集使用者認證。

[套件及部署 Helm] 圖表的螢幕擷取畫面,其中顯示 [使用叢集管理員認證] 核取方塊。

Docker Compose 工作中引數輸入

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

Docker Compose 工作的螢幕擷取畫面,其中顯示新的 [引數] 文字方塊。

GitHub 發行工作增強功能

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

顯示 GitHub 發行工作的螢幕擷取畫面,其中已指出 [工作版本] 和 [標籤模式] 區段。

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

顯示 GitHub 發行工作的螢幕擷取畫面,其中已醒目提示 [比較] 和 [變更記錄類型] 區段。

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

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

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

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

Azure CLI 工作中 PowerShell 腳本的支援

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

Azure CLI 工作的螢幕擷取畫面,其中顯示 Powershell 和 Powershell Core 是 [腳本類型] 下拉式清單中的選項。

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 時觸發您的管線。

    顯示已自動觸發管線的螢幕擷取畫面。

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

    此螢幕擷取畫面顯示 [目前管線] 區段中的認可。

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

  • 可供執行使用的 成品

    顯示管線 [成品] 頁面的螢幕擷取畫面。

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

[部署依據] 區段的螢幕擷取畫面,其中顯示 [Workitems] 索引標籤。

支援大型測試附件

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

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

顯示記錄中傳回 403 錯誤的螢幕擷取畫面。

若要修正此問題,我們建議您將輸出 要求的 防火牆更新為 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 上宣告明確的相依性。

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

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

開啟並呼叫 [代理程式更新設定] 選項的 [預設設定] 頁面的 Sceenshot。

代理程式診斷

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

YAML 管線的服務勾點

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

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

[新增服務勾點訂閱精靈] 的螢幕擷取畫面,其中顯示此類型事件下拉式清單上的 [觸發程式],其中已指出 [執行階段] 選項。

優化整合

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

Azure DevOps 的 Optimizely 擴充功能會將實驗和功能旗標推出步驟新增至組建和發行管線,以便您持續反復執行、推出功能,並使用 Azure Pipelines 來復原。

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

優化

將 GitHub 版本新增為成品來源

現在,您可以將 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 延伸模組,請參閱 這裡的檔。

Terraform 與 Azure Pipelines 整合的螢幕擷取畫面。

與 Google Analytics 整合

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

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

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

顯示 Google Analytics 實驗工作的螢幕擷取畫面。

已更新 ServiceNow 與 Azure Pipelines 的整合

適用于 ServiceNow 的 Azure Pipelines 應用程式有助於整合 Azure Pipelines 和 ServiceNow 變更管理。 透過此更新,您可以與 New York 版本的 ServiceNow 整合。 現在可以使用 OAuth 和基本驗證來建立這兩個服務之間的驗證。 此外,您現在可以設定進階成功準則,以便使用任何變更屬性來決定閘道結果。

從 VSCode 建立 Azure Pipelines

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

VS Code 的螢幕擷取畫面,其中顯示右下角的警示:您的管線已順利設定。

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 語法。

顯示自動測試錯誤訊息中 Markdown 支援的螢幕擷取畫面。

使用管線裝飾專案在部署作業中自動插入步驟

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

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

Test Plans

新增測試計劃頁面

所有 Azure DevOps 集合都可以使用新的 Test Plans Page (Test Plans *) 。 新頁面提供簡化的檢視,可協助您專注于手邊的工作 - 測試規劃、撰寫或執行。 它也與 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 標頭可讓您執行下列工作:

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

操作功能表選項

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

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

3.定義索引標籤

定義索引標籤頁面

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

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

工作

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

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

操作功能表選項

定義索引標籤操作功能表頁面

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

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

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

定義索引標籤複製測試案例頁面

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

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

定義索引標籤檢視連結專案頁面

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

4. 執行索引標籤

執行索引標籤頁面

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

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

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

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

工作

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

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

操作功能表選項

執行索引標籤操作功能表頁面

[執行] 索引標籤中 [測試點] 節點上的操作功能表提供下列選項:

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

Test Plans進度報表

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

[Test Plans] 區段的螢幕擷取畫面,其中已醒目提示 [進度報表] 選項。

報表的三個區段包括下列各項:

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

進度報表的螢幕擷取畫面。

Artifacts

注意

Azure DevOps Server 2020 不會在資料匯入期間匯入回收站中的摘要。 如果您想要匯入回收站中的摘要,請先從回收站還原它們,再開始資料匯入。

授權運算式和內嵌授權

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

Newtonsoft.Json NuGet 套件的螢幕擷取畫面,其中紅色箭號指向套件的授權。

按一下連結會帶您前往網頁,您可以在其中檢視授權的詳細資料。 此體驗適用于授權運算式和內嵌授權,因此您可以在一個位置看到儲存在 Azure Artifacts 中的套件授權詳細資料, (指定授權資訊和 Visual Studio) 支援的套件。

瀏覽器視窗散發 MIT 授權文字的螢幕擷取畫面

輕量型驗證工作

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

輕量型驗證工作的範例螢幕擷取畫面。

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

摘要頁面載入時間的改善

我們很高興宣佈我們已改善摘要頁面載入時間。 平均而言,摘要頁面載入時間已減少 10%。 最大摘要在最高 99% 的所有摘要) 減少 75% 的最大載入時間中, (載入時間,最多發現 99% 的摘要。

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

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

此螢幕擷取畫面顯示您套件的 PublicFeed 頁面。

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

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

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

您現在可以安裝並使用 Python 認證提供者 (成品金鑰) 自動設定驗證,以在 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 達到最多 10 倍的延遲減少。

協助工具增強功能

我們已部署修正,以解決摘要頁面上的協助工具問題。 修正包括下列各項:

  • 建立摘要體驗
  • 全域摘要設定體驗
  • 連線到摘要體驗

Wiki

程式碼 Wiki 頁面的豐富編輯

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

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

顯示 [編輯] 功能表的螢幕擷取畫面,其中已指出 [在 Repos 中編輯] 選項。

從 Wiki 頁面建立和內嵌工作專案

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

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

顯示如何從 Wiki 頁面建立和內嵌工作專案的短片。

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

Wiki 頁面中的批註

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

顯示如何在 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 工具列的螢幕擷取畫面,其中已呼叫 synchronus 捲動圖示,以及其上方的 [停用同步處理捲動] 切換按鈕。

注意

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

Wiki 頁面的頁面流覽

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

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

顯示先前 Wiki 頁面流覽的螢幕擷取畫面。

注意

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

報告

管線失敗和持續時間報告

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

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

顯示 [分析] 索引標籤的螢幕擷取畫面,其中顯示管線通過率徽章、測試通過率徽章和管線持續時間徽章。

顯示管線失敗報告的螢幕擷取畫面。

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

查詢結果小工具的改善

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

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

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

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

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

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

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

顯示 [組態] 對話方塊的螢幕擷取畫面,其中已指出 [泳道] 區段。

我們也包含工作專案篩選準則,以限制出現在圖表中的工作專案。

顯示 [組態] 對話方塊的螢幕擷取畫面,其中已指出 [欄位準則] 區段。

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

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

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

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

螢幕擷取畫面,顯示使用本文點的內嵌短期衝刺待用。

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

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

顯示新 Sprint Burndown 小工具的 Sceenshot。

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

注意

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

內嵌短期衝刺待用縮圖

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

顯示內嵌短期衝刺待用縮圖的螢幕擷取畫面。

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

在沒有小組的情況下建立儀表板

您現在可以建立儀表板,而不需要與小組建立關聯。 建立儀表板時,選取 [專案儀表板 ] 類型。

顯示 [建立儀表板] 對話方塊的螢幕擷取畫面,其中已選取並呼叫 [專案儀表板] 選項。

專案儀表板就像小組儀表板,不同之處在于它與小組無關,您可以決定誰可以編輯/管理儀表板。 就像小組儀表板一樣,專案中的每個人都可以看到它。

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

[小組] 下拉式清單的螢幕擷取畫面。

注意

針對自訂或協力廠商小工具,專案儀表板會將預設小組的內容傳遞給這些小工具。 如果您有依賴小組內容的自訂小工具,您應該更新設定以讓您選取小組。


意見反應

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


頁面頂端