Azure DevOps でorganization課金を管理する - Sprint 150 Update

  • [アーティクル]

Azure DevOps の Sprint 150 Update で、ポータル内でorganizationの課金を管理する機能が追加されました。

[新しい課金] タブから、課金に使用する Azure サブスクリプションを選択し、追加のユーザーに対して支払うことができます。 課金を管理するために、Visual Studio Marketplace またはAzure portalに移動する必要がなくなりました。

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

機能

全般:

Azure Boards:

Azure Repos:

Azure Pipelines:

レポート:

Wiki:

[Administration:

全般

ダーク テーマの一般提供

昨年 10 月、新しいナビゲーションの一部としてダーク テーマのパブリック プレビューをリリースしました。 プレビューの数か月後、フィードバックを聞き、エクスペリエンスをチューニングした後、ダーク テーマの一般提供についてお知らせします。

Azure DevOps からorganizationの課金を管理する

Azure DevOps ポータルからorganizationの課金を管理できるようになりました。 管理者は、Azure portalを使用して課金を設定する必要がなくなりました。 課金設定を管理するには、[ 組織の設定] に移動し、[課金] を選択 します。

[ 課金 ] タブから管理できる設定の一覧を次に示します。

  1. 課金に使用する Azure サブスクリプションを選択できます。

    組織設定の課金。

  2. 別のサブスクリプションを選択することで、organizationが課金に使用する Azure サブスクリプションを変更できます。 以前は、課金を削除してから、有料リソース (Basic ユーザー、パッケージ管理ユーザー、MS ホステッド パイプラインなど) ごとに同じレベルを慎重に再購入する必要がありました。このプロセスは面倒で、エラーが発生しやすくなります。 別のサブスクリプションを選択して [保存] をクリックすることで、organizationが課金に使用する Azure サブスクリプションを変更できるようになりました。

    Azure サブスクリプション ID の課金。

  3. Visual Studio Marketplace にアクセスして課金設定を管理する必要がなくなりました。 Basic、Test Manager、Package Management (Azure Artifacts) の追加ユーザーに対して支払う機能が追加されました。 新しい [課金] タブから、organizationが支払っているユーザーの数を増減できます。

    追加のユーザーに対する課金。

Azure Boards

Azure Active Directory グループに基づいて作業のクエリを実行する

Azure Active Directory の導入が増え、グループを使用してセキュリティを管理する普及が進む中、チームは、これらのグループをAzure Boardsで活用する方法をますます探しています。 [グループ内 ] または [ グループに 含まれていない ] 演算子を使用して特定のユーザーによって割り当てられた、または変更された作業項目のクエリに加えて、Azure Active Directory グループを直接使用することもできます。

詳細については、 クエリ演算子 のドキュメントを参照してください。

グループに基づくクエリ作業。

バッジを使用してチームのボードを共有する

リポジトリの README は、多くの場合、ソリューションに貢献して使用する方法に関する情報を得るためにプロジェクト チームがアクセスするホームです。 これで、Azure Pipelines のビルドまたはデプロイの状態と同様に、Azure Boardsでチームのボードのバッジを README に追加できます。 [進行中] 列またはすべての列のみを表示するようにバッジを構成し、プロジェクトがオープンソースされている場合はバッジを公開することもできます。

バッジを使用してボードを共有します。

README が Markdown に基づいている場合は、ステータス バッジの設定ページからサンプルの Markdown をコピーし、ファイルに貼り付けることができます。

GitHub の README のバッジ。

日、週、月、または年の開始日を基準にした作業のクエリ

チームは多くの場合、次に予定されている作業やスプリントのイテレーションに基づいて作業に集中しますが、多くの場合、予定表のレンズを通して作業を振り返って、先月または今年の第 1 四半期に発生したすべての作業を報告することが興味深いです。 これで、次の新しい @StartOf マクロセットと日付ベースのフィールドを使用して、日、週、月、または年の開始日に基づいてクエリを実行できます。

  • @StartOfYear
  • @StartOfMonth
  • @StartOfWeek
  • @StartOfDay

これらの各マクロでは、データを異なる日付単位でシフトできる新しい修飾子文字列も受け入れられます。 たとえば、今年の第 1 四半期に完了したすべての作業項目を検索するクエリを作成するには、状態変更日 = および状態変更日 ><= @StartOfYear@StartOfYear(“+3M”)に対してクエリを実行します。 詳細については、 クエリ マクロ のドキュメントを参照してください。

日、週、月、または年の開始日を基準にして、作業のクエリを実行します。

クエリ結果を CSV ファイルにエクスポートする

Web から CSV 形式ファイルにクエリ結果を直接エクスポートできるようになりました。

クエリ結果をエクスポートします。

Azure Repos

pull request を完了するための新しいマージの種類

pull request からターゲット ブランチに変更をマージするときに、さらに多くのオプションが用意されました。 Developer Communityで最も要求されている機能の 2 つに対するサポートが追加されました。高速転送マージとセミリニア マージ ("リベースとマージ" とも呼ばれます)。

[ Pull Request の完了 ] ダイアログで、次の新しいオプションを使用できるようになります。

pull request を完了するための新しいマージの種類。

更新されたポリシー管理ページを使用すると、管理者はブランチまたはブランチのフォルダーで許可されるマージ戦略を制御できます。

マージの種類を制限します。

注意

既存のポリシーは引き続き適用されます。 たとえば、ブランチに現在 "squash マージのみ" ポリシーが設定されている場合、新しいマージ戦略を使用するには、そのポリシーを編集する必要があります。

pull request の完了時に再評価できない場合は、いくつかの状況があります。

  • ターゲット ブランチのポリシーでリベース戦略の使用が禁止されている場合は、"ブランチ ポリシーをオーバーライドする" アクセス許可が必要です。
  • pull request のソース ブランチにポリシーがある場合、それをリベースすることはできません。 リbasingでは、ポリシー承認プロセスを経ずにソース ブランチが変更されます。
  • マージ競合拡張機能を使用してマージ競合を解決した場合。 3 方向マージに適用される競合解決は、pull request 内のすべてのコミットを一度に 1 つずつリベースする場合に、成功することはほとんどありません (または、有効な場合もあります)。

このような場合でも、ブランチをローカルにリベースしてサーバーにプッシュするか、pull request を完了するときに変更をsquashマージすることができます。

Azure Pipelines

Kubernetes マニフェスト タスク

マニフェスト ファイルを使用して Kubernetes クラスターにデプロイするプロセスを簡略化するために、リリース パイプラインに新しいタスクを追加しました。 このタスクは、スクリプトでの kubectl バイナリの使用と比較して、次の利点を提供します。

  • 成果物の置換 - デプロイ アクションは、タグまたはダイジェストと共に指定できるコンテナー イメージの一覧を入力として受け取ります。 これは、適切なバージョンのイメージがクラスターのノードによって確実にプルされるように、マニフェスト ファイルをクラスターに適用する前に、テンプレート以外のバージョンのマニフェスト ファイルに置き換えます。

  • マニフェストの安定性 - デプロイされた Kubernetes オブジェクトに対してロールアウトの状態がチェックされ、タスクの状態を成功または失敗として計算しながら安定性チェックが組み込まれます。

  • 追跡可能性の注釈 - 注釈は、デプロイされた Kubernetes オブジェクトに追加され、元のorganization、プロジェクト、パイプライン、および実行に関するトレーサビリティ情報が重ね合わされます。

  • ベイク マニフェスト - タスクのベイク アクションを使用すると、クラスターに適用できるように Helm チャートを Kubernetes マニフェスト ファイルにベイクできます。

  • デプロイ戦略 - デプロイ アクションを使用してカナリア戦略を選択すると、タスクの昇格/拒否アクションを使用して保持するバージョンを最終処理する前に、タスク中ManualInterventionに比較できるように、-baseline と -canary でサフィックスが付いたワークロードの望ましい割合が作成されます。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Docker タスクへのアップグレード

パイプラインの作成エクスペリエンスを簡略化するために Docker タスクをアップグレードしました。 buildAndPush コマンドを使用して、特定のコンテナー リポジトリの複数のタグをビルドし、1 つの手順で複数のコンテナー レジストリにプッシュできるようになりました。 タスクでは、コンテナー レジストリへのログインに Docker レジストリ サービス接続を使用できます。 ソース リポジトリ、コミット、ビルドの実績に関する追跡可能性メタデータは、このタスクを使用してビルドされたイメージにラベルとして追加されます。

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Kubectl ツール インストーラー

特定のバージョンの Kubectl バイナリをエージェントにインストールできる新しいタスクが追加されました。 'v1.14.0' などの 最新 および semver バージョンの文字列は、Kubectl Version Spec 入力の有効な値として受け入れられます。

kubectl ツール インストーラー。

Docker レジストリ サービス接続での Azure コンテナー レジストリ

これで、プロジェクトの設定ページから Docker レジストリ サービス接続を作成できます。 接続を作成するには、Azure Active Directory (Azure AD) ID に関連付けられているサブスクリプションのいずれかで Azure コンテナー レジストリを選択します。 Docker@2やKubernetesManifest@0など、コンテナー レジストリへのサービス接続を必要とするすべてのタスクは、接続を指定する 1 つの方法をサポートします。

Docker サービス接続を追加します。

ホストされている Ubuntu プールでの cgroup のサポート

Linux では、メモリ使用量が多すぎると、カーネルは残りの部分を保護するために一部のプロセスを終了します。 終了のために Azure Pipelines エージェント プロセスが選択されている場合、パイプラインの実行は失敗し、エージェントとの通信が失われるというエラー メッセージが表示されます。 Microsoft がホストする Ubuntu プールでは、カスタム cgroup 内で手順を実行することでエージェントが終了する可能性が低くなります。 使用可能なメモリを超えるとパイプラインが失敗する可能性はありますが、エージェント プロセスは存続し、エラーを正しく報告する可能性が高くなります。 プライベート Linux エージェントを実行する場合は、同様のセットアップを検討できるように、使用する設定が 公開 されています。

エージェントを 1 回実行する

Azure Container Instancesなどのインフラストラクチャを使用してエラスティック プライベート エージェントを実行する場合は、多くの場合、各エージェントが 1 つのジョブのみを受け入れてから退出する必要があります。 これまでは、エージェントを終了するか (エラーが報告される可能性があるため)、またはエージェントがシャットダウンする前に別のジョブを受け取るリスクを受け入れる必要があるため、これは簡単ではありませんでした。 この更新プログラムでは、エージェント構成に --once フラグを追加しました。 この方法でエージェントを構成すると、1 つのジョブのみを受け入れてからシャットダウンします。

Visual Studio テスト タスクでの Visual Studio 2019 (VS2019) のサポート

パイプラインの Visual Studio テスト タスクに VS2019 のサポートを追加しました。 VS2019 のテスト プラットフォームを使用してテストを実行するには、[テスト プラットフォームのバージョン] ドロップダウンから [最新 ] または [ Visual Studio 2019 ] オプションを選択します。

Visual Studio テスト タスクでの Visual Studio 2019 (VS2019) のサポート。

エージェント プールのユーザー インターフェイスの更新

プロジェクト設定のエージェント プール管理ページが、新しいユーザー インターフェイスで更新されました。 これで、プールで実行されているすべてのジョブを簡単に確認できます。 さらに、ジョブが実行されていない理由も学習できます。

エージェント プール ユーザー エクスペリエンス (UX) の更新。

YAML ファイルを編集するためのタスク アシスタント

パイプラインの YAML ファイルを簡単に編集できるように、引き続き多くのフィードバックを受け取ります。 以前の更新プログラムでは、Intellisense のサポートが追加されました。 次に、タスク アシスタントを YAML エディターに追加します。 これにより、クラシック エディターと同じように、YAML ファイルに新しいタスクを追加する場合と同じ使い慣れたエクスペリエンスが得られます。 この新しいアシスタントでは、ピック リストやサービス接続など、ほとんどの一般的なタスク入力の種類がサポートされています。 新しいタスク アシスタントを使用するには、YAML ベースのパイプラインで [編集] を選択し、[タスク] アシスタントを選択します。

YAML ファイルを編集するためのタスク アシスタント。

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

ホストされている macOS プール の OS X Mojave (10.4) の更新プログラムをお知らせします。これには Xcode 10.2 のサポートも含まれます。 デザイナーベースのパイプラインで ホステッド macOS プールを使用している場合、パイプラインは自動的に Mojave にアップグレードされます。 OS X High Sierra (10.3) を使用する場合は、ビルドを実行するプールを ホストされた macOS High Sierra に変更します。

YAML を使用している場合、使用できる新しい vmImage ラベルは次のとおりです。

  • 最新バージョンの macOS (現在は 10.4) を常に指すイメージ ラベル
vmImage: 'macOS-latest'
  • パイプラインが Mojave に対して確実に実行されるようにする場合、このイメージ ラベルは特に mac OS 10.4 を対象としています
vmImage: 'macOS-10.4'
  • パイプラインが High Sierra に対して確実に実行されるようにする場合は、特に mac OS 10.3 を対象とするイメージ ラベル
vmImage: 'macOS-10.3'

また、ホストされている Azure パイプラインの Windows Server 2019 イメージの更新も行いました。 最新のリリースについては、 こちらを参照してください。 この更新プログラムには、VS2019 プレビュー、Docker、PowerShell Core、Node.js、npm などの新しいバージョンが含まれています。

ホストされた macOS VM イメージに含まれている内容の詳細と、イメージで使用できるツールの詳細については、GitHub の Image Generation リポジトリ を参照してください。

ServiceNow 統合の機能強化

昨年 12 月に、ServiceNow Change Management とリリース パイプラインの統合をリリースしました。 各チームが選択したサービスを使用し、効果的なエンドツーエンドの配信を可能にした、チーム間コラボレーションの重要な機能です。 この更新プログラムでは、すべての種類の変更 (通常、標準、緊急) をサポートするように統合が強化されました。 さらに、organizationの ITSM プロセスに従って、既存のテンプレートを使用して新しい変更要求を作成するために使用するゲートを指定できるようになりました。 最後に、既存の変更要求に基づいてリリースをゲートすることもできます。 これにより、IT チームによって推奨されるプロセスを変更することなく、CD を採用できます。

ServiceNow の変更管理。

Azure PowerShell Az モジュールのサポート

Azure PowerShellには、コマンド ラインから Azure リソースを管理するために使用できる一連のコマンドレットが用意されています。 昨年 12 月に、Azure PowerShell Az モジュールが利用可能になり、Azure リソースを管理するための目的のモジュールになりました。

以前は、ホストされているエージェントの Azure PowerShell Az モジュールのサポートは提供していませんでした。 ビルド パイプラインとリリース パイプラインの新しいAzure PowerShell タスク バージョン 4.* により、すべてのプラットフォームに対する新しい Az モジュールのサポートが追加されました。 タスク バージョン 3.* Azure PowerShell、AzureRM モジュールは引き続きサポートされます。 ただし、最新の Azure サービスと機能に対応するには、できるだけ早く Azure PowerShell タスク バージョン 4.* に切り替えることをおすすめします。

Az モジュールには、既存のスクリプトを使用するのに役立つ互換性モードがあり、新しい構文を使用するように更新します。 Az モジュールの互換性を有効にするには、 コマンドを Enable-AzureRmAlias 使用します。 エイリアスを使用すると、Az モジュールで古いコマンドレット名を使用できます。 Azure RM モジュールから Azure PowerShell Az モジュールへの移行の詳細については、こちらを参照してください。

注意

プライベート エージェントを使用している場合は、エージェント コンピューターに Az モジュールをインストールする必要があります。

Azure PowerShell Az モジュールの詳細については、こちらのドキュメントを参照してください。

リソース承認の機能強化

YAML ファイルで参照される場合、保護されたリソース (サービス接続、変数グループ、エージェント プール、セキュリティで保護されたファイルなど) のセキュリティを提供する必要があります。 同時に、運用以外のシナリオでこれらの種類のリソースを使用するパイプラインを簡単に設定して使用できるようにしたいと考えました。 以前は、リソースを "すべてのパイプラインでの使用が承認されました" としてマークする設定を追加しました。

この更新プログラムでは、リソースをそのようにマークしていない場合でも、リソース承認の問題を簡単に修正できるようになりました。 新しいエクスペリエンスでは、リソース承認エラーが原因でビルドが失敗すると、パイプラインでこれらのリソースの使用を明示的に承認して続行するオプションが表示されます。 リソースを承認するアクセス許可を持つチーム メンバーは、失敗したビルドから直接このアクションを完了できます。

承認エラーを含むパイプラインの概要。

ビルド パイプラインの簡略化された保持ポリシー

YAML ビルドを含むすべてのビルド パイプラインのリテンション期間モデルを簡略化しました。 プロジェクト レベルには、各パイプラインのビルドを保持する日数と、各ビルドの成果物を保持する日数を制御できる新しい設定があります。 クラシック エディターを使用してビルド パイプラインを作成した場合、古い保持設定は引き続き受け入れられますが、新しいパイプラインでは新しい設定が使用されます。 リテンション期間は、プロジェクト設定のパイプライン設定ページで管理できます。

リリースで自動的にフェッチされるパイプライン成果物

以前は、リリースにリンクされたビルド パイプラインで [ パイプライン成果物 の発行] タスクを使用して成果物が発行されていた場合、成果物はリリースで自動的にフェッチされませんでした。 代わりに、成果物をダウンロードするために、リリース パイプラインにパイプライン成果物 のダウンロード タスクを明示的に追加する必要がありました。

これで、ビルド パイプラインによって発行されたすべてのパイプライン成果物が自動的にダウンロードされ、リリースで使用できるようになります。 リリース パイプラインのフェーズ プロパティからパイプライン成果物のダウンロードをカスタマイズすることもできます。

Cobertura コード カバレッジ レポートの更新

以前は、パイプラインでテストを実行し、コード カバレッジの結果を Azure DevOps に発行したときは、XML サマリーと HTML レポート ファイルの両方を指定する必要があります。 さらに、HTML レポートのスタイルは、コード カバレッジ タブに表示される前に削除されました。このスタイルの削除は、任意の HTML ファイルをアップロードできるため、セキュリティの観点から必要でした。

この更新プログラムでは、Cobertura カバレッジ レポートのこれらの制限に対処しました。 コード カバレッジ レポートを発行するときに、HTML ファイルを指定する必要がなくなりました。 レポートは自動的に生成され、[コード カバレッジ] タブに適切なスタイル設定で表示されます。この機能では、オープンソース ツール ReportGenerator を使用します。

コード カバレッジ。

レポート

ビルドの失敗と期間のレポート

パイプラインのスループットと安定性を継続的に向上させるために、メトリックと分析情報を用意することが重要です。 パイプライン分析を提供するための最初のステップとして、パイプラインに関するメトリックと分析情報を提供する 2 つのレポートを追加しました。

  1. エラー レポートには、ビルドパス率とエラー傾向が表示されます。 さらに、タスクの失敗傾向も表示され、エラーの最大数に貢献しているタスクに関する分析情報が提供されます。

    ビルドの失敗と期間のレポート。

  2. 期間レポートには、パイプラインの期間とその傾向が含まれます。

    パイプライン期間レポートの傾向。

分析の一般提供

次の分析機能が追加コストなしで Azure DevOps に含まれることをお知らせします。

  1. 分析ウィジェットは、ダッシュボードにデータを表示し、作業の進行状況を監視するのに役立つ構成可能なモジュールです。 含まれるウィジェットは次のとおりです。

    • バーンダウングラフとバーンアップ チャートは、一定期間にわたる一連のスコープ付き作業の進行状況を監視します。

      バーンダウンチャートとバーンアップチャート。

    • チームの開発サイクルを通じて作業がどのように進むかを視覚化するためのサイクル時間とリード タイム

      サイクル時間とリード タイム。

    • 累積フロー 図 (CFD) では 、さまざまな状態を経て作業項目が進行するにつれて追跡されます。

      累積フロー図。

    • 速度 は、チームが複数のスプリントに対してどのように価値を提供しているかを追跡します。

      ベロシティ チャート。

    • テスト結果の傾向 : テストの傾向を監視し、単一または複数のパイプラインに対するテストの失敗と期間のパターンを検出します。

      テスト結果の傾向。

  2. 製品には、パイプラインの信頼性の向上とテスト負債の削減に役立つ、パイプラインで失敗した上位のテストに関する分析情報を得るために、 失敗した上位 のテスト レポートが含まれています。

    テスト エラー レポート。

また、分析ビューを通じて Power BI 統合を提供し、すべてのAzure DevOps Servicesのお客様に対してプレビュー段階で OData エンドポイントに直接アクセスします。

Analytics Marketplace 拡張機能を使用している場合は、以前と同じように引き続き Analytics を使用できます。追加の手順に従う必要はありません。 これは、ホストされている顧客の Analytics Marketplace 拡張機能 を非推奨にすることを意味します。

Azure DevOps Analytics オファリングはレポートの未来であり、Analytics が主導する新機能に投資し続けます。 Analytics の詳細については、以下のリンクを参照してください。

Wiki

Wiki ページの通知

これまでは、Wiki ページのコンテンツがいつ変更されたかを知る方法はありませんでした。 これで、Wiki ページをフォローして、ページが編集、削除、または名前変更されたときに電子メールで通知を受け取ることができます。 Wiki に加えられた変更を追跡するには、Wiki ページから [フォロー ] ボタンを選択します。

Wiki ページ。

この機能は、 この 提案チケットに基づいて優先順位が付けされています。 詳細については、 こちらのドキュメントを参照してください。

管理

Azure DevOps からorganizationの課金を管理する

Azure DevOps ポータルからorganizationの課金を管理できるようになりました。 管理者は、Azure portalを使用して課金を設定する必要がなくなりました。 課金設定を管理するには、[ 組織の設定] に移動し、[課金] を選択 します。

[ 課金 ] タブで管理できる設定の一覧を次に示します。

  1. 課金に使用する Azure サブスクリプションを選択できます。

    組織設定の課金。

  2. organizationが課金に使用する Azure サブスクリプションを変更するには、別のサブスクリプションを選択します。 以前は、課金を削除してから、有料リソース (Basic ユーザー、パッケージ管理ユーザー、MS ホステッド パイプラインなど) ごとに同じレベルを慎重に再購入する必要がありました。このプロセスは面倒で、エラーが発生しやすくなっていました。 別のサブスクリプションを選択して [保存] をクリックすることで、organizationが課金に使用する Azure サブスクリプションを変更できるようになりました。

    Azure サブスクリプション ID の

  3. Visual Studio Marketplace にアクセスして課金設定を管理する必要がなくなりました。 Basic、Test Manager、Package Management (Azure Artifacts) の追加ユーザーに対して支払う機能が追加されました。 organizationが支払っているユーザーの数は、新しい [課金] タブから増減できます。

    追加のユーザーに対する課金。

次の手順

Note

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

Azure DevOps に進み、見てみましょう。

Azure DevOps に移動する

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

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

ご提案の送信

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

よろしくお願いします。

Jeremy Epling