次の方法で共有

ユーザー割り当てベースの課金、既定のアクセス レベル、毎日の課金 - スプリント 158 更新

  • [アーティクル]

Azure DevOps の Sprint 158 Update では、ユーザー割り当てベースの課金が追加されました。 この機能では、Basic または Basic + Test Plan ライセンスの数が、ユーザーの追加または削除時に変更されます。 つまり、使用しているライセンスに対してのみ支払います。 また、新しい設定が追加されました。これにより、新しいユーザーを組織に追加して、完全な Basic アクセスまたは制限付き/無料の利害関係者アクセスを取得するかどうかを選択できます。

さらに、月単位での課金から日単位での課金に変更しました。 これは、ユーザーに数週間、または数日間有効の有料アクセス権を付与した場合は、1 か月分支払うのではなく、有料のアクセス権が割り当てられた期間に対してのみ支払いが発生します。

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

Azure DevOps の新機能

機能

全般:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Test Plans:

レポート:

Wiki

全般

ユーザー割り当てベースの課金と既定のアクセス レベル

ユーザー割り当てベースの課金

この更新プログラムでは、ユーザー割り当てベースの課金が追加されました。 組織が割り当て可能な有料 の Basic または Basic + Test Plan ライセンスの数を増減する代わりに、ユーザーを追加または削除したり、アクセス レベルを変更したりしたときに自動的に行われるようになりました。 つまり、使用しているライセンスよりも多くのライセンスに対して料金が支払われることはなく、アクセス レベルの割り当ての自動化がはるかに簡単になります。 たとえば、チームに自動的に参加する新しいユーザーに割り当てられるアクセス レベルを制御するグループ ルールを設定できます。 しかし、以前は、支払っていた追加のライセンスがまだ誰にも割り当てられていない場合にのみ機能し、使い果たされた場合、 グループルール は失敗しました。 課金に使用する Azure サブスクリプションがアクティブなままである限り、このようなエラーは発生しなくなりました。

新しいユーザーの既定のアクセス レベル

また、新しい設定が追加されました。これにより、新しいユーザーを組織に追加して、完全な Basic アクセスまたは制限付き/無料の利害関係者アクセスを取得するかどうかを選択できます。 以前は、割り当てられていない Basic ライセンスが使用可能な場合は新しいユーザーが Basic を取得していましたが、存在しない場合は利害関係者を取得していました。 すべての組織は、既定のアクセス レベルが [利害関係者] に設定された状態で開始されるため、新しいユーザーに対して予期しない料金は発生しません。 通常、組織で割り当てられていない追加のライセンスを保持し、プロジェクトに追加された新しいユーザーが完全な Basic アクセス権を取得する場合は、必ず 既定のアクセス レベルを Basic に変更してください。

Default access level for new users.

毎日の請求

割り当てベースの課金への変更の一環として、月単位から毎日の請求に切り替えました。 ここで、ユーザーに数週間または数日の有料アクセス権を付与した場合、1 か月間ではなく、有料アクセスが割り当てられた時間に対してのみ支払います。 毎月の請求から毎日の請求に組織を切り替えると、次の Azure の請求書は以前よりも低くなる可能性があります。 翌月は、1 日に 1 か月分の累積料金が発生すると、通常の状態に戻ります。

組織とプロジェクトのアクセス許可を管理するための新しい UI

組織とプロジェクトのアクセス許可の管理に新しい外観が追加され、パフォーマンスが向上しました。 これで、新しいグループ メンバーは、強制的なページの更新を必要とせずに追加されると、一覧に表示されます。 組織の設定に向かい、見てみましょう。

Manage organization and project permissions.

Azure Boards

ロールアップ列のユーザー設定フィールドのサポート

ユーザー設定フィールドを含め、任意のフィールドでロールアップを実行できるようになりました。 ロールアップ列を追加する場合でも、クイック リストからロールアップ列を選択できますが、すぐに使用できるプロセス テンプレートに含まれていない数値フィールドをロールアップする場合は、次のように独自のフィールドを構成できます。

  1. バックログで[列オプション]をクリックします。 次に、パネルで [ロールアップ列の追加] をクリックし、 カスタム ロールアップを構成します。

    Rollup on custom fields.

  2. 進行状況バーと合計を選択します。
  3. 作業項目の種類またはバックログ レベルを選択します (通常、バックログは複数の作業項目の種類を集計します)。
  4. 集計の種類を選択します。 作業項目 の数または 合計。 [合計] では、集計するフィールドを選択する必要があります。
  5. [ OK] ボタンをクリックすると、新しいカスタム列を並べ替えることができる列オプション パネルに戻ります。

Support for custom fields in Rollup columns.

[OK] をクリックした後は、カスタム列を編集できないことに注意してください。 変更する必要がある場合は、カスタム列を削除し、必要に応じて別の列を追加します。

条件に基づいて作業項目フォームのフィールドを非表示にする新ルール

作業項目フォームのフィールドを非表示にできるように、継承されたルール エンジンに新しいルールが追加されました。 このルールでは、ユーザー グループのメンバーシップに基づいてフィールドが非表示になります。 たとえば、ユーザーが "製品所有者" グループに属している場合は、開発者固有のフィールドを非表示にすることができます。 詳細については、こちらのドキュメント を参照してください。

カスタムの作業項目の通知設定

自分やチームに関連する作業項目を最新の状態に保つのは非常に重要です。 チームが共同作業を行い、プロジェクトを追跡し、すべての適切な関係者が関与することを確認するのに役立ちます。 ただし、さまざまな利害関係者がさまざまな取り組みに対して異なるレベルの投資を行っており、作業項目の状態に従う能力に反映される必要があると考えています。

以前は、作業項目をフォローし、加えられた変更に関する通知を受け取る場合は、作業項目に加えられたすべての変更に関する電子メール通知を受け取ります。 フィードバックを検討した後、すべての利害関係者に対して作業項目のフォローをより柔軟に行っています。 これで、作業項目の右上隅にある [フォロー] ボタンの横に新しい設定ボタンが表示されます。 これにより、フォロー オプションを構成できるポップアップが表示されます。

Configure follow options.

通知設定から、3 つの通知オプションから選択できます。 最初に、完全に登録を解除できます。 次に、完全にサブスクライブできます。ここで、すべての作業項目の変更に関する通知を受け取ります。 最後に、上位の重要な作業項目変更イベントの一部について通知を受け取ることを選択できます。 1 つだけ、または 3 つのオプションすべてを選択できます。 これにより、チーム メンバーは、より高いレベルで作業項目をフォローでき、行われるすべての変更に気を取られるのではありません。 この機能を使用すると、不要なメールを排除し、手元の重要なタスクに集中できるようになります。

Choose Notification Settings.

作業項目フォームの配置コントロールのプレビューをリリースすることに興奮しています。 このコントロールは、作業項目をリリースにリンクし、作業項目が展開された場所を簡単に追跡できるようにします。 詳細については、こちらのドキュメント を参照してください。

Link work items to deployments.

Azure Repos

サービスのアカウントベースの認証を使用して AKS に接続する

以前は、AKS デプロイ センターから Azure Pipelines を構成するときに、Azure Resource Manager 接続を使用しました。 この接続は、パイプラインが構成された名前空間だけでなく、クラスター全体にアクセスできました。 この更新プログラムでは、パイプラインはサービス アカウントベースの認証を使用してクラスターに接続し、パイプラインに関連付けられている名前空間にのみアクセスできるようにします。

pull request の Markdown ファイルをサイド バイ サイドの差分でプレビューする

新しい [プレビュー] ボタンを使用して、Markdown ファイルがどのように表示されるかをプレビュー で確認できるようになりました。 さらに、[表示] ボタンを選択すると、Side-by-side diff からファイルの完全なコンテンツを 確認 できます。

Preview Markdown files in pull request Side-by-side diff.

手動ビルドにポリシーの有効期限を設定する

ポリシーによって、チームのコード品質と変更管理基準を確実に運用します。 以前は、自動ビルドのビルド有効期限ポリシーを設定できました。 ビルドの有効期限ポリシーを手動ビルドに設定できるようになりました。

Build policy expiration for manual builds.

コミット作成者メールに基づいてコミットをブロックするポリシーを追加する

管理作成者は、コミット作成者の電子メールが指定されたパターンと一致しないリポジトリにコミットがプッシュされないように、プッシュ ポリシーを設定できるようになりました。

Add a policy to block commits based on the commit author email.

この機能は、同様のエクスペリエンスを 提供するための開発者コミュニティ からの提案に基づいて優先順位が付けられました。 引き続きチケットを開いたままにし、他の種類のプッシュ ポリシーをユーザーに伝えることをお勧めします。

Azure Pipelines

再試行失敗のステージ

Note

この機能を試すには、プレビュー機能 のマルチステージ パイプラインが 有効になっている必要があります。

マルチステージ パイプラインで最も要求される機能の 1 つは、最初から開始しなくても失敗したステージを再試行できることです。 この更新プログラムでは、この機能の大部分を追加しています。

実行が失敗したときにパイプライン ステージを再試行できるようになりました。 最初の試行で失敗したジョブと、失敗したジョブに推移的に依存するジョブはすべて再試行されます。

これは、いくつかの方法で時間を節約するのに役立ちます。 たとえば、1 つのステージで複数のジョブを実行する場合、各ステージで異なるプラットフォームでテストを実行できます。 あるプラットフォームでテストが失敗し、他のプラットフォームが合格した場合は、合格したジョブを再実行しないことで時間を節約できます。 別の例として、ネットワーク接続が不安定なため、デプロイ ステージが失敗した可能性があります。 このステージを再試行すると、別のビルドを生成しなくても時間を節約できます。

この機能には、いくつかの既知のギャップがあります。 たとえば、明示的に取り消したステージを再試行することはできません。 今後の更新プログラムでは、これらのギャップを埋めるために取り組んでいます。

YAML パイプラインにおける承認の強化

Note

この機能を試すには、 マルチステージ パイプライン と 新しいサービス接続エクスペリエンス のプレビュー機能が有効になっている必要があります。

マルチステージの YAML パイプラインは引き続き改善されています。 この更新プログラムでは、サービス接続とエージェント プールに対する承認の構成を有効にしました。 承認のために、インフラストラクチャの所有者と開発者の間の役割の分離に従います。 環境、サービス接続、エージェント プールなどのリソースに対して承認を構成することで、リソースを使用するすべてのパイプライン実行で最初に承認が必要になることが保証されます。

このエクスペリエンスは、環境の承認の構成に似ています。 ステージで参照されているリソースで承認が保留中の場合、パイプラインの実行はパイプラインが手動で承認されるまで待機します。

Enhancements to approvals in YAML pipelines.

Azure Pipelines でのコンテナー構造テストのサポート

アプリケーションでのコンテナーの使用が増加しているため、堅牢なテストと検証の必要性が高まっています。 Azure Pipelines では、コンテナー構造テストのサポートが提供されるようになりました。 このフレームワークは、コンテナーの内容と構造を検証するための便利で強力な方法を提供します。

コマンド テスト、ファイル存在テスト、ファイル コンテンツ テスト、メタデータ テストという 4 つのカテゴリのテストに基づいて、イメージの構造を検証できます。 パイプラインで結果を使用して、go/no go の決定を行うことができます。 テスト データは、エラーのトラブルシューティングに役立つエラー メッセージと共にパイプライン実行で使用できます。

構成ファイルとイメージの詳細を入力する

Container structure testing support in Azure Pipeline.

テスト データと概要

Test data and summary.

flaky バグの管理と解決

7 月には、検出、レポート、解決によるエンドツーエンドのライフサイクルをサポートする不安定なテスト管理を導入しました。 さらに強化するために、不安定なテストバグの管理と解決を追加しています。

不安定なテストの調査中にバグアクションを使用して バグ を作成し、開発者に割り当てて、不安定なテストの根本原因をさらに調査することができます。 バグ レポートには、エラー メッセージ、スタック トレース、テストに関連付けられているその他の情報など、パイプラインに関する情報が含まれています。

バグ レポートが解決または閉じられると、テストのマークが自動的に解除されます。

Slack および Microsoft Teams 向けの Azure Pipelines アプリの機能強化

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

Note

この機能を試すには、プレビュー機能 のマルチステージ パイプラインが 有効になっている必要があります。

Slack および Microsoft Teams 用の Azure Pipelines アプリで、CI と CD 用のマルチステージ YAML パイプラインがサポートされるようになりました。 この機能強化により、YAML パイプラインに関連するさまざまなイベントに関する通知を受け取ります。

Enhancements to Azure Pipelines app for Slack and Microsoft Teams.

マルチステージ YAML パイプラインでサポートされるイベント

  • 実行状態が変更されました
  • 実行ステージの状態が変更されました
  • 承認を待機しているステージを実行する
  • ステージの承認の実行が完了しました

Events supported for multi-stage YAML pipelines.

URL 展開とメッセージング拡張機能

Microsoft Teams 用 Azure Pipelines アプリのメッセージング拡張機能が追加されました。 パイプラインを検索し、パイプラインに関する関連する詳細をチャネルのカードとして共有できるようになりました。 URL の展開は、パイプラインに関するディスカッションを開始し、意味のあるコンテキストに基づく会話を行うのに役立ちます。

URL unfurling and messaging extensions.

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

Azure Pipelines でホストされる VM イメージをいくつか更新しました。 この更新プログラムのハイライトを次に示します。

  • Go 1.13 を Ubuntu 16.04、Ubuntu 18.04、VS2017、VS2019 に追加しました。 既定値メイン 1.12 に戻ります。
  • Android SDK とビルド ツール 29 を Ubuntu 16.04、Ubuntu 18.04、VS2017、VS2019 に追加しました。
  • AZ Module 2.6.0 を VS2017 と VS2019 に追加しました。
  • さまざまなバグを修正しました。

最新リリース の詳細については、こちらをご覧ください。

Note

Ruby 2.3 は、2019 年 3 月 31 日に有効期間が終了して以降、今後の更新プログラムですべてのイメージから削除されます。

Open Policy Agent インストーラー タスク

Open Policy Agent は、コンテキストに対応した統合されたポリシーの適用を可能にする、オープンソースの汎用ポリシー エンジンです。 Open Policy Agent インストーラー タスクが追加されました。 これは、コード プロバイダーとしてのインフラストラクチャに関するパイプライン内ポリシーの適用に特に役立ちます。

たとえば、Open Policy Agent では、パイプライン内の Rego ポリシー ファイルと Terraform プランを評価できます。

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

リリース パイプラインのパイプライン デコレーター

パイプライン デコレーターを使用すると、すべてのジョブの先頭と末尾にステップを追加できます。 これは、組織内のすべてのパイプラインに適用されるため、1 つの定義にステップを追加する場合とは異なります。

ビルドと YAML パイプラインのデコレーターをサポートしており、お客様はそれらを使用してジョブのステップを一元的に制御しています。 現在、パイプラインをリリースするためのサポートも拡張しています。 拡張機能を作成して、新しいコントリビューション ポイントを対象とする手順を追加すると、リリース パイプライン内のすべてのエージェント ジョブに追加されます。

Azure Test Plans

新規テスト計画のページ

計画、作成、実行、追跡の機能のほとんどは、新しい [テスト プラン] ページで使用できるようになりました。 そのため、すべてのテスト プラン ユーザーに対して有効にして、フィードバックを提供できるようにしています。 再メイン前のテスト計画ページと同等に到達するために必要な機能はほとんどなく、次のいくつかのスプリントで有効になります。 必要に応じて、[プレビュー機能] メニューの [テスト プラン] ページを無効にすることができます。 詳細については、こちらをご覧ください。

報告

ストーリー ポイントを使用したインライン スプリント バーンダウン

スプリントバーンダウンがストーリー別にバーンダウンできるようになりました。 これは、開発者コミュニティからのフィードバックに 対応します。

スプリント ハブから[分析]タブを選択します。次に、次のようにレポートを構成します。

  1. ストーリーバックログの選択
  2. ストーリー ポイントの合計でバーンダウンする場合に 選択する

Inline sprint burndown using story points.

Wiki

短くて読みやすい Wiki ページの URL

Wiki ページのリンクを共有するために、複数行の URL を使用する必要がなくなりました。 URL のページ ID を利用してパラメーターを削除するため、URL が短くなり、読みやすくなっています。

URL の新しい構造は次のようになります。

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Azure DevOps Wiki へようこそページの新しい URL の例を次に示します。

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

これは、開発者コミュニティからのこの 機能提案チケット に基づいて優先順位が付けられます。

Wiki でサポートされる mermaid ダイアグラム

Wiki ページに人魚図を挿入するための サポートが 追加されました。 これで、フロー チャートの作成、編集、管理、デザイン ドキュメント内のダイアグラムのシーケンス処理、および計画ドキュメントへのガント チャートの追加を Azure DevOps Wiki で実行できるようになりました。

Mermaid diagram support in wiki.

これは、開発者コミュニティからのこの 機能提案チケット に基づいて優先順位が付けられます。 人魚図の詳細については、こちらのドキュメントを参照してください。

次のステップ

Note

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

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

Azure DevOps に移動する

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

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

Make a suggestion

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

よろしくお願いします。

Ravi シャンカー