Copy Dashboardのプレビューに長い間待望されていた機能強化についてお知らせできることをうれしく思います。ダッシュボードを別のチーム、同じチーム、または別のプロジェクトにコピーできるようになり、チームとクエリの構成は新しいダッシュボード用に自動更新されます。これにより、複数のチームのために同様のダッシュボードを一から構築する作業をさらに最小限に抑えることができます。
詳細については、以下の機能説明をご覧ください。
- タスク単位で自動リトライができるようになりました
- 他のタスクに注入可能なデコレーターをサポートしました
- サービス接続の使用履歴を改善しました
- クラッシックパイプライン作成時のデフォルトエージェントをWindows-2019に変更いたします
Azure DevOpsでAzure ADのテナントポリシーを構成するために必要なAzure DevOps Administratorロールが、Azure ADグループに割り当てられるようになりました。Azure ADグループを使用してAzure ADのロール割り当てを管理する方法については、こちらを参照してください。
パイプラインでまれに失敗する欠陥のあるタスクがある場合、そのタスクを成功させるためにパイプラインを再実行しなければならないことがあります。ほとんどの場合、不具合のあるタスクやスクリプトに対処する最善の方法は、そのタスクやスクリプト自体を修正することです。たとえば、テストの不具合が原因でテスト タスクがパイプラインで失敗した場合、不具合のあるテストを修正して信頼性を高めることは常に良いアイデアです。同様に、スクリプトがたまに失敗する場合は、スクリプト内に再試行機能を導入するなどして、スクリプトを修正するのがよいでしょう。
しかし、場合によってはタスクを再試行したいこともあります。よくあるユースケースは、パッケージ（Nuget、npmなど）をダウンロードするタスクです。これらのタスクは、ネットワークの障害やパッケージホスティングサーバーの一時的な障害の影響を受けやすいことがよく知られています。このような障害が発生した場合、パイプライン全体を再起動することなく、自動的に再試行することができればよいとのご意見をいただきました。
ご意見を受けて、パイプライン内のタスクが失敗したときに自動的に再試行する機能を追加しました。YAMLパイプラインを使用している場合は、この入力を以下のように設定します。
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...クラッシックビルドパイプラインやリリースパイプラインを使用している場合は、タスクの制御オプションでこのプロパティを設定できます。
再試行を使用する際の注意点は以下のとおりです。
- 失敗したタスクは直ちに再試行されます。
- 失敗したタスクは直ちに再試行されます。タスクの冪等性は仮定されません。タスクに副作用がある場合（たとえば、外部リソースを部分的に作成した場合など）、2回目の実行時に失敗する可能性があります。
- タスクが利用できるリトライ回数に関する情報は提供されません。
- タスクのログには、再試行される前に失敗したことを示す警告が追加されます。
- タスクを再試行するすべての試みは、同じタスクノードの一部としてUIに表示されます。
以前パイプライン内の対象タスクの前に、タスクを自動的に注入する機能を追加しました。今回はその機能を強化し、対象となるタスクの入力パラメータを使って、注入されるタスクをカスタマイズできるようにしました。この機能を実現するデコレーターを書くための構文は以下の通りです。
{
"contributions": [
{
"id": <my-required-task>,
"type": "ms.azure-pipelines.pipeline-decorator",
"targets": [
"ms.azure-pipelines-agent-job.pre-task-tasks",
"ms.azure-pipelines-agent-job.post-task-tasks"
],
"properties": {
"template": "my-decorator.yml",
"targettask": <target-task-id>,
"targettaskinputs": ["<name of input>"]
}
}
],
...
}この機能は、インジェクションの対象としてpre-task-tasksまたはpost-task-tasksを使用し、contributionのpropertiesセクションでtargettaskを指定した場合にのみ機能します。次に、targettaskinputsというプロパティを追加して、対象タスクが受け入れる入力パラメータ名のリストを指定します。これらの入力は、注入されたタスクが利用できるようになります。
このようなシナリオで実現できる一般的なユースケースは以下の通りです。ビルドによって公開されているアーティファクトの名前を自動的にログに記録するタスクを注入したいとします。アーティファクトの名前は、PublishBuildArtifactsタスクの入力です。あなたが注入したタスクは、同じ入力パラメータを取得し、それをログに使用できます。
パイプラインがservice connectionを使用すると、その使用状況が接続の履歴に記録されます。サービス接続の管理者は、プロジェクト設定を開き、適切なサービス接続を選択することで、使用履歴を確認できます。サービス接続の使用履歴にはいくつかの問題がありましたが、今回のアップデートで修正されました。修正された内容は次のとおりです。
- サービス接続を（通常のジョブではなく）deployment jobで使用すると、その使用状況が記録されないという問題がありました。
- パイプラインの複数のステージで複数のサービス接続を使用した場合、一部のステージがスキップされていても、すべてのサービス接続の使用履歴が記録されていました。
前回のリリースノートでは、vs2017-win2016ホストイメージの非推奨スケジュールを発表しました。それに備えて、Classic pipelinesで新規パイプラインを作成する際のデフォルトのエージェント仕様をwindows-2019に変更することになりました。
Copy Dashboardのフェーズ2パブリックプレビューを発表します。Queriesとconfigurationがコピー操作で引き継がれるようになりました。いくつかの問題を解決するのに予想以上に時間がかかりましたが、ご理解いただきありがとうございました。
プレビューは、デフォルトではダッシュボードコピーの改善機能フラグ（preview featuresの下）でオンになっています。
ダッシュボードをコピーするには、まず、コピーしたいダッシュボードに行きます。次に、メニューをクリックしてCopy Dashboardを表示させ、それをクリックします。
次に、新しいダッシュボードの名前と説明を入力し、ダッシュボードのタイプをTeamまたはProjectから選択します。Team Dashboardを選択する場合は、新しいプロジェクトとチームをそれぞれのドロップダウンボックスから選択します。Project Dashboardの場合は、プロジェクトのみが必要です。
Createボタンをクリックすると、新しく作成されたダッシュボードが表示されます。ウィジェットとレイアウトは同じです。
裏では、新しいダッシュボードの名前が付いたフォルダーがShared Queriesに作成されます。新しいダッシュボードのすべてのクエリがそのフォルダーにコピーされます。クエリ名は同じままです。チーム構成を持つウィジェットが新しいチームで更新されます。チーム構成を持つウィジェットは、Team DashboardからProject Dashboardにコピーされても、元の構成が維持されます。
バーンダウンチャートウィジェットのField Criteriaにおいて、null値をフィルタリングできるようになりました。この仕様は同じフィールド基準を使用するクエリと同じです。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Aaron Hallberg