Slack 用の新しい分析レポートと Azure Boards アプリ - Sprint 155 Update

  • [アーティクル]

Azure DevOps の Sprint 155 Updateでは、新しい Azure Boards レポートが導入され、重要なチーム メトリックを追跡しやすくなりました。 [ボード]、[バックログ]、[スプリント] ハブで、[分析] タブの下に新しいレポートが表示されます。 これらのレポートは、完全にインタラクティブで、ニーズに合わせて調整できます。

さらに、新しい Slack 用の Azure Boards アプリを発表いたします。 このアプリにより、ご使用の Slack チャネルから作業項目アクティビティを監視したり、作業項目を作成したりできるようになります。

詳細については、以下の 機能 の一覧を参照してください。

Azure DevOps の新機能

機能

全般:

Azure Boards:

Azure Repos:

Azure Artifacts:

Azure Pipelines:

   マルチステージの YAML パイプライン

  ホステッド VM

Kubernetes

テスト

  Azure エクスペリエンス

統合

全般

GitHub コラボレーターを Azure DevOps に招待する

GitHub ID でサインインするときに、GitHub から Azure DevOps にコラボレーターを招待できるようになりました。 他の GitHub ユーザーは、Project ホームページと組織設定の [ユーザー] ページから検索して招待できます。

Invite GitHub collaborators into Azure DevOps.

この機能は、[組織の設定] の [ポリシー] の下の設定を使用して、既存の組織で有効にする必要があります。 ただし、GitHub ID によって作成された組織では、既定で有効になっています。

Enable for existing organizations.

Note

この機能は、ポリシーが有効になっている場合でも、GitHub 以外のユーザーでは使用できません。

チーム メンバーの招待の詳細については、こちらのドキュメントを参照してください。 GitHub を使用した Azure DevOps への接続で問題が発生した場合は、トラブルシューティングの 認証と GitHub ユーザーの招待に関する FAQ を参照してください。

Azure Boards

3 つの新しい Azure Boards レポートを使ってチームの正常性に関する分析情報を得る

見えないものを修正することはできません。 そのため、作業プロセスの状態と正常性を注意深く監視する必要があります。 これらのレポートを使用すると、Azure Boards での最小限の労力で重要なメトリックを簡単に追跡できます。

3 つの新しい対話型レポートは、 バーンダウン、 累積フロー ダイアグラム (CFD) と 速度です。 新しい分析タブにレポートが表示されます。

スプリント バーンダウン、作業の流れ、チームの速度などのメトリックにより、チームの進行状況を可視化し、次のような質問に答えるのに役立ちます。

  • このスプリントにはどのくらいの作業が残っていますか? 私たちはそれを完了するために軌道に乗っていますか?
  • 開発プロセスで最も時間がかかっている手順は何ですか? 私たちはそれについて何かを行うことができますか?
  • 以前のイテレーションに基づいて、次のスプリントに対してどのくらいの作業を計画する必要がありますか?

Note

ヘッダーに表示されていたグラフは、これらの拡張レポートに置き換えられました。

新しいレポートは完全に対話型であり、ニーズに合わせて調整できます。 新しいレポートは、各ハブの [分析] タブ にあります。

  • バーンダウン チャートは、スプリント ハブの下にあります。

    Analytics tab in Sprint hub.

  • CFD および速度レポートには、関連するカードをクリックして、[ボードとバックログ] の [分析] タブからアクセスできます。

    CFD and velocity reports in boards.

新しいレポートを使用すると、チームに関するより詳細な制御と情報を得ることができます。 次に例をいくつか示します。

  • スプリント バーンダウンレポートとベロシティレポートは、作業項目の数または再メイン作業の合計を使用するように設定できます。
  • プロジェクトの日付に影響を与えずに、スプリントバーンダウンの期間を調整できます。 そのため、チームが通常、各スプリント計画の最初の日を費やしている場合は、グラフを照合して反映できるようになりました。
  • バーンダウン グラフに、週末を示す透かしが表示されるようになりました。
  • CFD レポートを使用すると、デザインなどのボード列を削除して、チームが制御するフローに重点を置くことができます。

ここでは、過去 30 日間のストーリー バックログのフローを示す CFD レポートの例を示します。

Example of the CFD report.

速度グラフをすべてのバックログ レベルで追跡できるようになりました。 たとえば、前のグラフが要件のみをサポートする前に、機能とエピックの両方を追加できるようになりました。 フィーチャー バックログの最後の 6 回のイテレーションの速度レポートの例を次に示します。

Example of a velocity report.

Slack 用 Azure Boards アプリ

Slack 用の新しい Azure Boards アプリをお知らせします。 このアプリを使用すると、作業項目のアクティビティを監視し、Slack チャネルから作業項目を作成できます。

このアプリを使用すると、作成、作業項目の更新などのイベント サブスクリプションを設定および管理したり、Slack チャネルでこれらのイベントの通知を取得したりできます。 Slack チャネルの会話を使用して、作業項目を作成できます。 また、作業項目が割り当てられると、個人の通知も受け取ります。 さらに、作業項目の URL のプレビューでは、ディスカッションを開始できます。

Azure Boards app for Slack.

Azure Boards アプリをインストールするには、ここをクリックします。

タスクボードの列をカスタマイズする

タスクボードの列をカスタマイズできるオプションが追加されたことをお知らせします。 これで、列の追加、削除、名前の変更、並べ替えができるようになりました。

タスクボードで列を構成するには、[列オプション] に 移動します。

Customizing columns on the taskboard.

この機能は、開発者コミュニティからの提案に基づいて優先されました。

バックログで、完了した子作業項目の表示と非表示を切り替える

多くの場合、バックログを絞り込むと、完了していない項目のみが表示されます。 これで、完了した子項目をバックログに表示または非表示にすることができます。

トグルがオンの場合は、完了状態のすべての子項目が表示されます。 トグルがオフの場合、完了状態のすべての子項目はバックログから非表示になります。

Show or hide child items on the backlog.

Azure Boards の検索ボックスをアクティブにすることで、最近アクセスしたボード、バックログ、クエリ、スプリントに検索ボックスから簡単にアクセスできるようになりました。

Activate the instant search box.

さらに、検索ボックスにボード名を入力して、プロジェクト全体でボード、バックログ、クエリ、スプリントを検索できます。 今、あなたに最も重要なボードは、クリックするだけです。

Search for a board name.

作業項目をタグ付けするときに最近使用したタグが表示される

作業項目にタグを付けると、オートコンプリート オプションに、最近使用したタグのうち最大 5 個が表示されるようになります。 これにより、作業項目に適切な情報を簡単に追加できます。

Most recent used tags displayed when tagging a work item.

Azure Repos

改善されたコード検索のフィルター オプション

以前は、コード検索では、コメント: や def: などの 39 個のコード検索フィルターがサポートされました。 データは、多くのフィルターが使用されていないことを示唆しているため、いくつかのフィルターを削除し、他のフィルターをマージしています。 この更新プログラムでは、フィルターの数を 19 に減らしました。 これは、コード検索クエリをより効率的にし、インターフェイスの煩雑さを減らすことで役立ちます。

Code search filter options.

たとえば、func: はメソッドにマップされます。つまり、func:Account管理 を検索すると、結果は method:Account管理 にマップされます。 同様に、macrodef: と macroref: はマクロにマップされます。 一方、union: や org: などのフィルターは、使用がないため非推奨とされています。

pull request のコード カバレッジ メトリックおよびブランチ ポリシー

プル要求 (PR) ビュー内の変更に関するコード カバレッジ メトリックを確認できるようになりました。 これにより、自動テストを通じて変更を適切にテストできます。 カバレッジの状態は、PR の概要にコメントとして表示されます。 ファイルの差分ビューで変更されたすべてのコード行のカバレッジ情報の詳細を表示できます。

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

さらに、リポジトリの所有者はコード カバレッジ ポリシーを設定し、テストされていない大規模な変更がブランチにマージされるのを防ぐことができます。 必要なカバレッジのしきい値は、リポジトリのルートにチェック設定ファイルで定義azurepipelines-coverage.ymlできます。また、カバレッジ ポリシーは、Azure Repos の追加サービス機能用にブランチ ポリシーを構成する既存の構成を使用して定義できます。

Define coverage thresholds.

pull request からのコメント通知のフィルター処理

プル要求のコメントでは、多くの場合、通知が原因で大量のノイズが発生する可能性があります。 コメントの有効期間、コメント 作成者、削除されたコメント、メンションユーザー、pull request 作成者、ターゲット ブランチ、スレッド参加者によってサブスクライブするコメント通知をフィルター処理できるカスタム サブスクリプションが追加されました。 これらの通知サブスクリプションを作成するには、右上隅にあるユーザー アイコンをクリックし、[ユーザー設定] に移動します。

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

pull request コメントのサービス フック

リポジトリとターゲット ブランチに基づいて、pull request にコメントのサービス フックを作成できるようになりました。

Service hooks for pull request comments.

Azure Artifacts

パッケージをパブリック フィードでパブリックに共有する (プレビュー)

これで、パブリック フィード内にパッケージを作成して格納できるようになりました。 パブリック フィード内に格納されているパッケージは、組織内にあるかどうかにかかわらず、Azure DevOps 組織にログインしている場合でも、認証なしでインターネット上のすべてのユーザーが利用できます。 フィードのドキュメントでパブリック フィードの詳細を確認するか、パッケージをパブリックに共有するためのチュートリアルに進んでください。

Share your packages with public feeds.

Azure Pipelines

Kubernetes マニフェスト タスクの bake オプションとしての kustomize および kompose

kustomize (Kubernetes sig-cli の一部) を使用すると、未加工のテンプレートフリーの YAML ファイルを複数の目的でカスタマイズでき、元の YAML はそのまま残すことができます。 kustomization.yaml ファイルを含むフォルダーを KubernetesManifest タスクの配置アクションで使用するマニフェスト ファイルの生成に使用できるように、kubernetesManifest タスクのベイク アクションの下に kustomize のオプションが追加されました。

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 タスクでのクラスター管理者資格情報のサポート

以前は、HelmDeploy タスクはデプロイにクラスター ユーザー資格情報を使用しました。 その結果、Azure Active Directory ベースの RBAC が有効なクラスターの対話型ログイン プロンプトと失敗したパイプラインが発生しました。 この問題に対処するために、クラスター ユーザー資格情報ではなくクラスター管理者の資格情報を使用できるチェックボックスが追加されました。

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

YAML エディターでパイプライン変数を管理する

YAML エディターでパイプライン変数を管理するためのエクスペリエンスを更新しました。 YAML パイプラインで変数を追加または更新するために、クラシック エディターに移動する必要がなくなりました。

Manage pipeline variables in YAML editor.

YAML パイプラインの新しい事前定義済み変数

変数を使うと、パイプラインのさまざまな部分に重要なデータを簡単に取り込むことができます。 この更新プログラムでは、いくつかの定義済みの変数をデプロイ ジョブに追加しました。 これらの変数は、システムによって自動的に設定され、特定のデプロイ ジョブにスコープが設定され、読み取り専用です。

  • Environment.Id - 環境の ID。
  • Environment.Name - デプロイ ジョブの対象となる環境の名前。
  • Environment.ResourceId - デプロイ ジョブの対象となる環境内のリソースの ID。
  • Environment.ResourceName - デプロイ ジョブの対象となる環境内のリソースの名前。

現時点では、作業項目をクラシック ビルドと自動的にリンクできます。 ただし、これは YAML パイプラインでは不可能でした。 この更新プログラムでは、このギャップに対処しました。 指定したブランチのコードを使用してパイプラインを正常に実行すると、Azure Pipelines は実行をすべての作業項目に自動的に関連付けます (そのコード内のコミットによって推論されます)。 作業項目を開くと、その作業項目のコードがビルドされた実行を確認できます。 これを構成するには、パイプラインの設定パネルを使用します。

マルチステージの YAML パイプライン実行のキャンセル ステージ

マルチステージ YAML パイプラインを実行するときに、ステージの実行中にステージの実行を取り消すようになりました。 これは、ステージが失敗することがわかっている場合や、開始する別の実行がある場合に役立ちます。 この機能は、将来的に失敗したステージの再試行をサポートするための前提条件でもあります。

マルチステージの YAML パイプラインでの承認

マルチステージの YAML パイプラインを引き続き改善し、これらのパイプラインに手動承認を追加できるようになりました。 インフラストラクチャの所有者は、環境を保護し、パイプラインのステージがデプロイされる前に手動承認を求めることができます。 インフラストラクチャ (環境) とアプリケーション (パイプライン) の所有者の間でロールを完全に分離することで、特定のパイプラインでのデプロイに対する手動サインオフを確実に行い、すべてのデプロイで同じチェックを環境に適用する際に中央制御できるようになります。

Approvals in multi-stage YAML pipelines.

開発にデプロイするパイプラインの実行は、ステージの開始時に承認のために停止します。

Pipeline runs deploying to dev will stop for approval.

ホストされたパイプライン イメージの更新

Azure Pipelines でホストされている VM イメージのいくつかに更新を加えました。 最新リリース の詳細については、こちらをご覧ください。 この更新プログラムの一部として、次の変更が追加されました。

  • VS2017 および VS2019 の場合:

  • Ubuntu 16.04 の場合:

    • 常に最新の Helm をプルするように更新されました (v2.14.0 ではピン留めされなくなりました)
    • いくつかの一般的な Docker コンテナーを 追加しました
    • Python をバージョン 2.7.16、3.4.10、3.5.7、3.6.9、3.7.4 に更新しました
    • Rust の既定のパスと環境変数の変更

  • すべてのイメージに対して、イメージの ImageVersion バージョンの環境変数を追加しました

特定のイメージで使用できるツールの完全な一覧については、「設定 エージェント プール>の詳細」を参照してください。 >

仮想マシン用 DevOps プロジェクトの機能強化

この更新プログラムでは、DevOps Projects 仮想マシン (VM) ワークフローを強化し、場所ごとのクォータ制限に準拠していない VM を含めます。 以前は、名前とオファリングで VM を選択する必要がありました。 これで、コスト/月、RAM、データ ディスクなど、VM オファリングの詳細を含むオンデマンド ビューが表示されます。これにより、必要な仮想マシンを簡単に選択できます。

Enhancements to DevOps Project for virtual machine.

単一のホストされたプール

最後のスプリントでは、ホストされている、ホストされている VS2017、ホストされた Ubuntu 1604、ホストされた Windows 2019 と VS2019、ホストされた macOS、およびホストされた macOS High Sierra の他のすべてのホストされたプールを置き換えるために、Azure Pipelines と呼ばれる新しいホストされたプールをロールアウトすることを伝えました。 この変更は、このリリースで実装されます。

ホストされているプールが複数存在すると、混乱を招く場合があります。 コンカレンシーが使用されている場所を正確に把握することはできません。 たとえば、10 個の並列ジョブのコンカレンシーがある場合、ホストされている各プールに 10 個の仮想エージェントが表示されます。これは正確ではありません。 ジョブが、すべてのアイドル 状態のエージェントで特定のホストされたプール (ホストされた VS2017 など) で待機している場合、他のホストされているプール (ホストされた Ubuntu 1604 など) でコンカレンシーが使用されている可能性があることを認識せずに、Azure Pipelines サービスが壊れていると考える場合があります。

この変更により、1 つのホストされたプールが表示され、そのプールで実行されているジョブの数を正確に把握できます。 この変更は、次のいくつかのスプリントにロールアウトする予定です。 古いホストされているプールから新しい統合プール内の適切なイメージにジョブが自動的にリダイレクトされるため、パイプラインに変更を加える必要はありません。

各ジョブの正しいプール情報を表示する

以前は、マトリックスを使用してジョブを展開したり、変数を使用してプールを識別したりすると、ログ ページに正しいプール情報を表示する際に問題が発生していました。 この更新プログラムでは、特定のジョブに対して不適切なプール情報が表示される原因となる問題を修正しました。

flaky テスト管理の製品内サポート

不安定なテストは、テストの失敗がテスト中の変更に関連していない可能性があるため、開発者の生産性に影響を与える可能性があります。 また、出荷されたコードの品質にも影響を与える可能性があります。 このため、不安定なテスト管理に対する製品内サポートが追加されました。 この機能は、検出、レポート、解決を使用したエンドツーエンドのライフサイクルをサポートします。 不安定なテストの管理では、システムとカスタムの検出がサポートされます。

システム検出は、VSTest タスク再実行機能を使用して使用できます。 不安定なテストは、ソース コードや実行環境に変更がない場合でも、成功や失敗など、さまざまな結果を示すテストです。 同じブランチに対するテストのそれ以上の実行はすべて、解決されてマークが解除されるまで、不安定なマークも付けられます。 また、API を使用してカスタム検出メカニズムをプラグインすることもできます。 テストが不安定であると識別されると、パイプラインのコンテキスト内テスト レポートで詳細を取得できます。 その後、不安定なテストがパイプラインの障害に影響を与えるかどうかを判断できます。 既定では、不安定なテスト情報は追加のメタデータとして使用できます。

In-product support for flaky test management.

テストの概要を含むレポートの例を次に示します。

Example of a report with the test summary.

不安定なテスト管理の詳細については、こちらのドキュメントを参照してください。

Azure portal での WebApp のデプロイ センターの機能強化

複数の成果物を含むパイプラインのサポートにより、Azure portal の WebApp のデプロイ センターが改善されました。 ここで、Azure Pipelines のプライマリ以外の成果物が Web アプリにデプロイされている場合は、Azure portal から関連する詳細を取得します。 また、デプロイされたリポジトリへのディープ リンクを使用して、Azure portal からリポジトリに直接移動することもできます。 リポジトリは、Azure Repos または GitHub でホストできます。

新しいブランチでの CI のトリガー

新しいブランチが作成され、そのブランチに変更がない場合に CI ビルドをトリガーしないという長い保留中の要求でした。 次に例を示します。

  • Web インターフェイスを使用して、既存のブランチに基づいて新しいブランチを作成します。 これにより、ブランチ フィルターが新しいブランチの名前と一致する場合、新しい CI ビルドが直ちにトリガーされます。 これは、新しいブランチの内容が既存のブランチと比較して同じであるため、望ましくはありません。
  • アプリとドキュメントの 2 つのフォルダーを含むリポジトリがあります。"app" と一致するように CI のパス フィルターを設定します。 つまり、変更がドキュメントにプッシュされた場合は、新しいビルドを作成する必要はありません。新しいブランチをローカルで作成し、ドキュメントに変更を加えてから、そのブランチをサーバーにプッシュします。 新しい CI ビルドをトリガーするために使用しました。 ドキュメント フォルダーで変更を検索しないように明示的に要求しているため、これは望ましくありません。 ただし、新しいブランチ イベントの処理方法により、アプリ フォルダーも変更されたかのように見えます。

これで、これらの問題に対処するための新しいブランチの CI をより適切に処理する方法が得られます。 新しいブランチを発行すると、そのブランチで新しいコミットが明示的に検索され、パス フィルターと一致するかどうかをチェックします。

Azure Pipelines との Terraform の統合

Terraform は、インフラストラクチャを安全かつ効率的に開発、変更、バージョン管理するためのオープンソース ツールです。 Terraform は API を宣言型の構成ファイルに変換し、高度な構成言語を使用してインフラストラクチャを定義およびプロビジョニングできるようにします。 Terraform 拡張機能を使用すると、すべての主要なインフラストラクチャ プロバイダー (Azure、アマゾン ウェブ サービス (AWS)、Google Cloud Platform (GCP) ) にわたってリソースを作成できます。

Terraform 拡張機能の詳細については、こちらのドキュメントを参照してください。

Terraform integration with Azure Pipelines.

Google Analytics との統合

Google Analytics の実験フレームワークを使用すると、Web サイトやアプリに対するほぼすべての変更やバリエーションをテストして、特定の目的への影響を測定できます。 たとえば、ユーザーに完了させるアクティビティ (購入、ニュースレターへのサインアップなど) や、改善するメトリック (収益、セッション期間、バウンス率など) があるとします。 これらのアクティビティを使用すると、機能のパフォーマンスに与える直接的な影響に基づいて、実装する価値のある変更を特定できます。

Azure DevOps 用の Google Analytics 実験拡張機能では、実験手順がビルド パイプラインとリリース パイプラインに追加されるため、Azure Pipelines から DevOps のすべての利点を得ながら、実験を継続的に管理することで、継続的に反復、学習、デプロイを迅速に行うことができます。

Google Analytics の 実験拡張機能 は、Marketplace からダウンロードできます。

Integration with Google Analytics.

パイプライン キャッシュ (パブリック プレビュー)

パイプライン キャッシュを使用すると、パッケージの復元や依存関係のコンパイルなど、実行時間の長い操作の結果を保存し、パイプラインの次の実行時に元に戻すことができます。 これにより、ビルドが高速になります。

詳細については、ブログの投稿と完全な発表 を参照してください。

パイプライン変数グループと変数管理コマンド

パイプライン変数と変数グループを手動で設定する必要があるため、YAML ベースのパイプラインを 1 つのプロジェクトから別のプロジェクトに移植するのは困難な場合があります。 ただし、パイプライン 変数グループ と 変数 管理コマンドを使用して、パイプライン変数と変数グループの設定と管理をスクリプト化できるようになりました。これにより、バージョン管理が可能になり、あるプロジェクトから別のプロジェクトにパイプラインを移動および設定する手順を簡単に共有できます。

PR ブランチのパイプラインの実行

PR を作成するときに、変更によってターゲット ブランチでのパイプラインの実行が中断される可能性があるかどうかを検証するのは困難な場合があります。 ただし、パイプラインの実行をトリガーしたり、PR ブランチのビルドをキューに入れたりする機能を使用して、ターゲット パイプラインに対して実行することで、変更を検証して視覚化できるようになりました。 詳細については、 az pipelines run と az pipelines build queue コマンドのドキュメントを参照してください。

最初のパイプライン実行をスキップする

パイプラインを作成するときに、インフラストラクチャの準備ができていないか、変数/変数グループを作成して更新する必要があるため、YAML ファイルを作成してコミットし、パイプラインの実行をトリガーしない場合があります。Azure DevOps CLI では、--skip-first-run パラメーターを含めることで、パイプラインの作成時に最初の自動パイプライン実行をスキップできるようになりました。 詳細については、 az pipeline create コマンドのドキュメント を参照してください。

サービス エンドポイント コマンドの機能強化

サービス エンドポイント CLI コマンドでは、Azure rm と github サービス エンドポイントの設定と管理のみがサポートされました。 ただし、このリリースでは、サービス エンドポイント コマンドを使用すると、ファイルを使用して構成を指定して任意のサービス エンドポイントを作成でき、最適化されたコマンド (az devops service-endpoint github と az devops service-endpoint azurerm) が提供されます。これにより、これらの種類のサービス エンドポイントを作成するためのファースト クラスのサポートが提供されます。 詳細については、コマンドの ドキュメント を参照してください。

次のステップ

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告したり、提案を提供したりします。

Make a suggestion

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

サム・グッケンハイマー