新的短期衝刺待處理小工具與改善的管線安全性 - 短期衝刺 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 工作中以 Service Mesh 介面為基礎的 Canary 部署
• 在環境中檢閱應用程式

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

我們正在尋找在環境中支援 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

管線資源中繼資料作為預先定義的變數

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

在環境中檢閱應用程式

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 小工具，其中包含您要求的所有專案

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

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

注意

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

Wiki

用於編輯 Wiki 頁面的同步捲動

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

注意

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

Wiki 頁面的頁面流覽

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

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

注意

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

後續步驟

注意

這些功能將在接下來兩到三周推出。

請前往 Azure DevOps 並查看。

移至 Azure DevOps

如何提供意見反應

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

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

感謝您！

Jeff Beehler