Azure DevOpsのSprint 162 Updateでは、チームに関連付けなくても良いダッシュボードが作成できるようになったことをお知らせします。ダッシュボードはプロジェクトの全員に表示され、誰が編集/管理できるかを決定できます。
さらに、スプリントバーンダウンサムネイルを追加しました。ストーリー、ストーリーポイント、またはタスク数に基づいてバーンダウンするように構成できるようになりました。
詳細については、以下の機能リストをご覧ください。
Azure Repos:
Azure Pipelines:
- マルチステージパイプラインのUI更新を初期状態で有効にしました
- VSTestのTestResultsDirectoryオプションをタスクのUIから指定可能にしました
- パイプライン内でextendsキーワードを使ってテンプレートを拡張できるようになりました
- 自動テストのエラーメッセージにMarkdownが使えるようになりました
- パイプラインからユーザー指定のメタデータコレクションを自動的に収集できるようになりました
- 更新されたサービス接続UIを初期状態で有効にします
- EnvironmentsでVMへのデプロイが監視できます
- YAMLパイプラインでステージのスキップができるようになりました
Reporting:
Reposのランディングページのユーザーエクスペリエンスを更新して、モダンで高速、モバイルフレンドリーにしました。更新されたページの例を2つ示しますが、今後の更新でさ他のページも更新し続けます。
Web experience:
Mobile experience:
ファイルエディターでKotlin言語の強調表示をサポートを開始しました。構文のハイライトに対応することで、Kotlinテキストファイルの可読性が向上し、すばやくスキャンしてエラーを見つけられるようになります。Developer Communityからの提案に基づいて、この機能に優先順位を付けました。
マルチステージパイプラインUIの更新バージョンを初期状態で提供開始しました。マルチステージパイプラインエクスペリエンスは、パイプラインのポータルUIの改善と使いやすさをもたらします。左側のメニューからPipelinesを選択すると、パイプラインを表示および管理できます。さらに、パイプラインの詳細、実行の詳細、パイプライン分析、ジョブの詳細、ログなどをドリルダウンして表示できます。
マルチステージパイプラインのユーザーエクスペリエンスの詳細については、こちらのドキュメントを参照してください。
VSTestタスクは、テスト結果と関連ファイルを$(Agent.TempDirectory)\TestResultsフォルダーに保存します。タスクUIにオプションを追加して、テスト結果を保存する別のフォルダーを構成できるようにしました。今回の更新により、特定の場所にあるファイルを必要とする後続のタスクで生成したテスト結果を再利用できます。
現在、パイプラインをテンプレートに分解して、再利用を促進し、定型文を削減できます。パイプラインの全体的な構造は、ルートYAMLファイルによって定義されていました。今回の更新により、パイプラインテンプレートを使用するためのより構造化された方法が追加されました。ルートYAMLファイルでは、キーワードextendsを使用して、メインパイプライン構造が別のファイルに存在すると指定できます。この機能強化により、どのセグメントを拡張または変更でき、どのセグメントが修正されるかを制御できます。また、フックできる場所を明確にするため、データ型を使用してパイプラインパラメーターを強化しました。
この例は、パイプライン作成者が使用する単純なフックを提供する方法を示しています。テンプレートは常にビルドを実行し、オプションでパイプラインによって提供される追加のステップを実行してから、オプションのテストステップを実行します。
# 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のサポートを追加しました。テスト実行とテスト結果の両方のエラーメッセージを簡単にフォーマットできるようになったので、Azure Pipelinesでの読みやすさが改善され、テスト失敗のトラブルシューティングエクスペリエンスを簡単にできるようになりました。サポートされているマークダウン構文はこちらにあります。
パイプラインタスクからの自動およびユーザー指定のメタデータコレクションの有効化ができるようになりました。メタデータを使用して、アーティファクトの評価チェックを使用して環境にアーティファクトポリシーの適用が可能になります。
サービス接続を管理するために、引き続きユーザーエクスペリエンスの更新に取り組んでいます。今回の更新により、サービス接続エクスペリエンスが刷新され、Azure DevOpsの方向性と一貫性が保たれます。今年の初めに、プレビュー機能としてサービス接続用の新しいUIを導入しました。新しい経験を試み、貴重なフィードバックを私たちに提供してくれたすべての人に感謝します。
ユーザーエクスペリエンスの更新に加えて、YAMLパイプラインでサービス接続を使用するために重要な2つの機能、パイプラインの承認と承認のチェックも追加しました。
このアップデートでは、新しいユーザーエクスペリエンスが初期状態で有効になります。プレビューをオプトアウトするオプションも引き続き有効です。
注意
新しい機能として、Cross-project Sharing of Service Connections(訳注:サービス接続のプロジェクト間共有)を導入する予定です。共有エクスペリエンスとセキュリティロールの詳細については、こちらをご覧ください。
Environmentsでもっとも要求された機能の1つはVMへの展開でした。今回の更新により、Environments内の仮想マシンリソースが有効になります。複数のマシン間でデプロイメントを調整し、YAMLパイプラインを使用してローリングデプロイを実行できるようになりました。また、各ターゲットサーバーにエージェントを直接インストールし、それらのサーバーにローリングデプロイを実行することもできます。さらに、ターゲットマシンで完全なタスクカタログを使用できます。
ローリングデプロイは、各イテレーションで一連のマシン(ローリングセット)上のアプリケーションが以前のバージョンのインスタンスからアプリケーションの新しいバージョンのインスタンスに置き換えます。
たとえば、以下のローリングデプロイでは、各反復で最大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...
注意
この更新により、現在のパイプラインおよび関連するパイプラインリソースから利用可能なすべてのアーティファクトは、デプロイライフサイクルフックでのみダウンロードされます。ただし、Download Pipeline Artifactタスクを指定することにより、ダウンロードを選択できます。この機能にはいくつかの既知のギャップがあります。たとえば、ステージを再試行すると、失敗したターゲットだけでなく、すべてのVMで展開が再実行されます。今後のアップデートでこれらのギャップを埋めるべく取り組んでいます。
手動実行を開始するときに、パイプラインのいくつかの段階をスキップしたい場合があります。たとえば、本番環境にデプロイしたくない場合、または本番環境のいくつかの環境へのデプロイをスキップする場合などです。YAMLパイプラインでこれを行うことができるようになりました。
更新された実行パイプラインパネルには、YAMLファイルのステージのリストが表示され、これらのステージの1つ以上をスキップするオプションがあります。ステージをスキップするときは注意が必要です。たとえば、最初のステージで後続のステージに必要な特定のアーティファクトが生成される場合、最初のステージをスキップしないでください。ダウンストリームの依存関係があるステージをスキップすると、実行パネルに一般的な警告が表示されます。これらの依存関係が真のアーティファクト依存関係であるのか、展開の順序付けのためだけに存在するのかと言った判断はユーザーに任されています。
ステージをスキップすることは、ステージ間の依存関係を再配線することと同等です。スキップされたステージのすぐ下流の依存関係は、スキップされたステージの上流の親に依存します。実行が失敗し、失敗したステージを再実行しようとすると、その試行でも同じスキップ動作が行われます。スキップするステージを変更するには、新しい実行を開始する必要があります。
スプリントバーンダウンが帰ってきました！少し前に、スプリントバーンダウンとタスクボードヘッダーからコンテキスト内スプリントバーンダウンを削除しました。戻して欲しいというフィードバックが多かったため、スプリントのバーンダウンサムネイルを改善し、再び提供しています。
サムネイルをクリックすると、すぐにグラフの拡大版が表示され、Analyticsタブで完全なレポートを表示するオプションが表示されます。完全なレポートに加えられた変更は、ヘッダーに表示されるグラフへ反映されます。残りの作業量だけでなく、ストーリー、ストーリーポイント、またはタスク数に基づいたバーンダウンが構成できるようになりました。
チームに依存しないダッシュボードが作れるようになりました。ダッシュボードを作成する時に、Project Dashboardタイプを選んでください。
Project Dashboardはチームダッシュボードに似ていますが、チームに関連付けられておらず、誰がダッシュボードを編集/管理できるかを決定できます。チームダッシュボードのように、プロジェクトの全員に表示されます。
チームコンテキストを必要とするすべてのAzure DevOpsウィジェットが更新され、構成内のチームを選択できるようになりました。これらのウィジェットをプロジェクトダッシュボードに追加して、必要な特定のチームを選択できます。
注意
カスタムウィジェットまたはサードパーティウィジェットの場合、プロジェクトダッシュボードはデフォルトチームのコンテキストをそれらのウィジェットに渡します。チームコンテキストに依存するカスタムウィジェットがある場合は、構成を更新してチームを選択できるようにする必要があります。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Jeff Beehler