事件
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 2020 引進新的管線執行(組建)保留模型,其運作方式是根據專案層級 設定。
Azure DevOps Server 2020 會根據管線層級保留原則,以不同的方式處理組建保留。 某些政策設定會導致在升級後刪除管線執行。 升級後,不會刪除已手動保留或由版本發佈保留的管線執行。
如需如何安全地從 Azure DevOps Server 2019 升級至 Azure DevOps Server 2020 的詳細資訊,請閱讀我們的 部落格文章。
我們已發行 Azure DevOps Server 2020 Update 0.2 的修補程式,其中包含下列的修正程式。
- 擴充 PowerShell 任務允許的字元清單,以進行 啟用 Shell 任務參數驗證。
注意
若要實作此修補程式的修正程式,您必須遵循許多步驟來手動更新工作。
重要
我們已發行 Azure Pipelines 代理程式的更新,修補程式 4 於 2023 年 9 月 12 日發行。 如果您未如 Patch 4 版本資訊中所述安裝代理程式更新,建議您在安裝 Patch 6 之前安裝這些更新。 安裝 Patch 4 之後的新版本代理程式將會是 3.225.0。
- 請遵循 將工作上傳至專案集合檔 中的步驟,以使用 tfx-cli 安裝及登入。
檔 | SHA-256 哈希 |
---|---|
Tasks20231103.zip | 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5 |
- 下載並擷取 Tasks20231103.zip。
- 將目錄切換至解壓縮檔案所在的資料夾。
- 執行下列命令,上傳工作:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip
若要使用新的行為,必須在使用受影響工作的管線中設定變數 AZP_75787_ENABLE_NEW_LOGIC = true
。
關於經典:
在管線的變數索引標籤中定義變數。
YAML 範例:
variables:
- name: AZP_75787_ENABLE_NEW_LOGIC
value: true
重要
我們已發行 Azure 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 的修補程式,其中包含下列的修正程式。
- CVE-2023-33136:Azure DevOps Server 遠端程式代碼執行弱點。
- CVE-2023-38155:Azure DevOps Server 和 Team Foundation Server 許可權提升弱點。
重要
請將修補程式部署到測試環境,並確定環境的管線在將修正套用至生產環境之前如預期般運作。
注意
若要實作此修補程式的修正程式,您必須遵循許多步驟來手動更新代理程式和工作。
- 下載並安裝 Azure DevOps Server 2020 Update 0.2 patch 4。
- 從下列位置下載代理程式: 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-cli 安裝及登入。
- 下載並擷取 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 的 修補程式,其中包含下列的修正程式。
- 已修正從 2018 或更早版本升級時干擾推送套件的錯誤。
我們已發行 Azure DevOps Server 2020 Update 0.2 的 修補程式,其中包含下列的修正程式。
- 已修正從 2018 或更早版本升級時影響封包推送的錯誤。
我們已發行 Azure DevOps Server 2020 Update 0.2 的 修補程式,其中包含下列的修正程式。
- 解決新增的AD身分識別未出現在安全性對話框身分識別選擇器中的問題。
- 修正 Web 鉤子設置中由群組成員請求的篩選條件的問題。
- 當管道的組織設定中將作業授權範圍設為「限制非發行管道的作業授權範圍僅限於目前專案」時,修正受限簽入構建錯誤。
Azure DevOps Server 2020.0.2 是 Bug 修正的匯總。 您可以直接安裝 Azure DevOps Server 2020.0.2 或從 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更新版本升級。
此版本包含下列專案的修正:
無法使用 [執行下一步] 按鈕略過組建佇列。 先前,僅針對專案集合管理員啟用 [執行下一步] 按鈕。
停用使用者的 Active Directory 帳戶之後,撤銷所有個人存取令牌。
我們已針對 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 的 Patch 8 包括以下修正。
- 自訂工件版面配置狀態的在地化問題。
- 電子郵件通知範本中的當地語系化問題。
- 當數據列中有多個相同的連結時,控制台記錄會遭到截斷的問題。
- 當欄位定義了多個 NOTSAMEAS 規則時,出現 NOTSAMEAS 規則評估的問題。
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號修補程式 包含以下修正。
- 修正成品下載/上傳失敗。
- 解決測試結果數據不一致的問題。
Azure DevOps Server 2020.0.1 的第5號修補程式 包含下列修正。
- 修正組建定義UI錯誤。
- 已變更瀏覽歷程記錄以顯示檔案,而不是根存放庫。
- 修正某些工作專案類型的電子郵件傳遞過程中的問題。
Azure DevOps Server 2020.0.1 的 Patch 4 包含下列修正。
- 修正數據匯入的問題。 對於有許多過時測試案例的客戶而言,數據匯入需要很長的時間。 這是因為引用增加了
tbl_testCaseReferences
表格的大小。 在此修補程式中,我們已移除過時測試案例的參考,以協助加速數據匯入程式。
我們已針對 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,您應該先更新至 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。
注意
下列所有步驟都必須在 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
Copyright Microsoft Corporation
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
- 執行以下命令將任務上傳到伺服器。 使用從步驟 1 擷取 .zip 檔案的路徑。
~$ tfx build tasks upload --task-path *<Path of the extracted package>*
注意
下列所有步驟都必須在 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
Copyright Microsoft Corporation
> 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 發行 修補程式,以修正下列各項。 如需詳細資訊,請參閱 部落格文章。
- 解決開發人員社群意見反應票證 中所報告的問題|「新增測試案例」按鈕無法運作
- 包含在 Azure DevOps Server 2020 Patch 2中發行的修正。
我們已針對 Azure DevOps Server 2020 發行 修補程式,以修正下列各項。 如需詳細資訊,請參閱 部落格文章。
- 解決在開發人員社群意見反應票證 中報告的此問題| [新增測試案例] 按鈕無法運作
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 發行 修補程式,以修正下列各項。 如需詳細資訊,請參閱 部落格文章。
- 測試執行詳細資訊不會顯示使用 OpsHub 移轉所移轉之測試資料的步驟詳細內容。
- Microsoft.TeamFoundation.TestManagement.Server.TCMLogger 的初始化程序異常
- 移轉至 Azure DevOps Server 2020 之後,立即刪除未完成的組建
- 修正數據提供者例外狀況
我們已針對 Azure DevOps Server 2020 發行 修補程式,以修正下列各項。 如需詳細資訊,請參閱 部落格文章。
- CVE-2020-17145:Azure DevOps Server 和 Team Foundation Services 詐騙弱點
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 是 Bug 修正的匯總。 其中包含先前發行的 Azure DevOps Server 2020 RC1 中的所有功能。
我們已重新發行 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 引進許多新功能。 部分重點包括:
- 多階段管線
- 在 YAML 中 持續部署
- 使用面板待辦項目匯總 追蹤父專案的進度
- 在工作面板和短期衝刺待辦事項中新增「父工作項目」篩選
- 適用於 Azure Repos 登陸頁面的新 Web UI
- 跨存放庫分支原則管理
- [新增測試計劃] 頁面
- 程式代碼Wiki頁面的豐富編輯
- 管道故障和時間長度報告
您也可以跳至個別區段,以查看每個服務的新功能:
在 2 月,我們引進了適用於 Azure CLI 的 Azure DevOps 擴充功能。 延伸模組可讓您從命令行與 Azure DevOps 互動。 我們已收集您的意見反應,協助我們改善擴充功能並新增更多命令。 我們很高興地宣布擴充功能已正式推出。
若要深入瞭解 Azure DevOps CLI,請參閱這裡的檔 。
現在您可以使用發佈設定檔驗證,從部署中心將 Windows 版 Azure WebApps 部署。 如果您有使用其發行配置檔部署至適用於 Windows 的 Azure WebApp 的許可權,您可以在部署中心工作流程中使用此設定檔來設定管線。
我們已將新的篩選新增至Sprint看板和Sprint待辦清單。 這可讓您依父項篩選需求階層的待辦事項(最左邊的第一欄)。 例如,在下面的屏幕截圖中,我們已篩選畫面,只顯示父系為「我的大功能」的使用者故事。
在過去,從看板上將工作項目從一個欄移至另一個會觸發狀態變更欄位規則的欄時,卡片只會顯示紅色錯誤訊息,這會強制您開啟工作項目以瞭解根本原因。 在短期衝刺 170 中,我們改善了體驗,因此您現在可以按兩下紅色錯誤訊息來查看錯誤的詳細數據,而不需要開啟工作專案本身。
先前,更新工作專案時,第二個小組成員正在對相同的工作專案進行變更,第二位使用者將會遺失其變更。 現在,只要你們兩個編輯不同的欄位,就會看到對工作專案所做的變更即時更新。
您現在可以使用 az boards iteration
和 az boards area
命令,從命令行管理反覆項目和區域路徑。 例如,您可以從 CLI 以互動方式設定和管理反覆項目和區域路徑,或使用腳本將整個設定自動化。 如需命令和語法的詳細資訊,請參閱這裡的檔案 。
您現在可以選擇在產品待辦清單或衝刺待辦清單中查看每個工作項目的父項。 若要啟用此功能,請前往所需待辦專案的 [欄位選項],然後新增 [父欄位]。
您的工具應該隨著團隊的變化而調整,您現在可以將專案從任何內建的流程範本切換到任何其他內建的流程。 例如,您可以將專案從使用 Agile 變更為 Scrum,或將 Basic 變更為 Agile。 您可以在這裡 找到完整的逐步說明文件。
您現在可以在自訂程式時,從表單設定隱藏自訂欄位。 欄位仍可從查詢和 REST API 取得。 當您與其他系統整合時,這會方便追蹤額外的欄位。
您無法修正無法看到的內容。 因此,您想要密切關注其工作程序的狀態和健康情況。 透過這些報告,我們可讓您更輕鬆地在 Azure Boards 中追蹤重要計量。
這三個新的互動式報告包括:燒毀圖(Burndown)、累計流程圖(Cumulative Flow Diagram, CFD)和 速度。 您可以在新的分析索引標籤中看到報告。
計算指標如短衝進度圖、工作流程和團隊速度等,可提供您對團隊進度的可視性,並協助回答下列問題:
- 在這個短期衝刺中,我們剩下多少工作? 我們正要完成嗎?
- 開發程式哪一個步驟花費的時間最長? 我們能做點什麼嗎?
- 根據先前的迭代,我們應該為下一個衝刺規劃多少工作量?
注意
之前顯示在標題中的圖表已被替換為這些增強的報告。
新的報表是完全互動式的,可讓您調整它們以符合您的需求。 您可以在每個中心的 [分析] 索引標籤中找到新的報告。
您可以在 衝刺 樞紐下找到燒毀圖表。
您可以按兩下相關的卡片,從 [Boards] 底下的 [Analytics] 索引標籤 存取 [] 和 [待辦專案 待辦專案]。
有了新的報表,您就擁有更多小組的控制權和資訊。 以下是一些範例:
- Sprint Burndown 和 Velocity 報表可以設定為使用工作項目計數或剩餘工作的總和。
- 您可以調整衝刺燃盡圖的時間框架,而不會影響專案日期。 因此,如果您的團隊通常會將每次衝刺的第一天用於規劃,您現在可以調整圖表來反映這一點。
- 燃燒圖現在有一個顯示週末的浮水印。
- 「CFD」報表讓您移除像是「設計」這樣的看板欄位,以更專注於小組可以掌控的流程。
以下是顯示過去 30 天「故事待辦專案」流程的CFD報表範例。
速度圖表現在可以追蹤所有待辦專案層級。 例如,您現在可以同時新增功能和史詩,而先前的圖表只支援需求規範。 以下是一份關於功能待辦項目過去 6 次迭代的進度報告範例。
我們很高興宣布,我們新增了一個選項,可讓您自訂任務板上的欄位。 您現在可以新增、移除、重新命名及重新排序數據行。
若在 Taskboard 上設定資料列,請移至 資料列選項。
此功能的優先順序是根據 開發者社群 的建議。
很多時候,在精簡待辦專案時,您只想看到尚未完成的專案。 現在,您可以在待辦項目上顯示或隱藏已完成的子專案。
如果切換為開啟狀態,您會看到所有子項目處於已完成狀態。 切換關閉時,所有處於已完成狀態的子項目都會從待辦項目隱藏。
標記工作專案時,自動完成選項現在會顯示最多五個您最近使用的標籤。 這可讓您更輕鬆地將正確的資訊新增至您的工作專案。
工作項目規則可讓您設定工作專案欄位的特定動作,以自動化其行為。 您可以建立規則,根據群組成員資格將字段設定為唯讀或必要。 例如,您可能想授予產品擁有者設定特性優先順序的權限,同時設定其他人只有讀取權限。
現在,您可以自訂任何系統選單的值(原因欄位除外),例如嚴重性、活動、優先順序等。選單自訂範圍是設定為讓您能夠針對每種工作項目類型管理相同欄位的不同值。
使用新的工作項目 URL 參數,將工作項目的連結與看板或待辦清單的內容分享。 您現在可以在面板、待辦專案或短期衝刺體驗上開啟工作項目對話框,方法是將 參數 ?workitem=[ID]
附加至 URL。
您與 共用連結的任何人,都會以您共用連結時擁有的相同內容登陸!
當我們聆聽您的意見反應時,我們聽說您希望能夠在工作專案描述區域(和其他 HTML 欄位)中提及人員、工作專案和 PR,而不只是在批注中提及。 有時候您需要與某人在工作項目上協作,或者想要在工作項目描述中強調一個 PR,但卻找不到方法來新增該資訊。 現在,您可以在工作專案的所有長文字欄位中提及人員、工作專案和 PR。
您可以在這裡看到範例。
- 若要使用人員提及,請輸入 @ 符號和您想要提及的人員名稱。 工作專案欄位中的 @mentions 會像對評論一樣產生電子郵件通知。
- 若要使用工作專案提及,請輸入 # 符號,後面接著工作專案標識碼或標題。 #mentions 會建立兩個工作專案之間的連結。
- 若要使用PR提及,請新增 ! 後面接著您的PR標識碼或名稱。
我們的主要目標之一是讓工作專案對小組更具共同作業性。 最近,我們在 Twitter 上進行了 民意調查,以瞭解您在工作項目的討論中想要哪些共同作業功能。 在評論中增加反應贏得了民意測驗,所以我們就加入了! 以下是 Twitter 投票的結果。
您可以將回應新增至任何評論,並且有兩種方式可以新增您的回應-在任何評論的右上角點選笑臉圖示,或者在評論底部的現有回應旁新增。 您可以視需要新增所有六個反應,或只新增一或兩個反應。 若要移除您的反應,請單擊評論底部的反應,這樣就會被移除了。 您可以在下方查看如何新增反應,並且瞭解反應在評論中的顯示樣貌。
在短期衝刺 155 更新中,我們已 更新版本的FDA和速度報告。 這些報告可在 [面板] 和 [待辦專案] 的 [分析] 索引標籤下取得。 現在您可以將報表直接釘選到儀錶板。 若要釘選報表,請將滑鼠停留在報表上方,選取省略號 “...” 選單,然後 [複製到儀表板]。
匯總欄位顯示階層內數值欄位或子項目的進度列和/或總計。 子系項目對應於層次結構中的所有子項目。 您可以將一或多個匯總欄新增至產品或組合待辦清單。
例如,我們在這裡顯示 [按工作項目顯示進度],它根據已關閉的子代項目的百分比顯示父代工作項目的進度條。 Epics 的子代專案包括所有子功能及其子工作專案或子系工作專案。 Features 的子系專案包含所有子用戶劇本及其子工作專案。
您的工作面板現在會在發生變更時自動重新整理! 當其他小組成員移動或重新排列工作面板上的卡片時,您的面板會自動更新這些變更。 您不再需要按 F5 來查看最新的變更。
匯總現在可以在任何欄位上完成,包括自定義欄位。 新增彙總欄時,您仍然可以從快速清單中挑選彙總欄,不過,如果您想要彙總不在預設流程範本中的數字欄位,您可以按如下方式設定您自己的欄位:
- 在您的待辦專案上,按兩下 [資料行選項]。 然後在面板中按下[新增匯總資料行],設定自訂匯總。
- 在 進度列 和 總計之間進行挑選。
- 選取工作專案類型或待辦專案層級(通常是待辦專案匯總數個工作專案類型)。
- 選取匯總類型。 工作項目計數 或 總和。 針對 [總和],您必須選取要摘要的欄位。
- [確定] 按鈕會將您帶回數據行選項面板,您可以在其中重新排序新的自定義數據行。
請注意,按兩下 [確定] 之後,您無法編輯自訂資料行。 如果您需要進行變更,請移除自定義數據行,並視需要新增另一個數據行。
我們已將新規則新增至繼承的規則引擎,讓您隱藏工作項目表單中的字段。 此規則會根據使用者群組成員資格隱藏欄位。 例如,如果使用者屬於「產品擁有者」群組,則您可以隱藏開發人員特定字段。 如需詳細資訊,請參閱這裡的檔案 ,。
掌握與您或小組相關的工作專案的最新狀態非常重要。 它可協助小組共同作業並持續追蹤專案,並確保所有相關方都參與其中。 不過,不同的項目關係人在不同的工作中有不同的投資水平,我們相信應該反映在您追蹤工作項目狀態的能力中。
先前,如果您想要追蹤工作專案並取得任何變更的通知,您會收到任何和對工作專案所做的所有變更的電子郵件通知。 考慮您的意見反應之後,我們將使所有相關人員更靈活地跟進工作項目。 現在,您會看到工作項目右上角 [遵循] 按鈕旁的一個新的設定按鈕。 這會帶您前往彈出視窗,讓您設定下列選項。
從 [通知設定]中,您可以選擇三個通知選項。 首先,您可以完全取消訂閱。 其次,您可以完全訂閱,以接收所有工作項目變更的通知。 最後,您可以選擇取得一些最上層和重要工作專案變更事件的通知。 您可以只選取一個選項,或全部三個選項。 這可讓小組成員遵循較高層級的工作專案,而不會因為每次所做的變更而分心。 透過這項功能,我們將消除不必要的電子郵件,並讓您專注於手邊的重要工作。
我們很高興在工作項目窗口上推出部署控制功能。 此控制項會將工作專案連結至發行,並可讓您輕鬆地追蹤工作專案已部署的位置。 若要深入瞭解,請參閱這裡的檔 。
到目前為止,從 CSV 檔案匯入工作專案相依於使用 Excel 外掛程式。 在此更新中,我們會直接從 Azure Boards 提供第一級匯入體驗,以便匯入新的或更新現有的工作專案。 若要深入瞭解,請參閱這裡的檔 。
現在,您的工作流程看板內已提供父內容,做為工作專案卡片的新字段。 您現在可以將父字段新增至卡片,而不需要使用標籤和前置詞等因應措施。
檢視待辦項目和查詢結果時,現在可以使用父欄位。 若要新增父欄位,請使用 [資料行] 選項 檢視。
您現在可以在拉取請求 (PR) 檢視中查看變更的程式碼覆蓋率指標。 這可確保您已透過自動化測試充分測試變更。 涵蓋範圍狀態會顯示為 PR 概觀中的批註。 您可以在檔案差異檢視中檢視每個已變更程式碼行的涵蓋範圍資訊詳細內容。
此外,存放庫擁有者現在可以設定程式代碼涵蓋範圍原則,並防止大型未經測試的變更合併至分支。 所需的涵蓋範圍閾值可以在存放庫根目錄簽入的 azurepipelines-coverage.yml
配置檔中定義,而且可以使用 Azure Repos 中現有的 設定其他服務分支原則的功能 來定義覆蓋率政策。
提取要求中的批注通常會因為通知而產生大量雜訊。 我們新增了自定義訂用帳戶,可讓您依批注年齡、批注器、已刪除的批註、提及的使用者、提取要求作者、目標分支和線程參與者來篩選您訂閱的批註通知。 您可以按下右上角的使用者圖示並瀏覽至 [使用者設定]來建立這些通知訂閱。
您現在可以根據存放庫和目標分支,在提取要求中建立批注的服務勾點。
系統管理員現在可以設定原則,以防止提交依據檔案類型和路徑被推送至倉儲庫。 檔名驗證原則會封鎖符合所提供模式的推送。
您現在可以使用像 修正、修復或 修正這樣的關鍵詞,透過提交到預設分支來解決工作項目。 例如,您可以在提交訊息中撰寫「此變更已修正 #476」,當提交被推送或合併至預設分支時,工作專案 #476 將會完成。 如需詳細資訊,請參閱這裡的檔案 ,。
先前,將群組層級的檢閱者新增至拉取請求時,只需要來自該群組的單一批准。 現在,您可以在新增自動檢閱者時,設定需要小組中的多個檢閱者核准提取要求的原則。 此外,您可以新增原則,以防止要求者核准自己的變更。
先前,從 AKS 部署中心設定 Azure Pipelines 時,我們使用 Azure Resource Manager 連線。 此連線可存取整個叢集,而不只是設定管線的命名空間。 透過此更新,我們的管線會使用服務帳戶型驗證來連線到叢集,使其只能存取與管線相關聯的命名空間。
您現在可以使用新的 Preview 按鈕來查看 Markdown 檔案的外觀預覽。 此外,您可以從並排差異中查看檔案的完整內容,只需選取 [檢視] 按鈕。
政策會強制執行團隊的程式碼品質和變更管理標準。 先前,您可以設定自動化組建的組建到期原則。 現在,您也可以為手動構建設置組建過期政策。
系統管理員現在可以設定推送策略,以防止當提交作者的電子郵件不符合指定模式時,提交被推送到存放庫。
此功能的優先順序是根據開發人員社群 建議來提供類似的體驗。 我們將繼續開放問題單,並鼓勵使用者告訴我們您想要查看的其他推送策略類型。
有時候,您需要檢閱包含大量檔案變更的提取要求,而且很難追蹤您已檢閱的檔案。 現在您可以在提取要求中將檔案標示為已檢閱。
您可以使用檔名旁的下拉功能表,或暫留並按下檔名,將檔案標示為已檢閱。
注意
這項功能只會在您檢閱提取要求時追蹤進度。 它並不代表對提取要求進行投票,因此檢閱者只會看到這些標記。
此功能的優先順序是根據 開發人員社群的建議。
您現在可以試用 Azure Repos 內新的新式、快速和行動裝置型登陸頁面。 這些頁面 新的 Repos 登陸頁面。 著陸頁面包括除了拉取請求詳細資訊、提交詳細資訊和分支比較之外的所有頁面。
網路
行動裝置
分支原則是 Azure Repos 的其中一個強大功能,可協助您保護重要的分支。 雖然在專案層級設定原則的能力存在於 REST API 中,但它沒有使用者介面。 現在,系統管理員可以在其專案中的所有存放庫上,在特定分支或預設分支上設定原則。 例如,系統管理員可以要求在其專案中每個存放庫的每個主要分支所提出的所有拉取請求至少有兩名檢閱者。 您可以在 Repos 專案設定中找到 新增分支保護 功能。
我們已更新 Repos 登陸頁面用戶體驗,使其現代化、快速且方便行動。 以下是兩個已更新的頁面範例,我們會在未來的更新中繼續更新其他頁面。
Web 體驗:
行動體驗:
我們很高興宣布,我們現在支援檔案編輯器中的 Kotlin 語言醒目提示。 醒目提示可改善 Kotlin 文字檔的可讀性,並協助您快速掃描以找出錯誤。 我們會根據開發人員社群 的建議,設定此功能的優先順序。
為了減少因提取請求而產生的電子郵件通知數量,您現在可以針對處於 草稿狀態的提取請求,建立自訂通知訂閱。 您可以選擇接收關於草稿拉取請求的電子郵件,或過濾掉來自草稿拉取請求的電子郵件,這樣您的小組就不會在拉取請求準備好接受檢閱之前收到通知。
當您有許多提取要求要檢閱時,瞭解您應該先採取動作的位置可能會很困難。 若要改善提取要求可採取動作性,您現在可以在提取要求清單頁面上建立多個自定義查詢,其中包含數個新選項來篩選,例如草稿狀態。 除了「由我建立」和「指派給我」之外,這些查詢還會在您的提取要求頁面上建立個別且可折疊的區段。 您也可以拒絕檢閱透過 [投票] 選單或在拉取請求清單頁面上的內容選單中將您新增至的拉取請求。 在自定義區段中,您現在會看到已提供檢閱或拒絕檢閱之提取要求的個別索引標籤。 這些自定義查詢會在集合首頁的「我的提取要求」標籤上跨存放庫運作。 如果您想返回某個拉取請求,可以將其加上標記,這樣它們會顯示在清單頂端。 最後,已設定為自動完成的拉取請求將會在清單中以「自動完成」標籤標示。
我們一直在努力開發 新的用戶體驗, 以便管理您的管線。 這些更新可讓管線體驗現代化且與 Azure DevOps 的方向一致。 此外,這些更新會將傳統組建管線和多階段 YAML 管線整合成單一體驗。 它適用於行動裝置,併為您管理管線的方式帶來各種改善。 您可以深入分析並檢視管線詳細資訊、執行詳細資訊、管線分析、作業詳細資訊、日誌等等。
新的體驗包含下列功能:
- 檢視和管理多個階段
- 核准作業流程運行
- 在管線仍在進行中時,一路捲動回記錄
- 管線的每個分支健康情況。
我們很高興提供 Azure Pipelines YAML CD 功能。 我們現在提供統一的 YAML 體驗,您可以將每個管線設定為執行 CI 或 CD,或同時執行 CI 和 CD。 YAML CD 功能引進數個新的進階功能,可供所有使用多階段 YAML 管線的集合使用。 部分重點包括:
- 多階段 YAML 管線 (適用於 CI 和 CD)
- 核准和檢查資源
- 環境 和 部署策略
- Kubernetes 和 虛擬機 環境中的資源
- 檢閱共同作業 的應用程式
- 重新整理服務連線的UX
- YAML 管線中的 資源
如果您已準備好開始建置,請參閱建置多階段 CI/CD 管線的 檔 或 部落格。
我們已更新在 YAML 編輯器中管理管線變數的體驗。 您不再需要移至傳統編輯器,即可在 YAML 管線中新增或更新變數。
處理待核准的事項變得更容易。 之前,您可以從發行詳情頁面核准發行。 您現在可以直接從發行中樞核准發行。
使用入門向導的一個常見需求是能夠重新命名生成的文件。 目前,它會以存放庫根目錄的 azure-pipelines.yml
的形式簽入。 您現在可以在儲存管線之前,將此更改為不同的檔名或位置。
最後,當您將 azure-pipelines.yml
檔案簽入至不同的分支時,您將會有更多控制權,因為您可以選擇略過從該分支建立拉取請求。
我們已新增 預覽,但未針對 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。
以前,您可以使用 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 排程的錯誤。
我們一直在優化更新的使用者體驗,以便更好地管理您的服務連線。 這些更新可讓服務連線體驗現代化且與 Azure DevOps 的方向一致。 我們今年早些時候引進了服務連線的新UI作為預覽功能。 感謝所有嘗試新體驗並給我們提供寶貴意見反應的人。
除了用戶體驗重新整理之外,我們也新增了兩項功能,對於取用 YAML 管線中的服務連線至關重要:管線授權以及核准及檢查。
更新後,新的用戶體驗將會預設開啟 。 您仍然可以選擇退出預覽。
注意
我們計劃將 跨專案共用服務連線 作為新功能。 您可以在這裡 找到有關共享體驗和安全性角色的詳細資訊。
當您開始手動執行時,有時可能會想要略過管線中的幾個階段。 例如,如果您不想將系統部署到生產環境,或想要略過生產環境中的某些部署。 您現在可以使用 YAML 管線來執行此動作。
更新的執行管線面板會顯示 YAML 檔案中的階段清單,而且您可以選擇略過其中一或多個階段。 略過階段時,您必須謹慎行事。 例如,如果您的第一個階段會產生後續階段所需的特定成品,則不應該略過第一個階段。 每當您略過具有下游相依性的階段時,執行面板就會顯示泛型警告。 是否將這些相依性視為真正的成果相依性,或僅僅是為了部署的排序而存在,由您決定。
略過階段相當於重新建立階段之間的相依性。 任何略過階段的直接下游相依性,都會根據略過階段的上游父系而定。 如果執行失敗,並且您嘗試重新執行一個失敗的階段,該嘗試也會顯示相同的略過行為。 若要變更略過哪些階段,您必須開始新的流程。
有新的服務連線 UI。 這個新的UI是以新式設計標準為基礎,其隨附各種重要功能,可支援多階段YAML CD管線,例如核准、授權和跨項目共用。
在此瞭解有關服務連線 的更多信息。
我們已新增在 [建立執行] 對話框中手動挑選管線資源版本的功能。 如果您使用 管線做為另一個管線中的資源,您現在可以在建立執行時挑選該管線的版本。
將 YAML 型管線從一個專案移植到另一個專案可能會很有挑戰性,因為需要手動設定管線變數和變數群組。 不過,透過管線 變數群組 和 變數 管理命令,您現在可以編寫管線變數和變數群組的設定和管理腳本,進而控制版本,讓您輕鬆地共用指示,將管線從某個專案移至另一個專案。
建立拉取請求 (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'
如需部署作業和指定部署作業的完整語法詳細資訊,請參閱部署作業 。
我們已新增 CD YAML 管線詳細數據的支援,其中 CI 管線稱為管線資源。 在您的 CI 管線執行視圖中,您現在會看到一個新的 [相關管線] 標籤,您可以在其中找到所有取用您的管線及其建置成果的管線執行。
我們最近引進了一種名為 套件的新資源類型, 這類資源類型新增支援從 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 刀鋒視窗。 這適用於映射到 Azure Kubernetes Service 叢集命名空間的環境。
資料夾允許組織管線,以便更容易探索和安全性控制。 您通常想要設定所有發行管線的自定義電子郵件通知,這些通知是由資料夾下的所有管線所代表。 先前,您必須設定多個訂用帳戶,或在訂用帳戶中具有複雜的查詢,以取得專注的電子郵件。 透過此更新,您現在可以將發行資料夾條件新增至 已完成的部署 以及 核准擱置的事件,並簡化訂閱。
目前,您可以自動連結工作專案與傳統組建。 然而,這對於 YAML 管線來說是不可能的。 透過此更新,我們已解決此差距。 當您使用指定分支的程式代碼成功執行管線時,Azure Pipelines 會自動將該執行與所有工作項目產生關聯(透過該程式碼中的提交推斷)。 當您開啟工作專案時,您將可以看到建立該工作專案的程式代碼執行。 若要進行此設定,請使用管線的設定面板。
執行多階段 YAML 管線時,您現在可以在某個階段進行中時取消該階段。 如果您知道階段將會失敗,或者您有另一個想要啟動的運行,那麼這會很有説明。
多階段管線中最要求的功能之一,就是能夠重試失敗的階段,而不需要從頭開始。 透過此更新,我們會新增大部分的功能。
您現在可以在執行失敗時重試管道階段。 在第一次嘗試中失敗的任何作業,以及那些間接依賴於這些失敗作業的作業,都會重新嘗試。
這可協助您以數種方式節省時間。 例如,當您在階段中執行多個作業時,您可能會希望每個階段在不同的平臺上執行測試。 如果某個平臺上的測試在其他人通過時失敗,您可以藉由不重新執行通過的作業來節省時間。 另一個範例是,部署階段可能因為網路連線不穩定而失敗。 重新嘗試該階段可以幫助您節省時間,因為不需要再產生另一個建置。
這項功能有一些已知的差距。 例如,您無法重試明確取消的階段。 我們正在努力在未來更新中縮小這些差距。
您的 YAML CD 管道可能包含手動核准。 基礎設施擁有者可以在任何管線的部署階段之前,保護其環境並尋求手動核准。 透過基礎結構(環境)和應用程式(管線)擁有者之間角色的完整隔離,您將確保在特定管線中的部署獲得手動批准,並取得集中權限,以將相同的檢查套用至所有環境中的部署。
部署至開發環境的管線會在階段的開始時暫停以待核准。
先前,發行流程中的閘道逾時限制是三天。 透過此更新,逾時限制已增加到 15 天, 允許持續時間較長的閘道。 我們也將閘口的頻率提高到 30 分鐘。
先前,在新管線建立中建立 Dockerfile 的新管線時,範本建議將映像推送至 Azure Container Registry 並部署至 Azure Kubernetes Service。 我們新增了範本,可讓您使用代理程式建置映像,而不需要推送至容器登錄。
Azure App Service 允許透過各種 設定,例如應用程式設定、連接字串和其他一般組態設定。 我們現在有新的 Azure Pipelines 工作 Azure App Service 設定,支援在 Web 應用程式或其任何部署插槽上使用 JSON 語法批量配置這些設定。 此工作可以與其他 App Service 工作搭配使用,以 部署、管理 及設定 Web 應用程式、函式應用程式或任何其他容器化 App Services。
Azure App Service 現在支援 Swap,並在其部署插槽上使用預覽。 這是在應用程式實際從預備位置交換至生產位置之前,使用生產設定來驗證應用程式的好方法。 這也可確保目標/生產時段不會發生中斷。
Azure App Service 工作現在可透過下列新動作支援此多階段交換:
- 開啟具有預覽的交換 - 啟動具有預覽功能的交換(多階段的交換),並將目標槽位(例如生產槽位)的配置套用到來源槽位。
- 完成預覽交換 - 當您準備好完成擱置交換時,請選取 [使用預覽完成交換] 動作。
- 取消預覽交換 - 若要取消擱置交換,請選取 [取消與預覽交換]。
先前,Azure Container Registry 和 Docker Hub 成品的正則表達式篩選僅適用於發行管線層級。 它們現在也已被新增在階段層級上。
我們已啟用核准設定功能,適用於服務連線和代理程式集區。 如需核准,我們會遵循基礎結構擁有者和開發人員之間角色的隔離。 藉由在您的資源上設定核准,例如環境、服務連線和代理程式集區,您就能確保所有使用資源的管線執行都需要先核准。
此體驗類似於設定環境的核准。 當流程階段所引用的資源待核准時,管線的執行會暫停,直到手動核准管線為止。
應用程式中的容器使用量正在增加,因此需要強固測試和驗證。 Azure Pipelines 現在支援 容器結構測試。 此架構提供方便且功能強大的方法來驗證容器的內容和結構。
您可以根據可以一起執行的四種測試類別來驗證影像的結構:命令測試、檔案存在測試、檔案內容測試和元數據測試。 您可以使用管線中的結果來做出是否進行的決策。 測試數據可在管道執行中取得,並提供錯誤訊息,以協助您更好地排除故障。
輸入組態檔和映像詳細數據
測試數據和摘要
管道裝飾器允許將步驟新增至每個作業的開頭和結尾。 這與將步驟新增至單一定義不同,因為它會套用至集合中的所有管線。
我們一直在為建置和 YAML 管道提供裝飾器的支持,客戶使用它們集中控制其作業中的步驟。 我們現在也把支援延伸至發佈流程。 您可以建立擴充功能,以新增針對新貢獻點的步驟,而且這些步驟將會新增至發行管線中的所有代理工作。
先前,我們僅支援部署至資源群組層級。 透過此更新,我們新增了將ARM範本部署至訂用帳戶和管理群組層級的支援。 這可協助您在一起部署一組資源,但將它們放在不同的資源群組或訂用帳戶中。 例如,將 Azure Site Recovery 的備份虛擬機部署到個別的資源群組和位置。
您現在可以取用 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
如需詳細資訊,請參閱下載構建產物文件 這裡。
持續傳遞應用程式更新的主要優點之一,就是能夠快速將更新推送至生產環境,以取得特定微服務。 這可讓您快速響應商務需求變更。 環境 作為重要的概念被引入,讓部署策略的協調執行成為可能,並促進零停機發行。 先前,我們支援 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...
on:
failure:
steps:
- script: echo clean-up, rollback...
success:
steps:
- script: echo checks passed, notify...
Kubernetes 的 Canary 策略會先以 10 個% Pod 部署更改,隨後以 20 個% 部署,同時在 期間監控 postRouteTraffic的健康狀況。 如果一切順利,將升級到 100%。
我們正在尋求對於在各種環境中支援 VM 資源以及跨多部機器執行滾動部署策略的早期意見反饋。 請與我們聯絡來報名。
在 YAML 管線中,我們會遵循資源擁有者控制的核准設定。 資源擁有者會在資源上設定核准,並且所有使用該資源的管線在開始執行該資源消耗階段之前會暫停以等待核准。 SOX 型應用程式擁有者通常會限制部署的要求者核准自己的部署。
您現在可以使用 進階核准選項 來設定核准原則,例如要求者不應核准、需要使用者子集的核准,以及核准逾時。
如果您需要使用發佈至 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 管線中使用未經授權的資源時,失敗並出現資源授權錯誤。 您必須從失敗的執行摘要頁面批准資源。 此外,如果管線使用引用未經授權資源的變數,管線就會失敗。
我們現在可讓您更輕鬆地管理資源授權。 執行不會失敗,相反地,它會在使用資源的階段開始時等待資源的使用權限。 資源擁有者可以從 [安全性] 頁面檢視管線並授權資源。
您現在可以定義一組原則,並將原則評估新增為容器映像成品環境的檢查。 當流程運行時,在啟動使用環境的階段之前會暫停執行。 指定的政策將根據被部署的映像的可用元數據進行評估。 檢查會在原則成功時通過,並在檢查失敗時將階段標示為失敗。
先前,我們並未篩選 ARM 範本部署工作中的服務連線。 如果您要選取較低的範圍服務連線,以執行ARM範本部署至更廣泛的範圍,這可能會導致部署失敗。 現在,我們新增了服務連線的篩選,可根據您選擇的部署範圍篩選出較低範圍的服務連線。
ReviewApp 會將 Git 存放庫的每個提取要求部署到動態環境資源。 檢閱者可以在合併至主要分支並部署至生產環境之前,查看這些變更的外觀與其他相依服務的運作方式。 這將讓您能夠輕鬆地建立和管理 ReviewApp 資源,並享有環境功能提供的所有追蹤及診斷能力的優勢。 藉由使用 reviewApp 關鍵詞,您可以建立資源的複製品(根據環境中的現有資源動態建立新資源),並將新資源新增至環境。
以下是在環境中使用 reviewApp 的範例 YAML 代碼段。
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MainNamespace
現在,您可以在管線任務中啟用自動和使用者指定的元數據收集。 您可以使用元數據透過 評估工件檢查,在環境上強制執行工件政策。
環境中最要求的功能之一是 VM 部署。 透過此更新,我們會在環境中啟用虛擬機資源。 您現在可以跨多部機器協調部署,並使用 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 範本
當您將核准新增至環境或服務連線時,所有使用資源的多階段管線都會在階段開始時自動等候核准。 指定的核准者必須先完成核准,才能繼續流程。
透過此更新,核准者會收到待核准的電子郵件通知。 使用者和小組擁有者可以使用 通知設定來取消訂閱或設定自訂通知。
有了這項功能,我們可讓您更輕鬆地設定管線,以使用您選擇的部署策略,例如,滾動、Canary或 Blue-Green。 您可以使用這些現成的策略,以安全的方式推出更新,並降低相關聯的部署風險。 若要存取此功能,請按兩下 Azure 虛擬機中的 [持續傳遞] 設定。 在組態窗格中,系統會提示您選取將建立管線之 Azure DevOps 專案的詳細數據、部署群組、發佈要部署之套件的建置管線,以及您選擇的部署策略。 繼續設定將所選套件部署至此虛擬機的完整功能管線。
如需詳細資訊,請參閱 設定部署策略的文件。
運行時間參數可讓您更充分掌控哪些值可以傳遞至管線。 不同於變數,運行時間參數具有數據類型,而且不會自動成為環境變數。 使用執行時間參數,您可以:
- 在運行時間為腳本和工作提供不同的值
- 控制參數類型、允許的範圍和預設值
- 使用範本表示式動態選取作業和階段
目前,流程可以分解成範本,以促進重複使用並減少樣板代碼。 管線的整體結構仍由根 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 集合時,預設會開啟此設定。
變數可讓您輕鬆地將關鍵資料導入到工作流程的各個環節。 透過此更新,我們已將一些預先定義的變數新增至部署作業。 系統會自動設定這些變數,範圍限定於特定的部署作業,而且是唯讀的。
- 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"
先前,當您在 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(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 工作使用叢集使用者認證進行部署。 這會導致已啟用 Azure Active Directory 型 RBAC 叢集的互動式登入提示和失敗的管線。 為了解決此問題,我們新增了一個複選框,可讓您使用叢集管理員認證,而不是叢集用戶認證。
Docker Compose 工作中已引進新的欄位,可讓您新增自變數,例如 --no-cache
。 像執行組建這類命令時,工作會傳遞參數。
我們已對 GitHub 發行工作進行數個增強功能。 您現在可以藉由指定標籤正則表達式來更好地控制發行建立,並且只有在觸發的提交被加上相符的字串標籤時,才會建立發行。
我們也已新增功能,以自定義變更記錄的建立和格式設定。 在變更記錄設置的新區段中,您現在可以指定一個版本,將目前的版本與其進行比較。 相較於 版本可以是最後一個完整版本(不包括預發布版本)、最後一個非草稿版本或任何符合您提供的發行標籤的舊版。 此外,此任務提供變更記錄類型欄位,用於格式化變更記錄。 根據選取專案,變更記錄會顯示認可清單或根據標籤分類的問題/PR 清單。
開放原則代理程式是開放原始碼、一般用途的原則引擎,可強制執行統一的內容感知原則。 我們已新增 [開放性政策代理] 安裝任務。 對於基礎設施即代碼提供者來說,在管道中強制執行策略特別有用。
例如,開放式原則代理程式可以評估管線中 Rego 原則檔案和 Terraform 計劃。
task: OpenPolicyAgentInstaller@0
inputs:
opaVersion: '0.13.5'
先前,您可以在 Azure CLI 工作中執行批次和 bash 腳本。 透過此更新,我們已將PowerShell和PowerShell核心腳本的支援新增至工作。
先前,當在 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 檔案複製工作可以在組建或發行管線中使用,將檔案複製到 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 容器資源時,我們可確保完整的 E2E 可追蹤性。 針對 YAML 管線所耗用的每個資源,您可以回溯至提交、工作項目和標的物。
在管線執行摘要檢視中,您可以看到:
觸發 執行的資源版本。 現在,您的管線可以在另一個 Azure 管線執行完成後或將容器映像檔推送至 ACR 時觸發。
提交由管線取用的。 您也可以找到由管線消耗的每個資源的提交記錄明細。
與每個管線耗用資源相關聯的 工作項目。
工件 可在執行時使用。
在環境的部署檢視中,您可以看到部署到環境之每個資源的提交和工作項目。
Azure Pipelines 中的發佈測試結果工作可讓您在執行測試時發佈測試結果,以提供完整的測試報告和分析體驗。 到目前為止,無論是測試執行還是測試結果,其測試附件的限制都是100MB。 這會限制上傳大型檔案,例如當機傾印或影片。 透過此更新,我們新增了大型測試附件的支援,讓您擁有所有可用的數據來針對失敗的測試進行疑難解答。
您可能會在記錄中看到 VSTest 工作或發佈測試結果工作傳回 403 或 407 錯誤。 如果您使用防火牆後方的自我裝載組建或發行代理程式來篩選輸出要求,您必須進行一些設定變更,才能使用這項功能。
若要修正此問題,建議您將 輸出要求的防火牆更新為https://*.vstmrblob.vsassets.io
。 您可以在這裡的檔案 中找到疑難解答資訊,。
注意
只有在您使用自我裝載的 Azure Pipelines 代理程式,且您位於篩選輸出流量的防火牆後方時,才需要這樣做。 如果您在雲端中使用Microsoft裝載的代理程式,或未篩選輸出網路流量,則不需要採取任何動作。
先前,當您使用矩陣來展開工作或變數來識別集區時,我們有時會在記錄頁上解析到不正確的集區資訊。 這些問題已經解決。
一個長期以來的要求,就是在建立新分支且該分支沒有變更時,不要觸發 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 管線的服務掛鉤事件,您現在可以根據管線執行的進度,驅動自訂應用程式或服務中的活動。 例如,您可以在需要核准時建立技術服務台票證、在階段完成後起始監視工作流程,或在階段失敗時將推播通知傳送至小組的行動裝置。
所有事件都支援篩選管線名稱和階段名稱。 核准事件也可以針對特定環境進行篩選。 同樣地,狀態變更事件可以依管線執行或階段的新狀態進行篩選。
Optimizely 是產品小組的強大 A/B 測試和功能標幟平臺。 Azure Pipelines 與 Optimizely 測試平臺整合可讓產品小組以加速的速度進行測試、學習和部署,同時從 Azure Pipelines 獲得所有 DevOps 優點。
適用於 Azure DevOps 的 Optimizely 擴充功能會將實驗和功能旗標推出步驟新增至組建和發行管線,讓您可以持續反覆運算、推出功能,以及使用 Azure Pipelines 加以復原。
在這裡深入瞭解 Azure DevOps Optimizely 擴充功能 ,。
現在,您可以將 GitHub 版本連結為 Azure DevOps 發行管線中的工件來源。 這可讓您在部署中取用 GitHub 版本。
當您在發行管線定義中按一下 新增工件,您會發現新的 GitHub Release 來源類型。 您可以提供服務連線和 GitHub 存放庫,以取用 GitHub 版本。 您也可以選擇 GitHub 版本的預設版本,以取用為最新的特定標籤版本,或在發行建立期間選取 。 連結 GitHub 版本之後,即會自動下載並可在您的發行作業中使用。
Terraform 是一種開放原始碼工具,可安全地且有效率地開發、變更和版本控制基礎結構。 Terraform 會將 API 編纂成宣告式組態檔,讓您能夠使用高階組態語言來定義和布建基礎結構。 您可以使用 Terraform 擴充功能,跨所有主要基礎結構提供者建立資源:Azure、Amazon Web Services (AWS) 和 Google Cloud Platform (GCP)。
若要深入瞭解 Terraform 擴充功能,請參閱這裡的檔 。
Google Analytics 實驗架構可讓您測試網站或應用程式幾乎任何變更或變化,以測量其對特定目標的影響。 例如,您可能有您想要使用者完成的活動(例如購買、註冊電子報)和/或您想要改善的計量(例如營收、會話持續時間、反彈率)。 這些活動可讓您根據對功能效能的直接影響,找出值得實作的變更。
適用於 Azure DevOps 的 Google Analytics 實驗延伸模組將實驗過程加入到組建和發行管線中,使您能夠持續進行迭代、學習和部署。透過持續管理實驗,您可以在享有 Azure Pipelines 所提供的所有 DevOps 優勢的同時,加速開發速度。
您可以從 Marketplace 下載 Google Analytics 實驗延伸模組。
適用於 ServiceNow 的 azure Pipelines 應用程式 可協助整合 Azure Pipelines 和 ServiceNow 變更管理。 透過此更新,您可以與紐約版本的 ServiceNow 整合。 現在可以使用 OAuth 和基本身份驗證來建立這兩個服務之間的驗證。 此外,您現在可以設定進階成功準則,從而可根據任何變更屬性來決定閘道結果。
我們已將新功能新增至適用於 VSCode 的 Azure Pipelines 擴充功能。 現在,您將能夠直接從 VSCode 建立 Azure Pipelines,而不需要離開 IDE。
我們引入了不穩定測試管理,以支持從偵測、報告到解決的端對端生命週期。 為了進一步增強功能,我們正在新增不穩定測試錯誤的管理和解決方法。
在調查不穩定測試時,您可以使用 Bug 操作來建立 Bug,然後指派給開發人員,以進一步調查不穩定測試的根本原因。 Bug 報告包含管線的相關信息,例如錯誤訊息、堆疊追蹤和其他與測試相關聯的資訊。
當錯誤報告解決或關閉時,我們會自動將測試解除標記為不不穩定的。
VSTest 工作會使用使用者輸入來探索和執行測試(測試檔案、篩選準則等等),以及所使用之測試架構特有的測試配接器。 使用者輸入或測試配接器的變更可能會導致測試未被找到的情況,並且僅執行部分預期的測試。 這可能會導致管線運行成功的情況,因為測試被略過,而不是因為程式碼質量足夠高。 為了協助避免這種情況,我們在 VSTest 工作中新增了一個新選項,可讓您指定必須執行的測試數目下限,才能讓工作通過。
VSTest 工作會將測試結果和相關聯的檔案儲存在 $(Agent.TempDirectory)\TestResults
資料夾中。 我們已將選項新增至工作 UI,讓您設定不同的資料夾來儲存測試結果。 現在,任何需要特定位置檔案的後續工作都可以使用這些檔案。
我們已在自動化測試的錯誤訊息中新增了對 Markdown 的支援。 現在,您可以輕鬆地將測試回合和測試結果的錯誤訊息格式化,以改善可讀性,並簡化 Azure Pipelines 中的測試失敗疑難解答體驗。 您可以在這裏 找到支援的 Markdown 語法。
您現在可以將 管線裝飾專案新增至部署作業。 您可以將任何自定義步驟(例如弱點掃描器)自動插入每個 生命周期攔截, 執行每個部署作業。 由於管線裝飾器可以套用到某集合中的所有管線,因此這可用來作為強制執行安全部署實務的一部分。
此外,如果已定義,部署作業可以當作 容器作業 以及 服務側車 來執行。
新的測試計劃頁面 (Test Plans *) 可供所有 Azure DevOps 集合使用。 新頁面提供簡化的檢視,可協助您專注於手邊的工作 - 測試規劃、撰寫或執行。 它也與 Azure DevOps 供應項目的其餘部分不雜亂且一致。
協助我了解新頁面
新的 [測試計劃] 頁面共有 6 個區段,前 4 個區段是新的,而 [圖表 & 擴充性] 區段是現有的功能。
- 測試計劃標題:使用此標題來尋找、加入我的最愛、編輯、複製或克隆測試計劃。
- 測試套件樹狀結構:使用此樹狀結構來新增、管理、匯出或排序測試套件。 利用此專案來指派組態並執行使用者驗收測試。
- 定義索引標籤:透過此索引標籤,在所選的測試套件中,定序、新增及管理測試案例。
- 執行標籤:透過此標籤指派和執行測試,或查找測試結果進行深入分析。
- 圖表標籤:透過圖表追蹤測試執行和狀態,並可釘選至儀錶板。
- 擴充性:支持產品內 目前的擴充性點。
讓我們大致瞭解以下這些新區段。
1.測試計劃標頭
工作
[測試計劃] 標頭可讓您執行下列工作:
- 將測試計劃標示為我的最愛
- 取消標示我的最愛測試計劃
- 輕鬆瀏覽您最愛的測試計劃
- 檢視測試計劃的迭代路徑,這清楚地指出測試計劃是否是目前或過去
- 檢視測試進度報表的快速摘要,並使用連結瀏覽至完整報表。
- 流覽回 [所有/Mine 測試計劃] 頁面
選單快選項
測試計劃標頭的內容功能表提供下列選項:
- 複製測試計劃:這是可讓您快速複製目前測試計劃的新選項。 以下更多詳細數據。
- 編輯測試計劃:此選項可讓您編輯測試計劃工作專案表單來管理工作專案欄位。
- 測試計劃設定:此選項可讓您設定測試回合設定(建立組建或發行管線的關聯)和測試結果設定
複製測試計劃(新功能)
我們建議為每個 sprint/版本建立新的測試計劃。 在這樣做時,一般而言,可以複製先前週期的測試計劃,並經過少量修改後,複製的測試計劃即可用於新的週期。 為了簡化此程式,我們已在新頁面上啟用「複製測試計劃」功能。 利用它,您可以複製或克隆測試計劃。 這裡介紹其支援的 REST API 和,且該 API 也可讓您在不同專案間複製或複寫測試計劃。
如需測試計劃使用方式的詳細資訊,請參閱這裡 。
2. 測試套件樹狀結構
工作
Test suite 標頭可讓您執行下列工作:
- 展開/折疊:此工具列選項可讓您展開或折疊套件階層樹狀結構。
- 顯示子套件中的測試點:只有在您位於 [執行] 索引卷標時,才會顯示這個工具列選項。這可讓您在一個檢視中檢視指定套件及其子系的所有測試點,以便更輕鬆地管理測試點,而不需要一次流覽至個別套件。
- 排序套件:您可以拖放套件來重新排序套件階層,或者將它們從一個套件階層移動到測試計劃內的另一個套件階層。
內容選單選項
在測試套件樹狀結構上的右鍵選單提供下列選項:
-
建立新套件:您可以建立 3 種不同類型的套件,如下所示:
- 使用靜態套件或資料夾套件來組織您的測試。
- 使用需求型套件直接連結至需求/用戶劇本,以取得順暢的可追蹤性。
- 使用基於查詢的方式動態地組織符合查詢準則的測試用例。
- 指派組態:您可以指派套件的組態(例如:Chrome、Firefox、EdgeChromium),然後這些設定適用於您稍後新增至此套件的所有現有測試案例或新的測試案例。
- 匯出為 pdf/電子郵件:匯出測試計畫屬性、測試套件屬性,以及測試案例和測試點的詳細數據,以「電子郵件」或「列印至 pdf」。
- 開啟測試套件工作專案:此選項可讓您編輯 Test suite 工作專案表單來管理工作專案欄位。
- 指派測試人員來執行所有測試:此選項對於使用者驗收測試 (UAT) 案例非常有用,因為多個測試人員必須執行/執行相同的測試,通常屬於不同部門。
- 重新命名/刪除:這些選項可讓您管理套件名稱,或從測試計劃中移除套件及其內容。
3. 定義頁籤
[定義] 索引標籤可讓您定序、新增及管理測試套件的測試案例。 而執行索引標籤是用來指派測試點並執行它們。
[定義] 標籤和特定作業僅供 基本 + 測試計劃 存取層級或等同級別的使用者使用。 其他所有項目都應該由具有「基本」存取層級的用戶執行。
工作
[定義] 索引標籤可讓您執行下列工作:
- 使用工作項目表單新增測試案例:此選項可讓您使用工作項目表單建立新的測試案例。 建立的測試案例會自動新增至套件。
- 使用方格新增測試案例:此選項可讓您使用測試案例方格檢視建立一或多個測試案例。 建立的測試案例會自動新增至套件。
- 使用查詢新增現有的測試案例:此選項可讓您藉由指定查詢,將現有的測試案例新增至套件。
- 在套件內藉由拖放重新排序測試案例:您可以通過在指定的套件內拖放一或多個測試案例來調整它們的順序。 測試案例的順序僅適用於手動測試案例,不適用於自動化測試。
- 將測試案例從某個套件移至另一個套件:使用拖放,您可以將測試案例從一個測試套件移至另一個測試套件。
- 顯示方格:您可以使用方格模式來檢視/編輯測試案例,以及測試步驟。
- 全螢幕檢視:您可以使用此選項,在全螢幕模式中檢視整個 [定義] 索引卷標的內容。
- 篩選:使用篩選列,您可以使用「測試案例標題」、「指派給」和「狀態」字段來篩選測試案例清單。 您也可以按下資料列標頭來排序列表。
- 資料列選項:您可以使用 [資料行選項] 來管理 [定義] 索引標籤中顯示的數據行清單。 可供選取的數據行清單主要是來自測試案例工作項目表單的欄位。
右鍵選單選項
[定義] 索引標籤內 [測試案例] 節點的選單提供下列選項:
- 開啟/編輯測試案例工作專案表單:此選項可讓您使用工作專案窗體編輯測試案例,在其中編輯工作專案字段,包括測試步驟。
- 編輯測試案例:此選項可讓您大量編輯測試案例工作專案欄位。 不過,您無法使用此選項大量編輯測試步驟。
- 在方格中編輯測試案例:此選項可讓您大量編輯選取的測試案例,包括使用方格檢視的測試步驟。
- 設定組態:此選項可讓您使用測試個案層級設定覆寫套件層級設定。
- 移除測試案例:此選項可讓您從指定的套件中移除測試案例。 不過,它不會變更基礎測試案例的工作項目。
- 建立測試案例的複本/複製:此選項可讓您建立所選測試案例的複本/複製。 如需詳細資訊,請參閱下方。
- 檢視連結的專案:此選項可讓您查看指定測試案例的連結專案。 如需詳細資訊,請參閱下方。
複製/克隆測試案例(新功能)
如果您想要複製或克隆測試個案,您可以使用 [複製測試案例] 選項。 您可以指定要在其中建立複製/複製測試案例的目的地專案、目的地測試計劃和目的地測試套件。 此外,您也可以指定是否要包含現有的連結/附件,以流入複製的複本。
檢視連結專案 (新功能)
測試成品、需求和 Bug 之間的可追蹤性是 Test Plans 產品的重要價值主張。 使用 [檢視連結的專案] 選項,您可以輕鬆地查看此測試案例所連結的所有需求項目、使用此測試案例的所有測試組合/測試計畫,以及所有在測試執行過程中提交的錯誤。
4.執行索引標籤
"定義索引標籤可讓您整合、新增及管理測試套件的測試用例。" 而執行索引標籤是用來指派測試點並執行它們。
什麼是測試點? 測試案例本身不是可執行的。 當您將測試案例新增至測試套件時,會產生測試點。。 測試點是測試案例、測試套件、組態和測試人員的唯一組合。 範例:如果您有測試案例作為「測試登入功能」,並將 2 個設定新增至它作為 Edge 和 Chrome,則會產生 2 個測試點。 現在可以執行這些測試點。 在執行時,會產生測試結果。 透過測試結果檢視(執行歷程記錄),您可以看到測試點的所有執行。 測試點的最新執行是您在 [執行] 索引標籤中看到的內容。
因此,測試案例是可重複使用的實體。 藉由將它們包含在測試計劃或套件中,會產生測試點。 藉由執行測試點,您可以判斷所開發的產品或服務品質。
新頁面的主要優點之一是針對主要執行與追蹤測試的使用者(只需基本存取權限),他們不會被套件管理的複雜性弄得不知所措(對於這類使用者,「定義」標籤會被隱藏)。
[定義] 標籤和特定作業僅適用於具有 基本 + 測試計劃 存取層級或相等權限的使用者。 其他所有專案,包括 [執行] 索引標籤,都應該由具有 'Basic' 存取層級的用戶執行。
工作
[執行] 索引標籤可讓您執行下列工作:
- 大量標記測試點:此選項可讓您快速標記測試點的結果 - 通過、失敗、封鎖或不適用,而不需要透過測試執行器執行測試案例。 結果可以一次性標記一個或多個測試點。
- 執行測試點:此選項可讓您個別執行每個測試步驟,並使用測試執行器將它們標示為通過/失敗,以執行測試案例。 根據您測試的應用程式,您可以使用「Web 執行器」來測試「Web 應用程式」或「桌面執行器」以測試桌面和/或 Web 應用程式。 您也可以調用「使用選項執行」,以指定要進行測試的目標建置。
- 資料列選項:您可以使用 [資料行選項] 來管理 [執行] 索引標籤中顯示的數據列清單。 可供選取的數據行清單與測試點相關聯,例如執行者、指派的測試人員、組態等等。
- 全螢幕檢視:您可以使用此選項,在全螢幕模式中檢視整個 [執行] 索引卷標的內容。
- 篩選:使用篩選列,您可以使用「測試案例標題」、「指派給」、「狀態」、「測試結果」、「測試人員」和「組態」字段來篩選測試點清單。 您也可以按下資料列標頭來排序列表。
內容選單選項
[執行] 索引標籤中的 [測試點] 節點的上下文選單提供以下選項:
- 標記測試結果:與上述相同,可讓您快速標記測試點的結果 - 通過、失敗、封鎖或不適用。
- 執行測試點:與上述相同,可讓您透過測試執行器執行測試案例。
- 將測試重設為使用中:此選項可讓您將測試結果重設為作用中,從而忽略測試點的最後一個結果。
- 開啟/編輯測試案例工作專案表單:此選項可讓您使用工作專案窗體編輯測試案例,在其中編輯工作專案字段,包括測試步驟。
- 指派測試人員:此選項可讓您將測試點指派給測試人員以進行測試執行。
- 檢視測試結果:此選項可讓您檢視最新的測試結果詳細數據,包括每個測試步驟的結果、新增的批注或已提交的 Bug。
- 檢視執行歷程記錄:此選項可讓您檢視所選測試點的整個執行歷程記錄。 它會開啟新的頁面,您可以在其中調整篩選條件,以檢視不僅選取的測試點的執行歷程記錄,還能檢視整個測試案例的執行歷程記錄。
此現成的報表可協助您追蹤專案中一或多個測試計劃的執行和狀態。 請瀏覽測試計劃 > 進度報告* 以開始使用報告。
報表的三個區段包括下列各項:
- 摘要:顯示所選測試計劃的合併檢視。
- 結果趨勢:提供每日快照,展現執行和狀態的趨勢線。 它可以顯示 14 天的數據(預設值)、30 天或自定義範圍。
- 詳細數據:本節可讓您依每個測試計劃向下切入,併為您提供每個測試套件的重要分析。
注意
Azure DevOps Server 2020 不會在數據匯入期間匯入回收站中的摘要。 如果您想要匯入回收站中的摘要,請在開始數據匯入之前,先從回收站還原它們。
現在,您可以在 Visual Studio 中瀏覽套件時,查看儲存在 Azure Artifacts 中的 NuGet 套件授權資訊詳細數據。 這適用於使用授權表達式或內嵌授權表示的授權。 現在,您可以在 Visual Studio 套件詳細數據頁面中看到授權資訊的連結(下圖中的紅色箭號)。
按兩下連結會帶您前往網頁,您可以在其中檢視授權的詳細數據。 此體驗適用於授權表達式和內嵌授權,因此您可以在一個地方查看儲存在 Azure Artifacts 中的套件的授權詳細數據(針對指定授權資訊和 Visual Studio 支援的套件)。
您現在可以使用輕量級的驗證任務,對受歡迎的套件管理員進行驗證,這些管理員來自 Azure Pipelines。 這包括 NuGet、npm、PIP、Twine 和 Maven。 先前,您可以透過提供廣泛功能的任務向這些套件管理工具進行身份驗證,這包含發佈和下載套件的能力。 不過,這需要針對與套件管理員互動的所有活動使用這些工作。 如果您有自己的腳本用於執行發佈或下載套件等任務,您將無法在流水線中使用它們。 現在,您可以在管道 YAML 中使用自己設計的腳本,並使用這些新的輕量級工作執行驗證。 使用 npm 的範例:
在此圖中,使用 「ci」 和 「publish」 命令是任意的,您可以使用 Azure Pipelines YAML 支援的任何命令。 這可讓您完全控制命令調用,並讓您輕鬆地在管線設定中使用共用腳本。 如需詳細資訊,請參閱 NuGet、npm、PIP、Twine和 Maven 驗證工作檔。
我們很高興宣布,我們已加速動態消息頁面的載入時間。 平均而言,動態消息頁面的載入時間已經減少了 10%。 最大的摘要已經看到最大的改善第99個百分位數摘要頁面載入時間(所有摘要中最高的99個% 的載入時間)減少了75%。
您現在可以在公共資訊流內建立和儲存套件。 儲存在公用資訊來源中的套件可供所有網際網路上的人使用,無需驗證,不論它們是否在您的集合中,甚至無需登入 Azure DevOps 集合。 在 資料文件中深入瞭解公用訊息源, 或直接開始我們公開分享套件的 教學課程。
您現在可以將與 Azure Active Directory (AAD) 租戶相關聯的另一個集合中的饋送新增為您 Artifacts 饋送的上游來源。 您的資訊源可以從設定為上游來源的資訊源中尋找和使用套件,讓套件可在與 AAD 租用戶相關聯的集合之間輕鬆共用。 請參閱如何在檔 中設定此專案。
您現在可以安裝和使用 Python 認證提供者(artifacts-keyring),自動設定驗證,以在 Azure Artifacts 源中發布或使用 Python 套件。 使用認證提供者時,您不需要設定任何組態檔 (pip.ini/pip.conf/.pypirc),您只需要在第一次呼叫 pip 或 twine 時,就能在網頁瀏覽器中通過驗證流程。 請參閱 檔中的詳細資訊。
我們現在會在 Visual Studio NuGet 套件管理員中,針對從 Azure Artifacts 源提供的套件顯示套件圖示、描述和作者。 先前,大部分的元數據並未提供給 VS。
[連線至來源] 對話方塊是使用 Azure Artifacts 的進入點,其中包含有關如何設定客戶端和儲存庫,以便從 Azure DevOps 的來源推送和擷取套件的資訊。 我們已更新對話框,以新增詳細的設定資訊,並擴充我們提供使用指導的工具。
公共訊息源的公開預覽已受到廣泛的採用和回饋。 在此版本中,我們已將額外功能擴展至一般可用性。 現在,您可以將公用饋送設定為私人饋送的上游來源。 您可以通過上傳和下載組態至私人和專案範圍的饋送,來讓您的組態檔保持簡單。
當我們發行公用摘要時,我們也會發行 專案範圍的摘要。 到目前為止,專案範圍的饋送可以透過 REST API 或建立公用饋送,然後將專案設為私用來建立。 現在,您可以在任何專案中直接在平台建立專案範圍的訊息源,只要您有相關的許可權。 您也可以在資訊流選擇器中查看哪些資訊流屬於專案範疇,哪些屬於集合範疇。
我們已變更核心設計,以改善我們在 Azure Artifacts 摘要中儲存和傳遞 npm 套件的方式。 這協助我們將 npm 的某些使用最頻繁的 API 的延遲最多降低至十分之一。
我們已部署修正程式,以解決動態消息頁面上的輔助功能問題。 修正程式包括下列各項:
- 建立資訊流體驗
- 全域信息流設定使用專案
- 連接至動態體驗
先前,編輯程式代碼Wiki頁面時,系統會將您重新導向至 Azure Repos 中樞進行編輯。 目前,存放庫中樞並未針對 Markdown 編輯進行優化。
現在,您可以在Wiki內的並存編輯器中編輯程式代碼Wiki頁面。 這可讓您使用豐富的 Markdown 工具列來建立內容,讓編輯體驗與專案 Wiki 中的內容相同。 您仍然可以選擇在存放庫中編輯,方法是在內容功能表中選取 在 Repos 中編輯 選項。
當我們聆聽您的意見反應時,我們聽說您使用Wiki來擷取腦力激蕩檔、規劃檔、功能的想法、規格檔、會議分鐘數。 現在,您可以直接從規劃檔建立功能和用戶劇本,而不需要離開Wiki頁面。
若要建立工作專案,請在Wiki頁面中選取您要內嵌工作專案的文字,然後選取 [[新增工作專案]。 這可節省您的時間,因為您不需要先建立工作專案,請移至編輯,然後尋找要內嵌的工作專案。 當您不離開Wiki範圍時,它也會減少內容切換。
若要深入瞭解如何從 Wiki 建立和內嵌工作專案,請參閱我們的檔案 這裡。
先前,您沒有辦法與Wiki內的其他Wiki用戶互動。 這使得協作內容和回覆問題成為一項挑戰,因為交談必須透過郵件或聊天頻道進行。 使用批注,您現在可以直接在Wiki內與其他人共同作業。 您可以利用批注內的 @mention 使用者功能,吸引其他小組成員的注意。 這項功能是根據此建議票證 設定優先級。 如需有關批注的詳細資訊,請參閱我們的文件 這裡。
到目前為止,Wiki 樹狀結構會顯示從Wiki樹狀結構中的點 (.) 開始的所有資料夾和檔案。 在程式代碼Wiki案例中,這會導致像 .vscode 這樣的資料夾顯示在Wiki樹狀結構中,儘管它們應該是隱藏的。 現在,以點開頭的所有檔案和資料夾都會隱藏在Wiki樹狀結構中,因而減少不必要的雜亂。
您不再需要使用多行 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頁面的頁面訪問情況。 REST API 可讓您存取頁面在過去 30 天內瀏覽資訊。 您可以使用此資料來建立Wiki頁面的報告。 此外,您可以將此資料儲存在資料來源中,並建立儀錶板以獲得特定的洞見,例如 最多瀏覽的頁面。
您也會在每個頁面中看到過去 30 天的匯總頁面流覽計數。
注意
頁面造訪是指在 15 分鐘時間內,特定使用者的頁面檢視。
計量和深入解析可協助您持續改善管線的輸送量和穩定性。 我們新增了兩份新報告,讓您深入瞭解您的管線。
- 管線失敗報告會顯示組建通過率和失敗趨勢。 此外,它也會顯示工作失敗趨勢,以提供管線中哪些工作導致最大失敗數目的深入解析。
- 管線持續時間報告顯示管線執行所花費的時間趨勢。 它也會顯示管線中的哪些工作會花費最多時間。
查詢結果小工具 是我們最受歡迎的小工具之一,而且有充分的理由。 小工具會在儀錶板上直接顯示查詢的結果,而且在許多情況下很有用。
透過此更新,我們包含了許多期待已久的改善:
- 您現在可以選取您想要在 Widget 中顯示的數據行數目。 沒有 5 欄的限制!
- 小工具 支援從 1x1 到 10x10 的所有大小。
- 當您調整欄大小時,欄寬度會被儲存。
- 您可以 將小工具展開至全螢幕模式。 展開時,它會顯示查詢傳回的所有數據行。
前導時間和週期時間 由小組用來查看工作流經其開發管線所需的時間,並最終為客戶創造價值。
到目前為止,領導和週期時間小工具 都不支援進階篩選準則來提出這樣的問題,例如:「我的小組需要多久才能關閉較高優先級的項目?」
藉由這次更新,這類問題可以透過篩選版面泳道來解決。
我們也包含工作項目篩選,以限制圖表中顯示的工作專案。
你的衝刺燒毀現在可以被故事燒毀。 這是針對 開發人員社群的回饋而做的回應。
從 Sprint 中樞頁面選取 [分析] 索引標籤。然後,按如下所示設定您的報告:
- 選擇故事待辦事項
- 選擇用於燃盡圖的 故事點總和
新的Sprint Burndown 小工具支援依劇本點、工作計數或加總自定義欄位來向下燃燒。 您甚至可以為功能或史詩建立衝刺燃盡圖。 小工具會顯示平均燒毀、% 完成,以及範圍增加。 您可以設定團隊,以便在同一個儀錶板上顯示多個團隊的短衝程燃盡圖。 為了顯示所有這些絕佳的信息,我們可讓您在儀錶板上將其大小調整為 10x10。
若要試用,您可以從小工具目錄新增它,或編輯現有的 Sprint Burndown 小工具設定,並勾選 [立即試用新版本] 方塊。
注意
新的小工具會使用 Analytics。 如果您無法存取 Analytics,我們會保留舊版 Sprint Burndown。
衝刺燒毀回來了! 幾次短期衝刺之前,我們已從 Sprint Burndown 和 Taskboard 標題中移除上下文中的衝刺燃盡圖。 根據您的意見回饋,我們已改進並重新引入衝刺大盤進度縮圖。
按兩下縮圖會立即顯示較大的圖表版本,並可選擇在 [分析] 索引標籤下檢視完整報表。對完整報表所做的任何變更都會反映在標題中顯示的圖表中。 因此,您現在可以將它設定為根據故事、故事點或依工作計數進行燒毀,而不只是剩餘的工作量。
您現在可以建立儀錶板,而不需與團隊關聯。 建立儀錶板時,請選取 [項目儀錶板] 類型。
項目儀錶板就像小組儀錶板,不同之處在於它與小組沒有關聯,而您可以決定誰可以編輯/管理儀錶板。 就像小組儀錶板一樣,專案中的每個人都可以看到它。
所有需要小組內容的 Azure DevOps 小工具都已更新,可讓您在其設定中選取小組。 您可以將這些小工具新增至 [項目儀錶板],然後選取您想要的特定小組。
注意
針對自定義或第三方小工具,專案儀錶板會將預設小組的內容傳遞給這些小工具。 如果您有依賴小組內容的自定義小工具,您應該更新設定以讓您選取小組。
意見反應
我們很樂意聽到你的聲音! 您可以回報問題或提供想法,並透過 開發人員社群 追蹤問題,並取得 Stack Overflow的建議。
其他資源
訓練
學習路徑
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
認證
Microsoft Certified: Power Platform Developer Associate - Certifications
示範如何使用 Microsoft Power Platform Developer 來簡化、自動化及轉換商務工作和程序。