Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Translate to Japanese to Azure DevOps release notes(unofficial) from https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/sprint-160-update

新しいスプリントバーンダウンウィジェットとパイプラインセキュリティの改善 - Sprint 160 Update

Azure DevOpsのSprint 160 Updateで、ストーリーポイント、カスタムフィールドの合計によるタスク数をサポートする新しいスプリントバーンダウンウィジェットを追加しました。さらに、アクセストークンの範囲を制限することにより、パイプラインのセキュリティを改善しました。

詳細については、以下の機能リストをご覧ください。

Features

Azure Pipelines:

Azure Artifacts:

Reporting:

Wiki:

Azure Repos

管理者が複数のレポジトリにブランチポリシーを設定可能になりました

ブランチポリシーは、重要なブランチの保護に役立つAzure Reposの強力な機能の1つです。REST APIにプロジェクトレベルでポリシーを設定する機能はありますが、そのためのユーザーインターフェイスが存在していませんでした。管理者は、プロジェクト内のすべてのリポジトリの特定のブランチに対して、デフォルトブランチにポリシーを設定できるようになりました。たとえば、管理者はプロジェクト内のすべてのリポジトリのすべてのmasterブランチに対してすべてのpull requestに対して、2人の最小レビューアーを必要とする設定ができます。ReposのProject SettingsのAdd branch protectionあります。

Cross-repo branch policy administration

Azure Pipelines

マルチステージパイプラインのUX更新

パイプラインを管理するために、ユーザーエクスペリエンスの更新に取り組んでいます。今回の更新により、パイプラインのエクスペリエンスがモダンになり、Azure DevOpsの方向性と一貫性が保たれます。さらに、これらの更新により、従来のビルドパイプラインとマルチステージYAMLパイプラインが1つのエクスペリエンスに統合されます。たとえば、マルチステージの表示と管理、パイプライン実行の承認、パイプラインの進行中にログを最後までスクロールする機能、およびパイプラインのブランチごとの状態表示といった機能が新しいエクスペリエンスに含まれています。

新しいエクスペリエンスを試してくれたすべての人に感謝します。まだ試していない場合は、プレビュー機能でマルチステージパイプラインを有効にしてください。Multi-stage pipelineの詳細については、こちらのドキュメントをご覧ください。

Multi-stage pipelins UX

フィードバックをいただきありがとうございます。私たちは最新の以下の2つの最新の更新を紹介します。

  1. フォルダービューで発見しやすくなりました。
  2. ログビューでジャンプが不要になりました。
  3. 実行中であっても、以前および現在のタスクのログを簡単に表示します。
  4. ログ確認中にタスク間の移動が簡単になりました。

moving logs

注意事項
次のアップデートでは、すべてのユーザーに対してこの機能をデフォルトで有効にする予定です。プレビューをオプトアウトするオプションが引き続き用意されます。さらにその数週間後、この機能は一般提供開始される予定です。

Kubernetes用environmentでカナリーデプロイ戦略のオーケストレーションを行う

アプリケーションの更新を継続的に配信することの重要な利点の1つは、特定のマイクロサービスの更新を運用環境にすばやくプッシュできることです。これにより、ビジネス要件の変化に迅速に対応可能となります。Environmentは、展開戦略のオーケストレーションを可能にし、ダウンタイムなしのリリースを促進するファーストクラスのコンセプトとして導入されました。以前は、ステップを連続して1回だけ実行する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...

Kuberenetesのカナリア戦略は、postRouteTrafficの間に死活監視をおこないながら、最初に10%のポッド、次に20%のポッドに変更を展開します。すべてがうまくいけば、100%になります。

環境でのVMリソースのサポートに関する早期のフィードバックを探しており、複数のマシンでローリング展開戦略を実行しています。登録するにはお問い合わせください。

YAMLパイプラインでの承認ポリシー

YAMLパイプラインでは、リソース所有者が制御する承認構成に従います。リソース所有者は、リソースの承認を設定し、リソースを使用するすべてのパイプラインは、リソースを消費するステージの開始前に承認のために一時停止します。SOXベースのアプリケーション所有者は、デプロイメントのリクエスターが自分のデプロイメントの承認に関しては一般的に制限されます。

advanced approval optionsを使用して、リクエスターが承認しない、ユーザーのサブセットからの承認が必要、承認タイムアウトなどの承認ポリシーを構成できるようになりました。

Approval policies for YAML pipeline

ACRがパイプラインリソースのファーストクラスとなりました

パイプラインの一部としてACR(Azure Container Registry)に発行されたコンテナーイメージを使うとすると、新しいイメージが発行されたときにパイプラインをトリガーする必要があります。このような場合、YAMLで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イメージのメタデータには、variablesに前もって定義している値を使用してアクセスできます。次のリストには、パイプラインで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パイプラインによって参照されているすべてのリソースについて、コミット、作業項目、およびアーティファクトにまでさかのぼることができます。

パイプライン実行の概要ビューでは、次の情報が表示されます。

  • resource version that triggered the run(実行をトリガーしたリソースバージョン)。別のAzureパイプラインの実行が完了したとき、またはコンテナーイメージがACRにプッシュされたタイミングで、パイプラインが呼び出されます。

Traceability for pipelines

  • パイプラインを呼び出したcommit。また、パイプラインが参照している各リソースによるコミットの内訳もブレイクダウンして参照できます。

commits that are consumed by the pipeline

  • パイプラインが参照している各リソースに関連付けられているWork Item

  • 実行時に使用されているartifacts

available artifacts

environmentのdeploymentsビューで、environmentに展開された各リソースのコミットと作業項目が確認できます。

environment's deployments view

YAMLパイプラインでのリソース認証を簡単にしました

リソースは、パイプラインの管理外で設定されますが、パイプラインで使用されます。リソースは使用する前に承認する必要があります。以前は、YAMLパイプラインで許可されていないリソースを使用すると、リソース認証エラーで失敗しました。失敗した後、実行結果の概要ページからリソースを承認する必要がありました。さらに、無許可のリソースを参照する変数(variable)を使用していた場合、パイプラインは失敗しました。

リソース承認の管理が簡単になりました。実行が失敗する代わりに、対象となるリソースを使用するタイミングで、リソースに対する許可が行われるまで実行を待機します。 リソース所有者は、Securityページからパイプラインを表示し、リソースを承認できます。

Simplified resource authorization in YAML pipelines

アクセストークンの範囲を制限して、パイプラインのセキュリティを改善する

Azure Pipelinesで実行されるすべてのジョブは、アクセストークンを取得します。アクセストークンは、タスクとスクリプトによって使用され、Azure DevOpsにコールバックします。たとえば、アクセストークンを使用して、ソースコードの取得、ログ、テスト結果、アーティファクトのアップロード、またはAzure DevOpsへのREST呼び出しを行います。ジョブごとに新しいアクセストークンが生成され、ジョブが完了すると失効します。 この更新では、次の機能強化が追加されました。

  • トークンがチームプロジェクト外部のリソースへアクセスできないようにする

これまで、すべてのパイプラインのデフォルトのスコープはチームプロジェクトコレクションでした。クラシックビルドパイプラインにおいては、スコープをチームプロジェクト内に変更できています。しかし、従来のリリースまたはYAMLパイプラインでは、その制御がありませんでした。今回の更新で、organizationの設定でパイプラインでの設定に関係なく、すべてのジョブで取得したトークンがプロジェクトスコープとなるをように強制する設定を導入しています。また、プロジェクトレベルにも設定を追加しました。これで、今後作成するすべての新しいプロジェクトとorganization、この設定が自動的にオンになります。

注意事項
organizationでの設定はプロジェクトの設定を上書きします。

既存のプロジェクトや組織でこの設定をオンにすると、パイプラインがアクセストークンを使用して、チームプロジェクトの外部にあるリソースへアクセスする場合、特定のパイプラインが失敗するかもしれません。パイプラインのエラーを軽減するために、プロジェクトビルドサービスアカウントに目的のリソースへのアクセスを明示的に許可できます。 これらのセキュリティ設定を有効にすることを強くお勧めします。

  • アクセストークンから特定のアクセス許可を削除する

既定では、アクセストークンに多くのアクセス許可を付与します。アクセス許可の1つはQueue buildsです。今回の更新では、アクセストークンに対するこのアクセス許可を削除しました。パイプラインでこのアクセス許可が必要な場合は、使用するトークンに応じてプロジェクトビルドサービスアカウントまたはプロジェクトコレクションビルドサービスアカウントに明示的に許可できます。

成果物の評価とチェック

今回の更新で、コンテナイメージアーティファクトを展開する環境に対してポリシーの定義をサポートしたため、ポリシーによる評価を追加できます。パイプラインが実行されると、環境を使用するステージを開始する前に実行が一時停止します。 指定されたポリシーは、展開されているイメージの利用可能なメタデータに対して評価されます。チェック合格はポリシー評価が成功したときで、チェックが失敗するとステージが失敗としてマークされます。

Evaluate artifact check

YAMLでcronスケジュール設定の診断をサポート

YAMLパイプラインでスケジュールを指定するためのcron構文の使用が着実に増加していることがわかりました。フィードバックによると、Azure Pipelinesが構文を正しく処理したかどうかを判断するのは難しいという声が多くありました。以前は、スケジュールの問題をデバッグするには、スケジュールされた実行時間まで待つ必要がありました。branch/構文エラーの診断に役立つように、パイプライン用の新しいアクションメニューを追加しました。Run pipelineメニューのScheduled runsで、パイプラインが今後実行するスケジュールのプレビューが表示され、cronスケジュールのエラーを診断できます。

Diagnosing cron schedules in YAML

ARMテンプレートデプロイタスクの更新

以前は、ARMテンプレートデプロイタスクでサービス接続をフィルタリングしていませんでした。この仕様では、より狭いスコープのサービス接続を選択して、より広いスコープへのARMテンプレートのデプロイを実行する場合、デプロイに失敗する可能性があります。今回の更新で、選択したデプロイスコープに基づいて、スコープの狭いサービス接続を除外するサービス接続のフィルタリングを追加しました。

サービス接続のプロジェクトレベルセキュリティ

今回の更新では、サービス接続にハブレベルのセキュリティを追加しました。これにより、すべてのサービス接続について、ユーザーを追加/削除し、役割を割り当て、アクセスを一か所で集中管理できます。

Project level security for services connections

Ubuntu 18.04 poolがlatestになりました

Azure Pipelinesは、Ubuntu 18.04でのジョブの実行をサポートするようになりました。 マイクロソフトがホストするAzure Pipelinesプールを更新して、Ubuntu-18.04イメージを含めました。YAMLパイプラインでubuntu-latestプールを参照する場合、ubuntu-16.04ではなくubuntu-18.04を意味します。 ubuntu-16.04を明示的に使用することで、ジョブ内の16.04イメージをターゲットにできます。

KubernetesManifestタスクで、カナリアデプロイのためのService Mesh Interfaceの提供

これまで、KubernetesManifestタスクでカナリア戦略が指定されていた場合、タスクは、レプリカが安定したワークロードに使用されるレプリカの割合に等しいベースラインおよびカナリアワークロードを作成していました。これは、要求レベルでトラフィックを目的の割合に分割することとまったく同じではありませんでした。この問題に取り組むため、KubernetesManifestタスクにService Mesh Interfaceベースのカナリア展開のサポートを追加しました。

Service Mesh Interfaceの抽象化により、LinkerdやIstioなどのサービスメッシュプロバイダーとのプラグアンドプレイ構成が可能になります。現在、KubernetesManifestタスクは、デプロイ戦略のライフサイクル中にSMIのTrafficSplitオブジェクトを安定したベースラインサービスとカナリアサービスにマッピングするという骨の折れる作業を取り除きます。安定、ベースライン、カナリア間のトラフィックの望ましい割合の分割は、サービスメッシュプレーン内のリクエストで割合のトラフィック分割が制御されるため、より正確です。

以下は、SMIベースのカナリアデプロイをローリング方式で実行するサンプルです。

- 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'

EnvironmentでのReviewAppの提供

ReviewAppは、Gitリポジトリからのすべてのpull requestを動的環境リソースにデプロイします。レビュー担当者は、これらの変更がどのように見えるかを確認し、他の依存サービスがメインブランチにマージされ、運用環境へ展開される前にサービスを操作できます。これにより、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

フィード接続エクスペリエンスの更新

Connect to feedダイアログは、Azure Artifactsへの入り口です。Azure DevOpsのフィードからパッケージをプッシュおよびプルするようにクライアントとリポジトリを構成する方法に関する情報が含まれています。今回の更新では、ダイアログを刷新して、仕様に際して必要なツール類の詳細および、セットアップ情報を追加しました。

パブリックフィードをupstreamとする機能を一般提供開始しました

パブリックフィードのパブリックプレビューには、大きな期待とフィードバックが寄せられています。このアップデートでは、追加機能を一般公開まで拡張しました。今回の更新で、プライベートフィードからのアップストリームソースとしてパブリックフィードを設定できます。プライベートフィードとプロジェクトスコープフィードの両方にアップストリームとして設定できるため、構成ファイルをシンプルに保つことができます。

ポータルからプロジェクトスコープ限定のフィードが作成できるようになりました

パブリックフィードをリリースしたとき、project-scoped feedもリリースしました。これまで、プロジェクトスコープのフィードはREST APIを使うか、またはパブリックフィードを作成してからプロジェクトをプライベートにすることで作成できました。 今回の更新で、必要な権限があれば、任意のプロジェクトからポータルでプロジェクトスコープフィードを直接作成できます。また、フィードピッカーでプロジェクトのフィードとorganization全体のスコープのフィードを確認することもできます。

Reporting

Sprintバーンダウンウィジェットはあなたの知りたいことをなんでも答えてくれます

新しいSprint Burndownウィジェットは、ストーリーポイント、タスクのカウント、またはカスタムフィールドの合計をサポートしています。フィーチャーまたはエピックのスプリントバーンダウンを作成することもできます。ウィジェットには、平均バーンダウン、完了までの割合、およびスコープの増加が表示されます。チームを構成して、同じダッシュボードで複数のチームのスプリントのバーンダウンを表示できます。この素晴らしい情報をすべて表示して、ダッシュボードで最大10x10にサイズを変更できます。

Sprint Burndown widget

試してみるには、ウィジェットカタログから追加するか、既存のSprint Burndownウィジェットの構成を編集して、Try the new version nowチェックボックスをオンにします。

注意事項
新しいウィジェットはAnalyticsを使用します。Analyticsにアクセスできない場合に備えて、従来のSprint Burndownも使えます。

Wiki

wikiのページを編集中にスクロールが同期するようになりました。

編集ペインとプレビューペイン間で同期スクロールをサポートしたので、Wikiページの編集がより簡単になりました。片側をスクロールすると、自動的に反対側がスクロールされて、対応するセクションにマッピングされます。トグルボタンを使用して、同期スクロールを無効にできます。

Synchronous scroll for editition wiki pages

注意事項
同期スクロールトグルの状態は、ユーザーおよびアカウントごとに保存されます。

wikiページの訪問者が確認できるようになりました

今回の更新により、Wikiページのページアクセスに関するインサイトが分析できるようになりました。REST APIを使用すると、過去30日間のページアクセス情報にアクセスできます。このデータを使用して、Wikiページのレポートを作成できます。さらに、このデータをデータソースに保存し、ダッシュボードを作成して、閲覧回数の多い上位nページなどの特定の洞察を取得できます。

また、すべてのページで過去30日間の集計ページアクセス数が表示されます。

Page visits for Wiki pages

注意事項
ページアクセスは、特定のユーザーによる15分間隔のページビューとして定義されます。

Next steps

注意事項

ここで議論されている機能は今後二~三週にわたって順次展開されます。

これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。

Go to Azure DevOps Services

Feedback

これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。

Make a suggestion

アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。

ありがとうございました。

Jeff Beehler

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.