次の方法で共有

チームなしでダッシュボードを作成する - Sprint 162 Update

  • [アーティクル]

Azure DevOps の Sprint 162 Update では、ダッシュボードをチームに関連付けなくても作成できることをお知らせします。 ダッシュボードはプロジェクト内のすべてのユーザーに表示され、編集または管理できるユーザーを決定できます。

さらに、スプリントバーンダウンサムネイルを追加しました。 これで、ストーリー、ストーリー ポイント、またはタスクの数に基づいてバーンダウンするように構成できます。

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

機能

Azure Repos:

Azure Pipelines:

レポート:

Azure Repos

新しい Web プラットフォーム変換ランディング ページ

Repos ランディング ページのユーザー エクスペリエンスが更新され、モダンで高速でモバイルに対応できるようになりました。 更新されたページの 2 つの例を次に示します。今後の更新では、引き続き他のページを更新します。

Web エクスペリエンス:

新しい Web プラットフォーム変換ランディング ページ。

モバイル エクスペリエンス:

新しいモバイル プラットフォーム変換ランディング ページ。

新しいモバイル プラットフォーム ランディング ページの例。

Kotlin 言語のサポート

ファイル エディターで Kotlin 言語の強調表示がサポートされるようになりました。 強調表示により、Kotlin テキスト ファイルの読みやすさが向上し、エラーをすばやくスキャンしてエラーを検出するのに役立ちます。 この機能は、Developer Communityからの提案に基づいて優先されました。

Kotlin 言語のサポート。

Azure Pipelines

マルチステージ パイプライン UI の更新

マルチステージ パイプライン UI の更新バージョンが既定で使用できるようになりました。 マルチステージ パイプライン エクスペリエンスは、パイプラインのポータル UI に改善と使いやすさをもたらします。 左側のメニューから [パイプライン] を選択すると、パイプラインを表示および管理できます。 さらに、パイプラインの詳細、実行の詳細、パイプライン分析、ジョブの詳細、ログなどをドリルダウンして表示できます。

マルチステージ パイプラインのユーザー エクスペリエンスの詳細については、 こちらのドキュメントを参照してください。

マルチステージ パイプライン UI を更新しました。

VSTest TestResultsDirectory オプションは、タスク UI で使用できます

VSTest タスクは、テスト結果と関連ファイルを フォルダーに $(Agent.TempDirectory)\TestResults 格納します。 テスト結果を格納するように別のフォルダーを構成できるように、タスク UI にオプションが追加されました。 これで、特定の場所にあるファイルを必要とする後続のタスクで、それらを使用できるようになりました。

VSTest TestResultsDirectory オプションは、タスク UI で使用できます。

パイプラインの拡張キーワード (keyword)を使用する

現時点では、パイプラインをテンプレートに組み込み、再利用を促進し、定型句を減らすことができます。 パイプラインの全体的な構造は、ルート YAML ファイルによってまだ定義されています。 この更新プログラムでは、パイプライン テンプレートを使用するためのより構造化された方法が追加されました。 ルート YAML ファイルで キーワード (keyword) 拡張を使用して、メイン パイプライン構造が別のファイルで見つかっていることを示すようになりました。 これにより、拡張または変更できるセグメントと固定されるセグメントを制御できます。 また、提供できるフックを明確にするために、データ型を使用してパイプライン パラメーターを強化しました。

この例では、パイプライン作成者が使用する単純なフックを提供する方法を示します。 テンプレートは常にビルドを実行し、必要に応じてパイプラインによって提供される追加の手順を実行し、オプションのテスト 手順を実行します。


# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

自動テスト エラー メッセージでの Markdown のサポート

自動テストのエラー メッセージに Markdown のサポートが追加されました。 これで、テスト実行とテスト結果の両方のエラー メッセージを簡単に書式設定して、読みやすさを向上させ、Azure Pipelines でのテスト エラーのトラブルシューティング エクスペリエンスを容易にすることができます。 サポートされている Markdown 構文については、 こちらを参照してください。

自動テスト エラー メッセージでの Markdown のサポート。

パイプラインから自動およびユーザー指定のメタデータを収集する

パイプライン タスクから、自動およびユーザー指定のメタデータ収集を有効にできるようになりました。 メタデータを使用して、成果物の評価チェックを使用して、環境に成果物ポリシーを適用できます。

パイプラインから自動およびユーザー指定のメタデータを収集します。

サービス接続 UI への更新

サービス接続を管理するために、更新されたユーザー エクスペリエンスに取り組んでいます。 これらの更新により、サービス接続エクスペリエンスが最新になり、Azure DevOps の方向と一致します。 今年の初めに、サービス接続用の新しい UI をプレビュー機能として導入しました。 新しいエクスペリエンスを試し、貴重なフィードバックを提供してくださった皆様に感謝します。

サービス接続 UI に更新します。

ユーザー エクスペリエンスの更新に加えて、YAML パイプラインでサービス接続を使用するために重要な 2 つの機能 (パイプラインの承認と承認とチェック) も追加しました。

パイプラインの承認と承認とチェック。

この更新プログラムでは、新しいユーザー エクスペリエンス が既定で有効になります 。 プレビューをオプトアウトすることもできます。

注意

新しい機能として、 サービス接続のプロジェクト間共有 を導入する予定です。 共有エクスペリエンスとセキュリティ ロールの詳細については、 こちらを参照してください。

環境を使用した VM のデプロイ

環境で最も要求された機能の 1 つは、VM のデプロイでした。 この更新プログラムでは、環境で仮想マシン リソースを有効にします。 複数のマシン間でデプロイを調整し、YAML パイプラインを使用して ローリング 更新を実行できるようになりました。 また、各ターゲット サーバーにエージェントを直接インストールし、それらのサーバーへのローリング デプロイを推進することもできます。 さらに、ターゲット マシンで完全なタスク カタログを使用することもできます。

環境を使用した VM のデプロイ。

ローリング デプロイは、アプリケーションの以前のバージョンのインスタンスを、各イテレーションの一連のマシン (ローリング セット) 上の新しいバージョンのアプリケーションのインスタンスに置き換えます。

たとえば、次のローリング デプロイでは、各イテレーションで最大 5 つのターゲットが更新されます。 maxParallel は、並列にデプロイできるターゲットの数を決定します。 選択は、デプロイ先のターゲットを除き、いつでも使用可能な状態を維持する必要があるターゲットの数を考慮します。 それはまた、デプロイの間に成功と失敗の条件を判断するためにも使用されます。

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

注意

この更新プログラムでは、現在のパイプラインと関連するパイプライン リソースから使用可能なすべての成果物は、ライフサイクル フックでのみ deploy ダウンロードされます。 ただし、[ パイプライン成果物のダウンロード] タスクを指定してダウンロードすることもできます。 この機能には、いくつかの既知のギャップがあります。 たとえば、ステージを再試行すると、失敗したターゲットだけでなく、すべての VM でデプロイが再実行されます。 今後の更新プログラムでは、これらのギャップを埋めるために取り組んでいます。

YAML パイプラインでのステージのスキップ

手動実行を開始するときに、パイプラインのいくつかのステージをスキップすることが必要な場合があります。 たとえば、運用環境にデプロイしない場合や、運用環境のいくつかの環境へのデプロイをスキップする場合などです。 これで、YAML パイプラインでこれを行うことができます。

更新された実行パイプライン パネルには、YAML ファイルからステージの一覧が表示され、これらのステージを 1 つ以上スキップするオプションがあります。 ステージをスキップする場合は注意が必要です。 たとえば、最初のステージで後続のステージに必要な特定の成果物が生成される場合、最初のステージをスキップしないでください。 ダウンストリーム依存関係を持つステージをスキップするたびに、実行パネルに一般的な警告が表示されます。 これらの依存関係が実際の成果物の依存関係であるかどうか、またはデプロイのシーケンス処理にだけ存在するかどうかは、ユーザーに任されます。

YAML パイプラインでのステージのスキップ。

ステージをスキップすることは、ステージ間の依存関係を再調整することと同じです。 スキップされたステージの即時ダウンストリーム依存関係は、スキップされたステージの上流の親に依存するように行われます。 実行が失敗し、失敗したステージを再実行しようとすると、その試行も同じスキップ動作になります。 スキップするステージを変更するには、新しい実行を開始する必要があります。

スキップするステージを変更するには、新しい実行を開始します。

レポート

インライン スプリントバーンダウンサムネイル

スプリントバーンダウンが戻ってきた! 少し前に、スプリント バーンダウンヘッダーとタスクボードヘッダーからコンテキスト内スプリントバーンダウンを削除しました。 フィードバックに基づいて、スプリントバーンダウンサムネイルが改善され、再導入されました。

インライン スプリントバーンダウンサムネイル。

サムネイルをクリックすると、より大きなバージョンのグラフがすぐに表示され、[分析] タブに完全なレポートを表示するオプションが表示されます。完全なレポートに加えられた変更は、ヘッダーに表示されるグラフに反映されます。 そのため、残りの作業量だけでなく、ストーリー、ストーリー ポイント、またはタスクの数に基づいてバーンダウンするように構成できるようになりました。

チームなしでダッシュボードを作成する

ダッシュボードをチームに関連付けることなく作成できるようになりました。 ダッシュボードを作成するときに、[ プロジェクト ダッシュボード ] の種類を選択します。

チームなしでダッシュボードを作成します。

プロジェクト ダッシュボードはチーム ダッシュボードに似ていますが、チームに関連付けられていないため、ダッシュボードを編集または管理できるユーザーを決定できます。 チーム ダッシュボードと同様に、プロジェクトのすべてのユーザーに表示されます。

チーム コンテキストを必要とするすべての Azure DevOps ウィジェットが更新され、構成でチームを選択できるようになりました。 これらのウィジェットをプロジェクト ダッシュボードに追加し、必要な特定のチームを選択できます。

チーム コンテキストを必要とする Azure DevOps ウィジェットを更新しました。

注意

カスタムまたはサードパーティのウィジェットの場合、プロジェクト ダッシュボードは既定のチームのコンテキストをそれらのウィジェットに渡します。 チーム コンテキストに依存するカスタム ウィジェットがある場合は、チームを選択できるように構成を更新する必要があります。

次のステップ

Note

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

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

Azure DevOps に移動する

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

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

ご提案の送信

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

よろしくお願いします。

Jeff Beehler