適用於 Slack 的新分析報告和 Azure Boards 應用程式 - 短期衝刺 155 更新

  • 發行項

在 Azure DevOps 的 Sprint 155 Update 中，我們將推出新的 Azure Boards 報表，以讓您能夠更輕鬆地追蹤重要的小組計量。 您會在 [面板]、[待辦項目] 和 [短期衝刺] 中樞的 [分析] 索引標籤下看到新的報表。 這些報表為完全互動式報表，可讓您加以調整以滿足自己的需求。

此外，也很高興在此宣布推出新的適用於 Slack 的 Azure Boards 應用程式。 這個應用程式可讓您從 Slack 通道監視工作項目活動，以及建立工作項目。

如需詳細資訊， 請參閱下方的功能 清單。

Azure DevOps 的新功能

功能

一般：

Azure Boards：

Azure Repos：

Azure Artifacts：

Azure Pipelines：

多階段 YAML 管線

託管 VM

Kubernetes

Test

Azure 體驗

整合

一般

Invite GitHub collaborators into Azure DevOps (邀請 GitHub 共同作業者加入 Azure DevOps)

當您使用 GitHub 身分識別登入時，您現在可以邀請共同作業者從 GitHub 到 Azure DevOps。 您可以從 Project 首頁和 [組織] 設定中的 [使用者] 頁面搜尋並邀請其他 GitHub 使用者。

Invite GitHub collaborators into Azure DevOps.

您必須透過 [組織設定中的原則] 底下的設定，為現有組織啟用此功能。 不過，根據預設，GitHub 身分識別所建立的組織會開啟它。

Enable for existing organizations.

注意

此功能不適用於非 GitHub 使用者，即使原則已開啟也一樣。

若要深入瞭解邀請小組成員，請參閱這裡的檔。 如果您在使用 GitHub 連線到 Azure DevOps 時遇到問題，請參閱 疑難解答驗證和邀請 GitHub 使用者常見問題。

Azure Boards

Get insights into your team’s health with three new Azure Boards reports (透過三種新的 Azure Boards 報表取得小組健康狀態的見解)

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

這三個新的互動式報告包括： 燒毀、 累計流程圖 （RC）和 速度。 您可以在新的分析索引標籤中看到報告。

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

  • 在這個短期衝刺中，我們剩下多少工作？ 我們正要完成嗎？
  • 開發程式哪一個步驟花費的時間最長？ 我們能做點什麼嗎？
  • 根據先前的反覆項目，我們應該規劃下一個短期衝刺多少工作？

注意

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

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

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

    Analytics tab in Sprint hub.

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

    CFD and velocity reports in boards.

有了新的報表，您就擁有更多小組的控制權和資訊。 以下列出一些範例：

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

以下是顯示過去 30 天「故事待辦專案」流程的CFD報表範例。

Example of the CFD report.

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

Example of a velocity report.

Azure Boards app for Slack (適用於 Slack 的 Azure Boards 應用程式)

我們很高興宣佈適用於 Slack 的新 Azure Boards 應用程式。 使用此應用程式，您可以監視工作項目活動，並從 Slack 通道建立工作專案。

應用程式可讓您設定及管理事件訂閱，包括建立和工作專案更新，以及在 Slack 通道中取得這些事件的通知。 Slack 通道中的交談可用來建立工作專案。 當您將工作專案指派給您時，您也會收到個人通知。 此外，工作專案 URL 的預覽可讓您起始討論。

Azure Boards app for Slack.

若要安裝 Azure Boards 應用程式，請按兩下 這裡。

自訂任務板數據行

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

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

Customizing columns on the taskboard.

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

Toggle to show or hide completed child work items on the backlog (切換以顯示或隱藏待辦項目中已完成的子工作項目)

很多時候，在精簡待辦專案時，您只想看到尚未完成的專案。 現在，您可以在待辦項目上顯示或隱藏已完成的子專案。

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

Show or hide child items on the backlog.

現在，您可以藉由在 Azure Boards 中啟動搜尋方塊，輕鬆地從搜尋方塊存取您最近造訪的面板、待辦專案、查詢和短期衝刺。

Activate the instant search box.

此外，您可以在搜尋方塊中輸入面板名稱，以搜尋整個專案的面板、待辦專案、查詢和短期衝刺。 現在，最重要的面板只是點擊一下。

Search for a board name.

Most recent tags displayed when tagging a work item (標記工作項目時顯示的最近標籤)

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

Most recent used tags displayed when tagging a work item.

Azure Repos

Improved code search filtering options (改進的程式碼搜尋篩選選項)

先前，程式代碼搜尋支援 39 個程式代碼搜尋篩選，例如 批注： 和 def：。 數據建議未使用許多篩選，因此我們會移除一些篩選，並合併其他篩選。 透過此更新，我們將篩選數目縮減為19。 這可協助讓程式代碼搜尋查詢更有效率，並減少介面中的雜亂。

Code search filter options.

例如，現在 func： 會對應至 method：，也就是如果您搜尋 func：Account 管理員，結果會對應至 method：Account 管理員。 同樣地 ，macrodef： 和 macroref： 會對應至 macro：。 另一方面，聯集：和組織：等篩選因為無法使用而已被取代。

Code coverage metrics and branch policy for pull requests (提取要求的程式碼涵蓋範圍計量與分支原則)

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

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

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

Define coverage thresholds.

Filter comment notifications from pull requests (篩選提取要求的註解通知)

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

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

Service hooks for pull request comments (提取要求註解的服務掛勾)

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

Service hooks for pull request comments.

Azure Artifacts

Share your packages publicly with public feeds (preview) (公開與公用摘要分享您的套件 (預覽))

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

Share your packages with public feeds.

Azure Pipelines

kustomize and kompose as bake options in KubernetesManifest task (kustomize 和 kompose 作為 KubernetesManifest 工作中的 bake 選項)

kustomize （Kubernetes sig-cli 的一部分）可讓您自定義原始、無範本的 YAML 檔案以供多種用途使用，並讓原始 YAML 保持不變。 已在 KubernetesManifest 工作的 bake 動作 下新增 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)

Support for cluster admin credentials in HelmDeploy task (HelmDeploy 工作中叢集系統管理員認證的支援)

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

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

Manage pipeline variables in YAML editor (在 YAML 編輯器中管理管線變數)

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

Manage pipeline variables in YAML editor.

New predefined variables in YAML pipeline (YAML 管線中新的預先定義變數)

變數提供將重要資料位元匯入管道不同部分的便利方式。 透過此更新，我們已將一些預先定義的變數新增至部署作業。 系統會自動設定這些變數，範圍限定於特定的部署作業，而且是唯讀的。

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

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

Cancel stage in a multi-stage YAML pipeline run (取消多階段 YAML 管線執行中的階段)

執行多階段 YAML 管線時，您現在可以在進行階段時取消執行階段。 如果您知道階段將會失敗，或您有另一個想要啟動的執行，這會很有説明。 這項功能也是我們未來支援重試失敗階段的必要條件。

Approvals in multi-stage YAML pipelines (多階段 YAML 管線中的核准)

我們繼續改善多階段 YAML 管線，現在可讓您將這些管線新增手動核准。 基礎結構擁有者可以在任何管線部署至環境的階段之前，保護其環境並尋求手動核准。 透過基礎結構（環境）和應用程式（管線）擁有者之間角色的完整隔離，您將確保手動註銷特定管線中的部署，並取得集中控制，以在所有部署中套用相同的檢查至環境。

Approvals in multi-stage YAML pipelines.

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

Pipeline runs deploying to dev will stop for approval.

對託管管線映像的更新

我們已更新數個 Azure Pipelines 裝載的 VM 映射。 您可以在這裡找到有關最新版本的更多詳細數據。 下列變更已新增為此更新的一部分：

  • 針對 VS2017 和 VS2019：

  • 針對 Ubuntu 16.04：

    • 已更新 helm 以一律提取最新版 （不再釘選於 v2.14.0）
    • 已新增數個 熱門 Docker 容器
    • 將 Python 更新為 2.7.16、3.4.10、3.5.7、3.6.9、3.7.4 版
    • 已變更 Rust 預設路徑和環境變數

  • 針對所有映像，新增 ImageVersion 映像版本的環境變數

如需特定映像可用的工具完整清單，請移至 [代理程式集>區詳細數據] > 設定。

Enhancements to DevOps Project for virtual machine (增強了 DevOps 專案的虛擬機器)

在此更新中，我們已增強DevOps Projects虛擬機 （VM） 工作流程，以包含不符合每個位置配額限制的VM。 之前，您必須依名稱和供應項目選擇 VM。 現在，您有隨選檢視，其中包含 VM 供應專案的詳細數據，例如成本/月、RAM、數據磁碟等。這可讓您更輕鬆地選取所需的虛擬機。

Enhancements to DevOps Project for virtual machine.

單一託管集區

在最後一個短期衝刺中，我們傳達了一個名為 Azure Pipelines 的新託管集區，以取代所有其他託管集區 - Hosted、Hosted VS2017、Hosted Ubuntu 1604、Hosted Windows 2019 與 VS2019、Hosted macOS 和 Hosted macOS High Sierra。 此變更將會使用此版本來實作。

擁有多個託管集區有時可能會造成混淆。 您無法準確瞭解正在取用並行的位置。 例如，如果您有10個平行作業的並行存取，您會在每個裝載集區中看到10個虛擬代理程式，但不正確。 當您的工作正在等候特定託管集區（例如裝載 VS2017）與所有閑置代理程式時，您可能會認為 Azure Pipelines 服務已中斷，而未意識到其他託管集區中可能會取用並行存取 （例如 Hosted Ubuntu 1604）。

透過這項變更，您會看到單一裝載的集區，讓您準確瞭解該集區中執行的工作數目。 我們計劃在未來幾個短期衝刺中推出這項變更。 您不需要對管線進行任何變更，因為我們會自動將作業從舊的託管集區重新導向至新整合集區中的適當映像。

Show correct pool information on each job (顯示每項作業的正確集區資訊)

先前，當您使用矩陣展開作業或變數來識別集區時，我們無法在記錄頁面中顯示正確的集區資訊。 透過此更新，我們已修正某些作業顯示不正確的集區信息的問題。

In-product support for flaky test management (不穩定測試管理的產品內支援)

Flaky 測試可能會影響開發人員的生產力，因為測試失敗可能與測試中的變更無關。 它們也可以影響出貨程式代碼的品質。 這就是為什麼我們新增了產品內對浮點測試管理的支援。 此功能支援偵測、報告和解決的端對端生命週期。 Flaky 測試管理支援系統和自定義偵測。

系統偵測可透過 VSTest 工作重新執行功能取得。 浮點測試是一項測試，可提供不同的結果，例如通過或失敗，即使原始程式碼或執行環境中沒有任何變更也一樣。 相同分支的所有進一步測試執行也會標示為浮點，直到解析並取消標記為止。 您也可以使用我們的 API 來插入自訂偵測機制。 一旦將測試識別為浮點，您就可以在管線中取得內容中測試報告的詳細數據。 然後，您可以決定浮點測試是否會影響您的管線失敗。 根據預設，會以額外的元數據的形式提供浮點測試資訊。

In-product support for flaky test management.

以下是具有測試摘要的報告範例。

Example of a report with the test summary.

如需有關浮點測試管理的詳細資訊，請參閱這裡的檔。

Azure 入口網站 中 WebApp 部署中心的改善

我們已在 Azure 入口網站 中改善 WebApp 的部署中心，並支援具有多個成品的管線。 現在，如果 Azure Pipelines 的非主要成品部署在 Web 應用程式上，您將從 Azure 入口網站 取得相關詳細數據。 您也會有已部署存放庫的深層連結，可從 Azure 入口網站 直接流覽至存放庫。 存放庫可以裝載於 Azure Repos 或 GitHub 中。

CI triggers for new branches (新分支的 CI 觸發程序)

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

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

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

Terraform integration with Azure Pipelines (Terraform 與 Azure Pipelines 整合)

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

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

Terraform integration with Azure Pipelines.

Integration with Google Analytics (與 Google Analytics (分析) 整合)

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

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

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

Integration with Google Analytics.

Pipeline caching (public preview) (管線快取 (公開預覽))

管線快取可讓您儲存長時間執行作業的結果，例如套件還原或相依性編譯，並在管線的下一次執行期間將它還原回。 這可能會導致更快速的組建。

如需詳細資訊，請參閱部落格文章，並在此發佈完整公告。

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

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

針對 PR 分支執行管線

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

略過第一個管線執行

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

服務端點命令增強功能

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

下一步

注意

這些功能將在未來兩到三周內推出。

前往 Azure DevOps 並查看。

移至 Azure DevOps

如何提供意見反應

我們很樂意聽到您對於這些功能的看法。 使用意見反應功能表來回報問題或提供建議。

Make a suggestion

您也可以在 Stack Overflow 上的社群取得建議和您的問題。

感謝您！

Sam Guckenheimer