Azure DevOpsのSprint 155 Updateでは、重要なチームメトリクスを追跡しやすくするために新しいAzure Boards Reportを導入しています。ボード、バックログ、およびスプリントの各ハブのAnalyticsタブに新しいレポートが表示されます。これらのレポートは完全にインタラクティブであり、あなたがあなたのニーズを満たすための調整が可能になっています。
さらに、Slack用の新しいAzure Boardsアプリの発表ができてとてもうれしいです。アプリでは、作業項目のアクティビティを監視し、Slackチャンネルから作業項目を作成できます。
詳細については、以下の機能リストをご覧ください。
General:
Azure Boards:
- 新しい3つのAzure Boardsレポートでチームの状態とインサイトを観測する
- Slack用Azure Boardsアプリケーション
- タスクボードの列をカスタマイズ
- バックログに紐づく完了した作業項目の表示非表示を切り替えられるようになりました
- ボード、バックログ、クエリ、スプリントをインスタント検索ボックスから検索する
- 作業項目につけるタグから直近で使用されたものが表示されるようになりました
Azure Repos:
- コード検索用フィルターの強化
- pull requestでのコードカバレッジメトリクスとブランチポリーのサポート
- pull requestからのコメント通知のフィルタリングが可能になりました
- pull requestコメントでのサービスフックをサポート
Azure Artifacts:
Azure Pipelines:
Multi-stage YAML pipelines
- 複数ステージYAMLパイプラインでの承認をサポート
- パイプライン変数をYAMLエディターで管理できるようになりました
- YAMLパイプラインでの新しい定義済みの値
- 複数ステージYAMLパイプラインでのステージキャンセルのサポート
- ジョブごとに正しいプールの情報を表示する
- 複数ステージYAMLパイプラインで作業項目の関連付けをサポート
- 新しいブランチ作成時のCIトリガー
- Pipelineの変数グループと変数を管理するコマンドのサポート
- Pipelineのキャッシュ(パブリックプレビュー)
- PRブランチ用のパイプラインを実行する
- 最初のパイプライン実行をスキップする
Hosted VMs
Kubernetes
Test
Azure experiences
Integrations
GitHubのIDでサインインしたときに、GitHubのアカウントをAzure DevOpsに共同編集者として招待できるようになりました。他のGitHubユーザーをProjectホームページとOrganization settingsのユーザーページから検索して招待できます。
この機能は、Organization settingsのPolicyにある設定を使って既存の組織に対して有効にする必要があります。ただし、GitHub IDによって作成された組織ではデフォルトでオンになっています。
注意事項
この機能は非GitHubユーザーではポリシーを有効にするまで使用できません。
チームメンバーの招待の詳細については、こちらのドキュメントを参照してください。GitHubを使用してAzure DevOpsへ接続する際に問題がある場合は、GitHubユーザーの認証と招待のトラブルシューティングに関するFAQを参照してください。
見えないものの修正は不可能です。したがって、あなたは彼らの業務プロセスの状態と正常性を注意深く見たいという要求があります。これらのレポートにより、Azure Boardsで最小限の労力で重要な指標を簡単に追跡できるようになりました。
3つの新しい対話型レポートは、Burndown(バーンダウン)、Cumulative Flow Diagram(累積フロー図(CFD))、およびVelocity(ベロシティ)です。新しいanalyticsタブでレポートを確認できます。
スプリントバーンダウン、作業のフロー、チームのベロシティなどの指標により、チームの進捗状況を把握し、次のような質問に答えられます。
- このスプリントに残っている作業量はどのくらいですか？我々はそれを完成するためのスケジュールがオンタイムですか？
- 開発プロセスにおいて、もっとも時間をかけている段階はどこでしょうか？それについて何かできるでしょうか？
- 前回のイテレーションの経験に基づき、次回のスプリントにはどのくらいの作業を計画する必要がありますか？
注意事項
以前、ヘッダーに表示されていたグラフは、これらの拡張レポートに置き換えられました。
新しいレポートは完全にインタラクティブであり、あなたのニーズに合わせて調整ができます。各ハブのAnalytics tabの下に新しいレポートがあります。
- バーンダウンチャートはSprintsハブの下にあります。
- CFDレポートとVelocityレポートは、関連するカードをクリックしてBoardsとBacklogsのAnalytics tabタブからアクセスできます。
新しいレポートを使用すると、チームに関するより詳細な管理と情報の入手が可能になります。ここではいくつかの例を紹介します。
- Sprint BurndownとVelocityレポートは、作業項目の数または残りの作業の合計を使用するように設定できます。
- プロジェクトの日付に影響を与えずにスプリントバーンダウンの期間を調整できます。そのため、チームが通常各スプリント計画の初日を過ごすのであれば、それを反映させるためにチャートを一致させられます。
- Burndownチャートは今週末がいつになるか、という情報を透かし状態で表示します。
- CFDレポートを使用すると、Designのようなボードコラムを削除して、チームが管理しているフローにより焦点を絞れます。
これは、過去30日間のStoriesバックログのフローを示すCFDレポートの例です。
Velocityチャートは、すべてのバックログレベルで追跡できるようになりました。たとえば、以前のバージョンのチャートではRequirementsのみがサポートされていましたが、今回の更新でFeaturesとEpicの両方を追加できるようになりました。これは、直近の6回のイテレーションにおけるFeaturesバックログのベロシティレポートの例です。
Slack用の新しいAzure Boardsアプリを発表できてとても喜ばしいです。このアプリを使えば、作業項目のアクティビティを監視し、Slackチャンネルから作業項目を作成できます。
アプリでは、作成、作業項目の更新などのイベント購読を設定および管理し、Slackチャンネルでこれらのイベントの通知を受け取ることができます。Slackチャンネルの会話は、作業項目を作成するために使用可能です。作業項目が割り当てられたときにも、個人あてに通知を受け取ります。さらに、作業項目のURLのプレビューでディスカッションを開始できます。
Azure Boards用アプリケーションはこちらからインストールしてください。
タスクボードの列をカスタマイズ可能にするオプションの追加をお知らせいたします。この更新で、列の追加、削除、名前変更、および順序変更が可能になります。
タスクボードの列を設定するには、Column Optionsに進みます。
この機能はDeveloper Communityでの提案に基づいて優先順位がつけられました。
多くの場合、バックログを調整するときには、完了していないアイテムのみを表示します。今回の強化で、バックログで完了した子アイテムの表示と非表示を切り替えられるようになりました。
トグルがオンになっている場合は、すべての子項目が完成状態になります。トグルがオフの場合、完了状態のすべての子項目はバックログから隠されます。
今回の強化で、Azure Boardsの検索ボックスをアクティブにすると、検索ボックスから最近訪れたボード、バックログ、クエリ、スプリントに簡単にアクセスできます。
さらに、検索ボックスにボード名を入力して、プロジェクト全体のボード、バックログ、クエリ、およびスプリントの検索ができます。今、ワンクリックするだけで、最も重要なボードの参照が可能になっています。
作業項目をタグ付けするとき、オートコンプリートオプションは、最近使用したタグを最大5つまで表示するようになりました。今回の強化で、簡単に作業項目に正しい情報を追加できます。
以前のコード検索では、**comment:やdef:**など、39個のコード検索フィルターがサポートされていました。データから使用されていないフィルターが多数あるとわかったため、いくつかのフィルターを削除し、いくつかのフィルターを統合しています。今回の更新で、フィルターの数を19に減らしました。これは、コード検索クエリをより効率的にし、インタフェースの乱雑さを減らすために役立ちます。
たとえば、func:がmethod:へマッピングされるようになりました。つまり、func:AccountAdminを検索すると、結果はmethod:AccountAdminにマッピングされます。同様に、**macrodef:とmacroref:はmacro:**にマップされます。一方、**union:やorg:**などのフィルターは、使用頻度が少ないために非推奨となりました。
pull request(PR)ビュー内で、変更に対するコードカバレッジメトリックスを確認できるようになりました。この強化により、自動テストによって変更を適切にテストしたことの確認ができます。カバレッジの状態はPR概要にコメントとして表示されます。ファイル差分ビューで変更されたすべてのコード行のカバレッジ情報の詳細を表示ができます。
さらに、リポジトリ所有者はコードカバレッジポリシーを設定し、テストされていない大規模な変更がブランチにマージされるのを防ぐことができます。必要なカバレッジしきい値は、リポジトリのルートでチェックインされているazurepipelines-coverage.yml設定ファイルで定義できます。また、Azure Reposの追加のサービス機能に対する既存のブランチ構成ポリシーを使用してカバレッジポリシーを定義できます。
通知のためにpull request内のコメントから、多くのノイズを生み出すことがあります。あなたが購読するコメント通知をコメントの歴史、コメント投稿者、削除コメント、ユーザーのメンション、pull requestの作者、ターゲットブランチ、スレッド参加者といった単位でフィルタリングできるカスタム設定を追加しました。これらの通知サブスクリプションを作成するには、右上隅にあるユーザーアイコンをクリックしてUser settingsに移動します。
リポジトリとターゲットブランチに基づいて、pull request内のコメント用のサービスフックを作成できるようになりました。
パッケージを作成してパブリックフィードへ保存できるようになりました。パブリックフィードに格納されているパッケージは、組織内にあるかどうかにかかわらず、あるいはAzure DevOps組織にログインしているかどうかにかかわらず、認証なしでインターネット上のすべての人が利用できます。私たちのフィードに関するドキュメントでパブリックフィードについてもっと学ぶか、またはパッケージをパブリックで共有するためチュートリアルを使ってためしてみてください。
kustomize(Kubernetes sig-cliの一部)を使用すると、テンプレートを含まないそのままのYAMLファイルを複数の目的に合わせてカスタマイズでき、元のYAMLは変更されません。kustomizeのオプションがKubernetesManifestタスクのベイク処理アクション内に追加されたため、任意のフォルダに格納されたkustomization.yamlファイルを使用して、KubernetesManifestタスクのデプロイアクションで使用されるマニフェストファイルを生成できます。
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kustomize
kustomizationPath: folderContainingKustomizationFile
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)komposeはDocker ComposeファイルをKubernetesリソースに変換します。
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kompose
dockerComposeFile: docker-compose.yaml
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)以前のHelmDeployタスクはデプロイメントにクラスターユーザーの資格情報を使用していました。このため、インタラクティブなログインプロンプトが表示され、Azure Active DirectoryベースのRBAC対応クラスターのパイプラインが失敗しました。この問題に対処するため、クラスターユーザーの資格情報の代わりにクラスター管理者の資格情報を使用できるようにするチェックボックスを追加しました。
YAMLエディターでパイプライン変数を管理するためのエクスペリエンス更新しました。今後、YAMLパイプラインの変数を追加または更新するために、従来のエディターに移動する必要はありません。
- Environment.Id - 環境のID
- Environment.Name - デプロイジョブで対象となる環境の名前
- Environment.ResourceId - デプロイジョブの対象となる環境のリソースID
- Environment.ResourceName - デプロイジョブで対象となる環境のリソース名
変数を使用すると、重要なデータをパイプラインのさまざまな部分に取り込むことができます。今回の更新では、デプロイメントジョブにいくつかの定義済み変数を追加しました。これらの変数はシステムによって自動的に設定され、特定の展開ジョブに範囲が設定されており、読み取り専用となっています。
現在、従来のビルドを使った場合、作業項目と自動的にリンクされます。しかし、これはYAMLパイプラインでは不可能でした。今回の更新で、このギャップに対処しました。指定されたブランチのコードを使用してパイプラインを正常に実行すると、Azure Pipelinesはその実行をすべての作業項目(そのコード内のコミットを通じて推測される)に自動的に関連付けます。作業項目を開くと、その作業項目のコードが作成された実行を確認できます。設定するには、パイプラインの設定パネルを使用します。
マルチステージYAMLパイプラインを実行しているときに、進行中のステージの実行をキャンセルできるようになりました。これは、ステージが失敗するとわかっている場合、または開始したい別の実行がある場合に役立ちます。この機能は、将来失敗したステージの再試行をサポートするための前提条件でもあります。
私達は複数ステージYAMLパイプラインを改善し続けています、今回の更新で、複数ステージYAMLパイプラインに手動承認を追加します。インフラストラクチャの所有者は、パイプラインの段階で展開される前に、環境を保護して手動で承認を求められるようになりました。インフラストラクチャ(環境)所有者とアプリケーション(パイプライン)所有者の間で役割を完全に分離することで、特定のパイプラインでの配置のための手動サインオフを確実にし、環境へのすべての配置にわたって同じチェックを適用することで集中管理できます。
ステージの開始時にdevにデプロイするパイプラインの実行が、承認待ちで停止ています。
Azure Pipelinesが提供するVMイメージを更新しました。最新リリースの詳細については、こちらを参照してください。このアップデートの一環として、次の変更が加えられました。
-
VS2017とVS2019:
- Azul Java 7を追加
- キャッシュされたDocker imagesをホストのカーネルバージョンと一致させた
- Az Powershell Module v2.3.2を追加
- Mercurialをv5.0.0に変更
- Pythonのバージョンを2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4に変更
- Portable Class Library (VS 2019のみ)を追加
- Rustのデフォルトパスと環境変数を変更
-
Ubuntu 16.04用:
- helmが常時最新をpullするように変更(v2.14.0のままにできなくなりました)
- 著名ななDockerコンテナーを追加
- Pythonのバージョンを2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4に変更
- Rustのデフォルトパスと環境変数を変更
-
すべてのイメージの環境変数に
ImageVersionを付与。
特定のイメージで使用可能なツールの完全なリストについては、Settings > Agent pools > Detailesに移動してください。
今回の更新では、DevOps Projectsの仮想マシン(VM)ワークフローが拡張され、場所ごとのクォータ制限に準拠しているVMのみが含まれるようになりました。以前は、名前と製品でVMを選択する必要がありました。月当たりのコスト、RAM、データディスクなどのVM製品に関する詳細を含むオンデマンドビューが表示されるようになります。必要な仮想マシンを簡単に選択できるようになります。
前のスプリントで、Azure Pipelinesという新しいホストプールを展開して、他のすべてのホストプール(Hosted、Hosted VS2017、Hosted Ubuntu 1604、Hosted Windows 2019とVS2019、Hosted macOS、Hosted macOS)を置き換えることをお伝えました。この変更はこのリリースで実装される予定です。
複数のホストプールを持つと、ときどき混乱することがあります。並列ビルドが行われているープルの正確な状況はわかりません。たとえば、10の並列ジョブの同時実行性がある場合、各ホストプールに10の仮想エージェントが表示されますが、これは正確ではありません。すべてのアイドル状態のエージェントで特定のホストプール(Hosted VS2017など)でジョブが待機している場合、他のホストプール(Hosted Ubuntu 1604など)で並行性が消費される可能性があることに気付かずにAzure Pipelinesサービスで問題が発生しているように見えてしまいます。
この変更により、単一のホストプールが表示され、そのプールで実行されているジョブの数が正確にわかります。次の数スプリントでこの変更を発表する予定です。古いホストプールから新しい統合プールの適切なイメージにジョブが自動的にリダイレクトされるため、パイプラインに変更を加える必要はありません。
以前は、マトリックスを使用してジョブを拡張したり、変数を使用してプールを識別したりすると、ログページに正しいプール情報を表示できませんでした。このアップデートでは、特定のジョブについて誤ったプール情報が表示される問題を修正しました。
テストの失敗はテスト中の変更に関連しない場合があるため、フレークテスト(訳注:Flaky Testとはネットワーク状態などに依存する、必ずテストコードの意図通りの結果が出ないテストのこと)は開発者の生産性に影響を与える可能性があります。この問題は出荷されたコードの品質にも影響を与えます。これが、フレークテスト管理に対する製品内サポートを追加した理由です。この機能は、検出、レポート作成、および解決により、エンドツーエンドのライフサイクルをサポートします。フレークテスト管理はシステムとカスタム検出をサポートします。
システム検出はVSTestタスク再実行機能を介して利用できます。フレークテストは、ソースコードや実行環境に変更がない場合でも、合格や不合格などのさまざまな結果を提供するテストです。同じブランチに対するそれ以降のすべてのテストの実行も、解決されてマークが付けられなくなるまでフレークのマークが付けられます。当社のAPIを使用してカスタム検出メカニズムをプラグインすることもできます。テストが不安定であると識別されたら、パイプラインのコンテキスト内テストレポートで詳細を取得できます。フレークテストがパイプラインの障害に影響を与えるかどうかを判断できます。デフォルトでは、フレークテスト情報が追加のメタデータとして利用可能です。
テストサマリー付きのレポートの例を次に示します。
不安定なテスト管理の詳細ドキュメントはこちらをみてください。
Azure PortalのWebAppのデプロイセンターを改善し、複数のアーティファクトを含むパイプラインをサポートしました。今回の更新で、Azure Pipelinesの重要ではないアーティファクトがWebアプリケーションに展開された場合、Azure Portalから関連性の高い詳細情報を入手できます。Azureポータルからレポジトリに直接移動するためのデプロイ済みレポジトリへのディープリンクもあります。リポジトリはAzure ReposまたはGitHubでホストできます。
新しいブランチが作成されたとき、およびそのブランチに変更がないときにCIビルドをトリガーしないようにすることは、長い間実装されず、保留されていました。次の例を見てください。
- Webインターフェイスを使用して、既存のブランチに基づいて新しいブランチを作成します。ブランチフィルターが新しいブランチの名前と一致する場合、これはすぐに新しいCIビルドを起動します。新しいブランチの内容は既存のブランチと同じなので、これは望ましくありません。
- appとdocsの2つのフォルダーを持つリポジトリがあります。"app"に一致するようにCIのパスフィルターを設定します。言い換えれば、変更がドキュメントにプッシュされた場合、新しいビルドを作成したくはありません。ローカルに新しいブランチを作成し、ドキュメントに変更を加えてから、そのブランチをサーバーにプッシュします。私たちは新しいCIの構築を始めていました。docsフォルダーを変更したことを明示的に依頼したので、これは望ましくありません。しかしながら、新しいブランチイベントの処理方法が原因で、appフォルダーにも変更が加えられたように見えます。
現在、これらの問題に対処するため、新しいブランチのCIを処理するより良い方法があります。新しいブランチを公開すると、そのブランチで新しいコミットを明示的に探し、それらがパスフィルターに一致するかどうかを確認します。
Terraformは、インフラストラクチャを安全かつ効率的に開発、変更、およびバージョン管理するためのオープンソースツールです。Terraformは、APIを宣言型の設定ファイルに体系化して、高レベルの設定言語を使用してインフラストラクチャを定義およびプロビジョニングできるようにします。Terraform拡張機能を使用すると、Azure、Amazon Web Services(AWS)、およびGoogle Cloud Platform(GCP)など、すべての主要インフラストラクチャプロバイダーにわたってリソースを作成できます。
Terraformエクステンションの詳細については、こちらのドキュメントを参照してください。
Google Analyticsの実験的フレームワークを使用すると、Webサイトまたはアプリに対するほぼすべての変更またはバリエーションをテストして、特定の目的への影響を測定できます。たとえば、ユーザーに完了させるアクティビティ(購入、ニュースレターへの登録など)や改善したい指標(収益、セッション期間、直帰率など)があるとします。これらのアクティビティによって、機能のパフォーマンスに対する直接的な影響に基づいて、実装する価値のある変更を特定できます。
Azure DevOps用のGoogle Analyticsの実験用拡張機能では、ビルドおよびリリースパイプラインに実験手順が追加されているため、Azure PipelinesからすべてのDevOpsの利点を得ながら実験を継続的に管理することで、繰り返しの繰り返し、学習、展開が可能です。
実験を開始または一時停止する方法、バリアントなどにトラフィックを割り当てる方法の詳細については、Azure DevOpsドキュメントのGoogle Analytics 実験用拡張機能を参照してください。
パイプラインキャッシングを使用すると、パッケージの復元や依存関係のコンパイルなど、長時間実行される操作の結果を保存し、パイプラインの次の実行中に復元できます。この機能のおかげでビルドが高速化されます。
詳細については、ここに完全な発表があるブログ投稿を参照してください。
パイプライン変数と変数グループを手動で設定する必要があるため、YAMLベースのパイプラインをあるプロジェクトから別のプロジェクトへの移植は難しい場合があります。ただし、パイプライン変数グループと変数管理コマンドを使用すると、パイプライン変数と変数グループのセットアップと管理をスクリプト化してバージョン管理できるようになるため、1つのパイプラインを構築して、別のプロジェクトへパイプラインを移動およびセットアップするためのスクリプトを簡単に共有できるようになりました。
PRを作成するとき、変更がターゲットブランチで実行されているパイプラインを壊す可能性があるかどうかを検証するのは難しい場合があります。ただし、パイプラインの実行をトリガーしたり、PRブランチのビルドをキューに入れたりする機能を使用すると、ターゲットパイプラインに対して実行することで、進行中の変更を検証および視覚化できます。詳細については、az pipeline runおよびaz pipeline build queueコマンドのドキュメントを参照してください。
パイプラインを作成するときに、YAMLファイルを作成してコミットし、パイプラインの実行をトリガーしたくない場合があります。これは、さまざまな理由でインフラストラクチャの準備ができていないか、変数/変数グループを作成および更新する必要があるため、パイプライン実行に失敗してしまう可能性があるためです。Azure DevOps CLIでは、-skip-first-runパラメーターを含めることで、パイプラインの作成時に最初の自動パイプライン実行をスキップできるようになりました。詳細については、az pipeline create command documentationを参照してください。
サービスエンドポイントCLIコマンドは、azure rmおよびGitHubサービスエンドポイントのセットアップと管理のみをサポートしていました。このリリースでは、サービスエンドポイントコマンドを使用すると、あらかじめ構成されたファイル経由でサービスエンドポイントを作成でき、最適化されたコマンドを提供します。az devops service-endpoint githubおよび、az devops service-endpoint azurermは、サービスエンドポイントを作成するためのファーストクラスサポートを提供します。これらのタイプの。 詳細については、コマンドのドキュメントを参照してください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Sam Guckenheimer