新的短期衝刺燒毀小工具與改善的管線安全性 - Sprint 160 更新

在 Azure DevOps 的 Sprint 160 更新中，我們新增了新的短期衝刺燒毀小工具，可支援按故事點、工作計數和加總自定義欄位來向下燃燒。 此外，我們還透過限制存取權杖的範圍，提高管線的安全性。

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

Azure DevOps 的新功能

功能

Azure Repos：

• 跨存放庫分支原則管理

Azure Pipelines：

• 多階段管線 UX
• 針對 Kubernetes 環境協調 Canary 部署策略
• 核准 YAML 管線原則
• ACR 作為一流的管線資源
• 管線資源中繼資料即預先定義變數
• 管線和 ACR 資源的可追蹤性
• YAML 管線中的簡化資源授權
• 透過限制存取權杖的範圍以提高管線安全性
• 評估成品檢查
• 自動化測試錯誤訊息中的 Markdown 支援
• 使用 YAML 診斷 Cron 排程
• ARM 範本部署工作的更新
• 服務連線的專案層級安全性
• Ubuntu 18.04 集區
• KubernetesManifest 工作中的服務網格介面型 Canary 部署
• 環境中的 ReviewApp

Azure Artifacts：

• 已更新連線至摘要體驗
• 上游支援現已正式推出公用摘要
• 從入口網站建立專案範圍的摘要

報告：

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

Wiki：

• 同步捲動以編輯 Wiki 頁面
• Wiki 頁面的頁面瀏覽次數

Azure Repos

跨存放庫分支原則管理

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

Azure Pipelines

多階段管線 UX

我們一直在處理更新的用戶體驗，以管理您的管線。 這些更新可讓管線體驗現代化且與 Azure DevOps 的方向一致。 此外，這些更新會將傳統組建管線和多階段 YAML 管線整合成單一體驗。 例如，新體驗中包含下列功能;檢視和管理多個階段、核准管線執行、在管線仍在進行中時，能夠一路捲動回記錄，以及管線的每個分支健康情況。

感謝所有曾嘗試過新體驗的人。 如果您尚未嘗試，請在預覽功能中啟用 多階段管線 。 若要深入瞭解多階段管線，請參閱這裡的檔。

由於您的意見反應，我們在最後兩個更新中解決了下列問題。

1. 資料夾檢視的可探索性。
2. 記錄檢視中的跳躍性。
3. 即使執行正在進行中，也隨時顯示先前和目前工作的記錄。
4. 在檢閱記錄時，更輕鬆地在工作之間巡覽。

注意

在下一個更新中，我們計劃針對每個人默認開啟此功能。 您仍然可以退出宣告預覽。 幾周后，此功能將正式推出。

針對 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%。

核准 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

管線資源中繼資料即預先定義變數

我們已為管線中的 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

管線和 ACR 資源的可追蹤性

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

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

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

  

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

  

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

• 可供 執行使用的成品 。

  

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

YAML 管線中的簡化資源授權

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

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

透過限制存取權杖的範圍以提高管線安全性

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

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

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

  注意

  組織設定會覆寫項目設定。

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

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

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

評估成品檢查

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

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

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

使用 YAML 診斷 Cron 排程

我們已看到使用cron語法在YAML管線中指定排程的穩步增加。 當我們聆聽您的意見反應時，我們聽說您很難判斷 Azure Pipelines 是否已正確處理您的語法。 之前，您必須等候排程執行的實際時間，以偵錯排程問題。 為了協助您診斷分支/語法錯誤，我們新增了管線的新動作功能表。 [ 執行管線] 功能表中的 [排程執行 ] 可讓您預覽管線即將進行的一些排程執行，以協助您診斷 cron 排程的錯誤。

ARM 範本部署工作的更新

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

服務連線的專案層級安全性

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

Ubuntu 18.04 集區

Azure Pipelines 現在支援在 Ubuntu 18.04 上執行您的作業。 我們已更新Microsoft裝載的 Azure Pipelines 集區，以包含Ubuntu-18.04 映像。 現在，當您在 YAML 管線中參考 ubuntu-latest 集區時，這表示 ubuntu-18.04 而非 ubuntu-16.04。 您仍然可以明確地使用 ubuntu-16.04 ，將作業中的 16.04 映射設為目標。

KubernetesManifest 工作中的服務網格介面型 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'

環境中的 ReviewApp

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

Azure Artifacts

已更新連線至摘要體驗

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

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

公開摘要的公開預覽已收到絕佳的採用和意見反應。 在此更新中，我們已將其他功能擴充至正式運作。 現在，您可以從私人摘要將公用摘要設定為上游來源。 您可以讓組態檔在私人和專案範圍的摘要中上游，讓組態檔保持簡單。

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

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

報表

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

新的Sprint Burndown 小工具支援依劇本點、工作計數或加總自定義欄位來向下燃燒。 您甚至可以為功能或 Epics 建立短期衝刺燒毀。 小工具會顯示平均燒毀、完成百分比和範圍增加。 您可以設定小組，讓您在同一個儀錶板上顯示多個小組的短期衝刺燒毀。 為了顯示所有這些絕佳的信息，我們可讓您在儀錶板上將其大小調整為 10x10。

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

注意

新的小工具會使用 Analytics。 如果您無法存取 Analytics，我們會保留舊版 Sprint Burndown。

Wiki

同步捲動以編輯 Wiki 頁面

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

注意

同步捲動切換的狀態會儲存每個用戶和組織。

Wiki 頁面的頁面瀏覽次數

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

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

注意

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

下一步

注意

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

前往 Azure DevOps 並查看。

移至 Azure DevOps

如何提供意見反應

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

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

感謝您！

Jeff Beehler