コピー ダッシュボードプレビューに対して待望の機能強化をお知らせします。 ダッシュボードを別のチーム、同じチーム、または別のプロジェクトにコピーできるようになりました。チームとクエリの構成は新しいダッシュボードで更新されます。 これにより、複数のチームに対して同様のダッシュボードをゼロから構築するために必要な作業がさらに最小限に抑えられます。
詳細については、次の機能の説明を参照してください。
全般
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>"]
}
}
],
...
}
この機能は、挿入のターゲットとして pre-task-tasks または post-task-tasks を使用し、コントリビューションのプロパティ セクションで targettask を指定する場合にのみ機能します。 その後、 targettaskinputs というプロパティを追加し、ターゲット タスクで受け入れられる入力パラメーター名の一覧を指定できます。 これらの入力は、挿入されたタスクで使用できるようになりました。
このようなシナリオで実現できる一般的なユース ケースは次のとおりです。 たとえば、ビルドによって発行される成果物の名前を自動的にログに記録するタスクを挿入するとします。 成果物の名前は、 PublishBuildArtifacts タスクへの入力です。 挿入されたタスクは、同じ入力パラメーターを取得し、ログ記録に使用できるようになりました。
サービス接続の使用履歴の機能強化
パイプラインが サービス接続を使用すると、その使用状況が接続の履歴に記録されます。 サービス接続の管理者は、プロジェクト設定に移動し、適切なサービス接続を選択することで、使用履歴を確認できます。 この更新プログラムで修正されたサービス接続の使用履歴には、いくつかの問題がありました。 修正プログラムには、次のものがあります。
- (通常のジョブではなく) デプロイ ジョブ でサービス接続が使用されている場合、その使用状況はログに記録されませんでした。
- パイプラインの複数のステージで複数のサービス接続を使用した場合、一部のステージがスキップされた場合でも、すべてのサービス接続で使用履歴にレコードが表示されます。
クラシック パイプラインの既定のエージェント仕様が Windows-2019 になりました
最後のリリース ノートでは、ホストされているイメージの廃止スケジュールvs2017-win2016。 その準備として、クラシック パイプラインで新しいパイプラインを作成するときに、既定のエージェント仕様を windows-2019 に変更します。
レポーティング
コピー ダッシュボードの機能強化
コピー ダッシュボードのフェーズ 2 パブリック プレビューをお知らせします。 これで、コピー操作でクエリと構成が引き継がれようになりました。 問題の一部を解決するために予想よりも少し時間がかかりましたので、あなたの忍耐をありがとう。
プレビューは、ダッシュボード エクスペリエンスのコピー 機能フラグ (プレビュー機能の下) で既定でオンになっています。
ダッシュボードをコピーするには、まずコピーするダッシュボードに移動します。 次に、メニューをクリックして ダッシュボードのコピー を表示し、それをクリックします。
次に、新しいダッシュボードの名前と説明を入力し、ダッシュボードの種類 (チームまたはプロジェクト) を選択します。 チーム ダッシュボードを選択すると、それぞれのドロップダウン ボックスから新しいプロジェクトとチームが選択されます。 プロジェクト ダッシュボードの場合は、プロジェクトのみが必要です。
[ 作成 ] ボタンをクリックすると、新しく作成されたダッシュボードに移動します。 ウィジェットとレイアウトは変わりません。
バックグラウンドで、新しいダッシュボードの名前を持つフォルダーが 共有クエリに作成されます。 新しいダッシュボードのすべてのクエリがそのフォルダーにコピーされます。 クエリ名は変わりません。 チーム構成のウィジェットは、新しいチームで更新されます。 チームダッシュボードからプロジェクトダッシュボードにコピーされるチーム構成のウィジェットは、元の構成を保持します。
バーンダウン グラフ ウィジェットで null 値をフィルターする
バーンダウン グラフ ウィジェットでフィールド抽出条件を使用するときに、null 値でフィルター処理できるようになりました。 この動作は、同じフィールド条件を使用するクエリと一致するようになりました。
次のステップ
注
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に向かい、見てみましょう。
フィードバックの提供方法
これらの機能についてご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
アーロン・ハルベルク