ダッシュボードのコピーの機能強化
コピー ダッシュボード プレビューに対して待望の機能強化をお知らせします。 ダッシュボードを別のチーム、同じチーム、または別のプロジェクトにコピーできるようになり、チームとクエリの構成が新しいダッシュボードで更新されます。 これにより、複数のチームに対して同様のダッシュボードをゼロから構築するために必要な作業がさらに最小限に抑えられます。
詳細については、次の機能の説明を参照してください。
全般
Azure Pipelines
レポート
全般
Azure DevOps 管理者ロールを Azure AD グループに割り当てる
Azure DevOps で Azure AD テナント ポリシーを構成するために必要な Azure DevOps 管理者ロールを、Azure AD グループに割り当てることができるようになりました。 Azure AD グループを使用して Azure AD でロールの割り当てを管理する方法の詳細を確認してください。
Azure Pipelines
タスクの自動再試行
パイプラインで断続的に失敗する不安定なタスクがある場合は、パイプラインを再実行して成功させる必要がある場合があります。 ほとんどの場合、不安定なタスクまたはスクリプトに対処する最善の方法は、タスクまたはスクリプト自体を修正することです。 たとえば、不安定なテストが原因でパイプラインでテスト タスクが失敗した場合は、常に薄いテストを修正し、より信頼性の高いテストにすることをお勧めします。 同様に、スクリプトがしばらくの間に失敗する場合は、スクリプト内で再試行を導入するなどの方法で、スクリプトを修正することをお勧めします。
ただし、タスクを再試行したい場合もあります。 この一般的なユース ケースは、パッケージ (NuGet、npm など) をダウンロードするタスクです。 多くの場合、これらのタスクはネットワーク障害や、パッケージ ホスティング サーバーでの一時的な障害の影響を受けやすいことが確認されています。 パイプライン全体を再起動することなく、このような失敗したタスクを自動的に再試行することをお勧めしますというフィードバックをお寄せください。
フィードバックに基づいて、失敗した場合にパイプライン内のタスクを自動的に再試行する機能が追加されました。 YAML パイプラインを使用する場合は、次のようにこの入力を設定できます。
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
クラシック ビルドまたはリリース パイプラインを使用する場合は、タスクのコントロール オプションでこのプロパティを設定できます。
再試行を使用する場合に注意すべき点を次に示します。
- 失敗したタスクはすぐに再試行されます。
- タスクのべき等性に関する想定はありません。 タスクに副作用がある場合 (たとえば、外部リソースが部分的に作成された場合など)、2 回目の実行時に失敗する可能性があります。
- タスクで使用できる再試行回数に関する情報はありません。
- 再試行前に失敗したことを示す警告がタスク ログに追加されます。
- タスクの再試行の試みはすべて、同じタスク ノードの一部として UI に表示されます。
注意
エージェント バージョン 2.194.0 以降が必要です。 エージェントレス タスクではサポートされていません。
デコレーターで別のタスクからの入力を使用する
最近、そのパイプライン内の別のターゲット タスクの前に、タスクをパイプラインに自動的に挿入する 機能 を追加しました。 現在、ターゲット タスクの入力パラメーターを使用して、挿入されたタスクをカスタマイズできるようにすることで、この機能を強化しています。 これを行うためのデコレーターを記述するための構文は次のとおりです。
{
"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>"]
}
}
],
...
}
この機能は、挿入のターゲットとして または post-task-tasks
を使用pre-task-tasks
し、コントリビューションのプロパティ セクションで をtargettask
指定する場合にのみ機能します。 その後、 という名前 targettaskinputs
の追加プロパティを追加し、ターゲット タスクで受け入れられる入力パラメーター名の一覧を指定できます。 これらの入力は、挿入されたタスクで使用できるようになりました。
このようなシナリオで実現できる一般的なユース ケースは次のとおりです。 たとえば、ビルドによって発行される成果物の名前を自動的にログに記録するタスクを挿入するとします。 成果物の名前は、タスクへの PublishBuildArtifacts
入力です。 挿入されたタスクは、同じ入力パラメーターを取得し、ログに使用できるようになりました。
サービス接続の使用履歴の機能強化
パイプラインが サービス接続を使用すると、その使用状況は接続の履歴に記録されます。 サービス接続の管理者は、プロジェクト設定に移動し、適切なサービス接続を選択することで、使用履歴を確認できます。 この更新プログラムで修正されたサービス接続の使用履歴には、いくつかの問題がありました。 修正プログラムには、次のものがあります。
- (通常のジョブではなく) デプロイ ジョブ でサービス接続が使用されている場合、その使用量はログに記録されませんでした。
- パイプラインの複数のステージで複数のサービス接続を使用した場合、一部のステージがスキップされた場合でも、すべてのサービス接続で使用履歴にレコードが表示されます。
クラシック パイプラインの既定のエージェント仕様が Windows-2019 になりました
最後のリリース ノートでは、ホストされているイメージの非推奨のスケジュールをvs2017-win2016
発表しました。 その準備として、クラシック パイプラインで新しいパイプラインを作成するときに、既定のエージェント仕様を に windows-2019
変更します。
レポート
コピー ダッシュボードの機能強化
コピー ダッシュボードのフェーズ 2 パブリック プレビューをお知らせします。 コピー操作でクエリと構成が引き継がれることができるようになりました。 問題の一部を解決するために予想よりも少し時間がかかったので、あなたの忍耐に感謝します。
プレビューは既定で [ ダッシュボード エクスペリエンスのコピー ] 機能フラグ (プレビュー機能の下) でオンになっています。
ダッシュボードをコピーするには、まずコピーするダッシュボードに移動します。 次に、メニューをクリックして [ダッシュボードのコピー ] を表示し、それをクリックします。
次に、新しいダッシュボードの名前と説明を入力し、ダッシュボードの種類として [チーム] または [プロジェクト] を選択します。 チーム ダッシュボードを選択すると、新しいプロジェクトとチームがそれぞれのドロップダウン ボックスから選択されます。 プロジェクト ダッシュボードの場合は、プロジェクトのみが必要です。
[作成] ボタンをクリックすると、新しく作成されたダッシュボードに 移動 します。 ウィジェットとレイアウトは変わりません。
バックグラウンドでは、新しいダッシュボードの名前を持つフォルダーが 共有クエリに作成されます。 新しいダッシュボードのすべてのクエリがそのフォルダーにコピーされます。 クエリ名は変わりません。 チーム構成のウィジェットは、新しいチームで更新されます。 チーム ダッシュボードからプロジェクト ダッシュボードにコピーされるチーム構成を含むウィジェットは、元の構成を保持します。
バーンダウン グラフ ウィジェットで null 値をフィルター処理する
バーンダウン グラフ ウィジェットで [フィールド条件] を使用するときに、null 値でフィルター処理できるようになりました。 この動作は、同じフィールド条件を使用するクエリと一致するようになりました。
次の手順
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に進み、見てみましょう。
フィードバックの提供方法
これらの機能についてご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
アーロン・ハルベルク