Azure DevOpsのSprint 160 Updateで、ストーリーポイント、カスタムフィールドの合計によるタスク数をサポートする新しいスプリントバーンダウンウィジェットを追加しました。さらに、アクセストークンの範囲を制限することにより、パイプラインのセキュリティを改善しました。
詳細については、以下の機能リストをご覧ください。
Azure Pipelines:
- マルチステージパイプラインのUX更新
- Kubernetes用environmentでカナリーデプロイ戦略のオーケストレーションを行う
- YAMLパイプラインでの承認ポリシー
- ACRがパイプラインリソースのファーストクラスとなりました
- パイプラインのメタデータリソースを定義しました
- パイプラインとACRリソースの実行状況の追跡を容易にしました
- YAMLパイプラインでのリソース認証を簡単にしました
- アクセストークンの範囲を制限して、パイプラインのセキュリティを改善する
- 成果物の評価とチェック
- YAMLでcronスケジュール設定の診断をサポート
- ARMテンプレートデプロイタスクの更新
- サービス接続のプロジェクトレベルセキュリティ
- Ubuntu 18.04 poolがlatestになりました
- KubernetesManifestタスクで、カナリアデプロイのためのService Mesh Interfaceの提供
- EnvironmentでのReviewAppの提供
Azure Artifacts:
Reporting:
Wiki:
ブランチポリシーは、重要なブランチの保護に役立つAzure Reposの強力な機能の1つです。REST APIにプロジェクトレベルでポリシーを設定する機能はありますが、そのためのユーザーインターフェイスが存在していませんでした。管理者は、プロジェクト内のすべてのリポジトリの特定のブランチに対して、デフォルトブランチにポリシーを設定できるようになりました。たとえば、管理者はプロジェクト内のすべてのリポジトリのすべてのmasterブランチに対してすべてのpull requestに対して、2人の最小レビューアーを必要とする設定ができます。ReposのProject SettingsのAdd branch protectionあります。
パイプラインを管理するために、ユーザーエクスペリエンスの更新に取り組んでいます。今回の更新により、パイプラインのエクスペリエンスがモダンになり、Azure DevOpsの方向性と一貫性が保たれます。さらに、これらの更新により、従来のビルドパイプラインとマルチステージYAMLパイプラインが1つのエクスペリエンスに統合されます。たとえば、マルチステージの表示と管理、パイプライン実行の承認、パイプラインの進行中にログを最後までスクロールする機能、およびパイプラインのブランチごとの状態表示といった機能が新しいエクスペリエンスに含まれています。
新しいエクスペリエンスを試してくれたすべての人に感謝します。まだ試していない場合は、プレビュー機能でマルチステージパイプラインを有効にしてください。Multi-stage pipelineの詳細については、こちらのドキュメントをご覧ください。
フィードバックをいただきありがとうございます。私たちは最新の以下の2つの最新の更新を紹介します。
- フォルダービューで発見しやすくなりました。
- ログビューでジャンプが不要になりました。
- 実行中であっても、以前および現在のタスクのログを簡単に表示します。
- ログ確認中にタスク間の移動が簡単になりました。
注意事項
次のアップデートでは、すべてのユーザーに対してこの機能をデフォルトで有効にする予定です。プレビューをオプトアウトするオプションが引き続き用意されます。さらにその数週間後、この機能は一般提供開始される予定です。
アプリケーションの更新を継続的に配信することの重要な利点の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パイプラインでは、リソース所有者が制御する承認構成に従います。リソース所有者は、リソースの承認を設定し、リソースを使用するすべてのパイプラインは、リソースを消費するステージの開始前に承認のために一時停止します。SOXベースのアプリケーション所有者は、デプロイメントのリクエスターが自分のデプロイメントの承認に関しては一般的に制限されます。
advanced approval optionsを使用して、リクエスターが承認しない、ユーザーのサブセットからの承認が必要、承認タイムアウトなどの承認ポリシーを構成できるようになりました。
パイプラインの一部として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コンテナリソースがパイプラインで使用される場合、完全なE2Eトレーサビリティを提供します。YAMLパイプラインによって参照されているすべてのリソースについて、コミット、作業項目、およびアーティファクトにまでさかのぼることができます。
パイプライン実行の概要ビューでは、次の情報が表示されます。
- resource version that triggered the run(実行をトリガーしたリソースバージョン)。別のAzureパイプラインの実行が完了したとき、またはコンテナーイメージがACRにプッシュされたタイミングで、パイプラインが呼び出されます。
- パイプラインを呼び出したcommit。また、パイプラインが参照している各リソースによるコミットの内訳もブレイクダウンして参照できます。
-
パイプラインが参照している各リソースに関連付けられているWork Item。
-
実行時に使用されているartifacts。
environmentのdeploymentsビューで、environmentに展開された各リソースのコミットと作業項目が確認できます。
リソースは、パイプラインの管理外で設定されますが、パイプラインで使用されます。リソースは使用する前に承認する必要があります。以前は、YAMLパイプラインで許可されていないリソースを使用すると、リソース認証エラーで失敗しました。失敗した後、実行結果の概要ページからリソースを承認する必要がありました。さらに、無許可のリソースを参照する変数(variable)を使用していた場合、パイプラインは失敗しました。
リソース承認の管理が簡単になりました。実行が失敗する代わりに、対象となるリソースを使用するタイミングで、リソースに対する許可が行われるまで実行を待機します。 リソース所有者は、Securityページからパイプラインを表示し、リソースを承認できます。
Azure Pipelinesで実行されるすべてのジョブは、アクセストークンを取得します。アクセストークンは、タスクとスクリプトによって使用され、Azure DevOpsにコールバックします。たとえば、アクセストークンを使用して、ソースコードの取得、ログ、テスト結果、アーティファクトのアップロード、またはAzure DevOpsへのREST呼び出しを行います。ジョブごとに新しいアクセストークンが生成され、ジョブが完了すると失効します。 この更新では、次の機能強化が追加されました。
- トークンがチームプロジェクト外部のリソースへアクセスできないようにする
これまで、すべてのパイプラインのデフォルトのスコープはチームプロジェクトコレクションでした。クラシックビルドパイプラインにおいては、スコープをチームプロジェクト内に変更できています。しかし、従来のリリースまたはYAMLパイプラインでは、その制御がありませんでした。今回の更新で、organizationの設定でパイプラインでの設定に関係なく、すべてのジョブで取得したトークンがプロジェクトスコープとなるをように強制する設定を導入しています。また、プロジェクトレベルにも設定を追加しました。これで、今後作成するすべての新しいプロジェクトとorganization、この設定が自動的にオンになります。
注意事項
organizationでの設定はプロジェクトの設定を上書きします。
既存のプロジェクトや組織でこの設定をオンにすると、パイプラインがアクセストークンを使用して、チームプロジェクトの外部にあるリソースへアクセスする場合、特定のパイプラインが失敗するかもしれません。パイプラインのエラーを軽減するために、プロジェクトビルドサービスアカウントに目的のリソースへのアクセスを明示的に許可できます。 これらのセキュリティ設定を有効にすることを強くお勧めします。
- アクセストークンから特定のアクセス許可を削除する
既定では、アクセストークンに多くのアクセス許可を付与します。アクセス許可の1つはQueue buildsです。今回の更新では、アクセストークンに対するこのアクセス許可を削除しました。パイプラインでこのアクセス許可が必要な場合は、使用するトークンに応じてプロジェクトビルドサービスアカウントまたはプロジェクトコレクションビルドサービスアカウントに明示的に許可できます。
今回の更新で、コンテナイメージアーティファクトを展開する環境に対してポリシーの定義をサポートしたため、ポリシーによる評価を追加できます。パイプラインが実行されると、環境を使用するステージを開始する前に実行が一時停止します。 指定されたポリシーは、展開されているイメージの利用可能なメタデータに対して評価されます。チェック合格はポリシー評価が成功したときで、チェックが失敗するとステージが失敗としてマークされます。
YAMLパイプラインでスケジュールを指定するためのcron構文の使用が着実に増加していることがわかりました。フィードバックによると、Azure Pipelinesが構文を正しく処理したかどうかを判断するのは難しいという声が多くありました。以前は、スケジュールの問題をデバッグするには、スケジュールされた実行時間まで待つ必要がありました。branch/構文エラーの診断に役立つように、パイプライン用の新しいアクションメニューを追加しました。Run pipelineメニューのScheduled runsで、パイプラインが今後実行するスケジュールのプレビューが表示され、cronスケジュールのエラーを診断できます。
以前は、ARMテンプレートデプロイタスクでサービス接続をフィルタリングしていませんでした。この仕様では、より狭いスコープのサービス接続を選択して、より広いスコープへのARMテンプレートのデプロイを実行する場合、デプロイに失敗する可能性があります。今回の更新で、選択したデプロイスコープに基づいて、スコープの狭いサービス接続を除外するサービス接続のフィルタリングを追加しました。
今回の更新では、サービス接続にハブレベルのセキュリティを追加しました。これにより、すべてのサービス接続について、ユーザーを追加/削除し、役割を割り当て、アクセスを一か所で集中管理できます。
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タスクでカナリア戦略が指定されていた場合、タスクは、レプリカが安定したワークロードに使用されるレプリカの割合に等しいベースラインおよびカナリアワークロードを作成していました。これは、要求レベルでトラフィックを目的の割合に分割することとまったく同じではありませんでした。この問題に取り組むため、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'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: MasterNamespaceConnect to feedダイアログは、Azure Artifactsへの入り口です。Azure DevOpsのフィードからパッケージをプッシュおよびプルするようにクライアントとリポジトリを構成する方法に関する情報が含まれています。今回の更新では、ダイアログを刷新して、仕様に際して必要なツール類の詳細および、セットアップ情報を追加しました。
パブリックフィードのパブリックプレビューには、大きな期待とフィードバックが寄せられています。このアップデートでは、追加機能を一般公開まで拡張しました。今回の更新で、プライベートフィードからのアップストリームソースとしてパブリックフィードを設定できます。プライベートフィードとプロジェクトスコープフィードの両方にアップストリームとして設定できるため、構成ファイルをシンプルに保つことができます。
パブリックフィードをリリースしたとき、project-scoped feedもリリースしました。これまで、プロジェクトスコープのフィードはREST APIを使うか、またはパブリックフィードを作成してからプロジェクトをプライベートにすることで作成できました。 今回の更新で、必要な権限があれば、任意のプロジェクトからポータルでプロジェクトスコープフィードを直接作成できます。また、フィードピッカーでプロジェクトのフィードとorganization全体のスコープのフィードを確認することもできます。
新しいSprint Burndownウィジェットは、ストーリーポイント、タスクのカウント、またはカスタムフィールドの合計をサポートしています。フィーチャーまたはエピックのスプリントバーンダウンを作成することもできます。ウィジェットには、平均バーンダウン、完了までの割合、およびスコープの増加が表示されます。チームを構成して、同じダッシュボードで複数のチームのスプリントのバーンダウンを表示できます。この素晴らしい情報をすべて表示して、ダッシュボードで最大10x10にサイズを変更できます。
試してみるには、ウィジェットカタログから追加するか、既存のSprint Burndownウィジェットの構成を編集して、Try the new version nowチェックボックスをオンにします。
注意事項
新しいウィジェットはAnalyticsを使用します。Analyticsにアクセスできない場合に備えて、従来のSprint Burndownも使えます。
編集ペインとプレビューペイン間で同期スクロールをサポートしたので、Wikiページの編集がより簡単になりました。片側をスクロールすると、自動的に反対側がスクロールされて、対応するセクションにマッピングされます。トグルボタンを使用して、同期スクロールを無効にできます。
注意事項
同期スクロールトグルの状態は、ユーザーおよびアカウントごとに保存されます。
今回の更新により、Wikiページのページアクセスに関するインサイトが分析できるようになりました。REST APIを使用すると、過去30日間のページアクセス情報にアクセスできます。このデータを使用して、Wikiページのレポートを作成できます。さらに、このデータをデータソースに保存し、ダッシュボードを作成して、閲覧回数の多い上位nページなどの特定の洞察を取得できます。
また、すべてのページで過去30日間の集計ページアクセス数が表示されます。
注意事項
ページアクセスは、特定のユーザーによる15分間隔のページビューとして定義されます。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Jeff Beehler