新しいスプリント バーンダウン ウィジェットとパイプラインのセキュリティの強化 - Sprint 160 Update
Azure DevOps の Sprint 160 Update では、ストーリー ポイント、タスクの数、カスタム フィールドの合計による書き込みをサポートする新しいスプリント バーンダウン ウィジェットを追加しました。 さらに、アクセス トークンのスコープを制限することで、パイプラインのセキュリティを強化しました。
詳細については、以下の 機能 の一覧を参照してください。
Azure DevOps の新機能
機能
Azure Repos:
Azure Pipelines:
- マルチステージ パイプライン UX
- Kubernetes の環境でカナリアデプロイ戦略を調整する
- YAML パイプラインの承認ポリシー
- ファースト クラスのパイプライン リソースとしての ACR
- 定義済み変数としてのパイプライン リソースのメタデータ
- パイプラインと ACR リソースの追跡可能性
- YAML パイプラインでのリソース承認の簡素化
- アクセス トークンのスコープを制限することでパイプラインのセキュリティを強化する
- 成果物のチェックを評価する
- 自動テスト エラー メッセージでの Markdown のサポート
- YAML での cron スケジュールの診断
- ARM テンプレートのデプロイ タスクに更新する
- サービス接続のプロジェクト レベルのセキュリティ
- Ubuntu 18.04 プール
- KubernetesManifest タスクでの Service Mesh Interface ベースのカナリア デプロイ
- 環境での ReviewApp
Azure Artifacts:
レポート:
Wiki:
Azure Repos
リポジトリ間ブランチ ポリシーの管理
ブランチ ポリシーは、重要なブランチを保護するのに役立つAzure Reposの強力な機能の 1 つです。 プロジェクト レベルでポリシーを設定する機能は REST API に存在しますが、ユーザー インターフェイスはありませんでした。 管理者は、プロジェクト内のすべてのリポジトリに対して、特定のブランチまたは既定のブランチにポリシーを設定できるようになりました。 たとえば、管理者は、プロジェクト内のすべてのリポジトリにわたってすべてのメイン ブランチに対して行われたすべての pull request に対して、2 つの最小レビュー担当者を要求できます。 ブランチ保護機能の追加は、Repos プロジェクトの設定で確認できます。
Azure Pipelines
マルチステージ パイプライン UX
パイプラインを管理するために、更新されたユーザー エクスペリエンスに取り組んできました。 これらの更新により、パイプラインのエクスペリエンスが最新になり、Azure DevOps の方向と一貫性が保たれます。 さらに、これらの更新により、クラシック ビルド パイプラインとマルチステージ YAML パイプラインが 1 つのエクスペリエンスにまとめられます。 たとえば、次の機能が新しいエクスペリエンスに含まれています。複数のステージの表示と管理、パイプラインの実行の承認、パイプラインの進行中にログをスクロールして戻す機能、パイプラインのブランチごとの正常性。
新しいエクスペリエンスを試したすべてのユーザーに感謝します。 試していない場合は、プレビュー機能で マルチステージ パイプライン を有効にします。 マルチステージ パイプラインの詳細については、 こちらの ドキュメントを参照してください。
フィードバックのおかげで、最後の 2 つの更新プログラムで次の点に対処しました。
- フォルダー ビューの検出可能性。
- ログ ビューの Jumpiness。
- 実行が進行中の場合でも、以前のタスクと現在のタスクのログを簡単に表示できます。
- ログを確認するときに、タスク間を簡単に移動できるようにします。
Note
次の更新では、すべてのユーザーに対してこの機能を既定で有効にする予定です。 プレビューをオプトアウトすることもできます。 その数週間後、この機能は一般公開されます。
Kubernetes の環境でカナリアデプロイ戦略を調整する
アプリケーション更新プログラムの継続的デリバリーの主な利点の 1 つは、特定のマイクロサービスの運用環境に更新プログラムをすばやくプッシュできることです。 これにより、ビジネス要件の変化に迅速に対応できます。 環境 は、デプロイ戦略のオーケストレーションを可能にし、ダウンタイムゼロのリリースを容易にする、ファースト クラスの概念として導入されました。 以前は、手順を順番に 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 ベースのアプリケーション所有者は、展開の要求者が独自のデプロイを承認できないように制限するのが一般的です。
高度な承認オプションを使用して、要求者が承認しない、ユーザーのサブセットからの承認を要求する、承認タイムアウトなどの承認ポリシーを構成できるようになりました。
ファースト クラスのパイプライン リソースとしての 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 呼び出しを行います。 ジョブごとに新しいアクセス トークンが生成され、ジョブが完了すると有効期限が切れます。 この更新プログラムでは、次の機能強化が追加されました。
トークンがチーム プロジェクトの外部のリソースにアクセスできないようにする
これまで、すべてのパイプラインの既定のスコープはチーム プロジェクト コレクションでした。 スコープを従来のビルド パイプラインのチーム プロジェクトに変更できます。 ただし、クラシック リリースまたは YAML パイプラインに対しては、そのコントロールがありませんでした。 この更新プログラムでは、パイプラインで構成されている内容に関係なく、すべてのジョブがプロジェクト スコープのトークンを取得するように強制するorganization設定を導入します。 また、プロジェクト レベルで設定を追加しました。 これで、作成するすべての新しいプロジェクトとorganizationで、この設定が自動的にオンになります。
Note
organization設定は、プロジェクト設定をオーバーライドします。
既存のプロジェクトや組織でこの設定をオンにすると、アクセス トークンを使用してチーム プロジェクトの外部にあるリソースにパイプラインがアクセスすると、特定のパイプラインが失敗する可能性があります。 パイプラインの障害を軽減するために、目的のリソースへのアクセス権を Project Build Service Account に明示的に付与できます。 これらのセキュリティ設定を有効にすることを強くお勧めします。
アクセス トークンの特定のアクセス許可を削除する
既定では、アクセス トークンに対して多数のアクセス許可が付与されます。このアクセス許可の 1 つは キュー ビルドです。 この更新プログラムでは、アクセス トークンに対するこのアクセス許可を削除しました。 パイプラインにこのアクセス許可が必要な場合は、使用するトークンに応じて、 プロジェクト ビルド サービス アカウント または プロジェクト コレクション ビルド サービス アカウント に明示的に付与できます。
成果物のチェックを評価する
一連のポリシーを定義し、コンテナー イメージ成果物の環境でポリシー評価をチェックとして追加できるようになりました。 パイプラインを実行すると、環境を使用するステージを開始する前に実行が一時停止します。 指定されたポリシーは、デプロイされるイメージの使用可能なメタデータに対して評価されます。 チェックは、ポリシーが成功したときに成功し、チェックが失敗した場合にステージを失敗としてマークします。
自動テスト エラー メッセージでの Markdown のサポート
自動テストのエラー メッセージで Markdown がサポートされるようになりました。 テストの実行結果とテスト結果の両方のエラー メッセージを簡単に書式設定して、読みやすさを向上させ、Azure Pipelines でのエラーのトラブルシューティングを容易にすることができます。 サポートされている Markdown 構文については、 こちらを参照してください。
YAML での cron スケジュールの診断
YAML パイプラインでスケジュールを指定するための cron 構文の使用が着実に増加しています。 ご意見をお寄せくださいましたが、Azure Pipelines が構文を正しく処理したかどうかを判断するのは難しいと聞きました。 以前は、スケジュールされた実行の実際の時刻を待って、スケジュールの問題をデバッグする必要があります。 ブランチ/構文エラーの診断に役立つ、パイプラインの新しいアクション メニューを追加しました。 [パイプラインの実行] メニューの [ スケジュールされた実行 ] では、cron スケジュールでエラーを診断するのに役立つ、パイプラインに対して予定されているいくつかのスケジュールされた実行のプレビューが表示されます。
ARM テンプレートのデプロイ タスクに更新する
以前は、ARM テンプレートのデプロイ タスクでサービス接続をフィルター処理しませんでした。 これにより、より広範なスコープへの ARM テンプレートのデプロイを実行するために、より低いスコープのサービス接続を選択すると、デプロイが失敗する可能性があります。 ここで、選択したデプロイ スコープに基づいて、より低いスコープのサービス接続を除外するサービス接続のフィルター処理を追加しました。
サービス接続のプロジェクト レベルのセキュリティ
この更新プログラムでは、サービス接続のハブ レベルのセキュリティが追加されました。 これで、すべてのサービス接続の一元的な場所で、ユーザーの追加と削除、ロールの割り当て、アクセスの管理を行うことができます。
Ubuntu 18.04 プール
Azure Pipelines では、Ubuntu 18.04 でのジョブの実行がサポートされるようになりました。 Ubuntu-18.04 イメージを含むように、Microsoft がホストする Azure Pipelines プールを更新しました。 ここで、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'
環境での ReviewApp
ReviewApp は、Git リポジトリから動的な環境リソースにすべての pull request をデプロイします。 レビュー担当者は、メイン ブランチにマージして運用環境にデプロイする前に、それらの変更がどのように見えるかを確認したり、他の依存サービスと連携したりできます。 これにより、 reviewApp リソースを簡単に作成および管理でき、環境機能のすべての追跡可能性と診断機能の恩恵を受けることができます。 reviewApp キーワード (keyword)を使用すると、リソースの複製を作成し (環境内の既存のリソースに基づいて新しいリソースを動的に作成する)、新しいリソースを環境に追加できます。
環境で 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 を使用して作成することも、パブリック フィードを作成してからプロジェクトをプライベートにすることで作成することもできます。 これで、必要なアクセス許可がある場合は、任意のプロジェクトからポータルでプロジェクト スコープフィードを直接作成できます。 また、どのフィードがプロジェクトで、どのフィードがorganizationスコープであるかをフィード ピッカーで確認することもできます。
レポート
あなたが求めてきたすべてのものを含むスプリントバーンダウンウィジェット
新しいスプリント バーンダウン ウィジェットでは、ストーリー ポイント、タスクの数、またはユーザー設定フィールドの合計による書き込みをサポートしています。 フィーチャーやエピックのスプリント バーンダウンを作成することもできます。 ウィジェットには、平均バーンダウン、達成率、スコープの増加が表示されます。 チームを構成して、同じダッシュボードに複数のチームのスプリント バーンダウンを表示できます。 この優れた情報をすべて表示して、ダッシュボードで最大 10 x 10 のサイズを変更できます。
試すには、ウィジェット カタログから追加するか、既存のスプリント バーンダウン ウィジェットの構成を編集し、[ 今すぐ新しいバージョンを試す ] ボックスをオンにします。
Note
新しいウィジェットでは Analytics が使用されます。 Analytics にアクセスできない場合に備えて、従来のスプリント バーンダウンを維持しました。
Wiki
Wiki ページを編集するための同期スクロール
編集ウィンドウとプレビュー ウィンドウ間の同期スクロールにより、Wiki ページの編集が簡単になりました。 一方の側をスクロールすると、もう一方の側が自動的にスクロールされ、対応するセクションがマップされます。 トグル ボタンを使用して同期スクロールを無効にすることができます。
Note
同期スクロール トグルの状態は、ユーザーごとおよびorganizationごとに保存されます。
Wiki ページのページ アクセス数
Wiki ページのページ アクセスに関する分析情報を取得できるようになりました。 REST API を使用すると、過去 30 日間のページ アクセス情報にアクセスできます。 このデータを使用して、Wiki ページのレポートを作成できます。 さらに、このデータをデータ ソースに格納し、ダッシュボードを作成して、 トップ n の最も閲覧数の多いページなどの特定の分析情報を取得できます。
また、すべてのページで過去 30 日間の集計されたページ訪問数も表示されます。
Note
ページ 訪問は、15 分間隔で特定のユーザーによってページ ビューとして定義されます。
次の手順
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に進み、見てみましょう。
フィードバックの提供方法
これらの機能についてご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
Jeff Beehler
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示