管理者
すべてのパブリック API を PAT スコープに関連付ける
スコープの使用は、 個人用アクセス トークン (AT) によってもたらされるリスクを制限する優れた方法です。 また、管理者が フル スコープの PAT の作成を完全に制限できるポリシーもあります。
ただし、一部のパブリック API は現在 PAT スコープと関連付けされておらず、"フル スコープ" の PAT でのみ使用できます。 このため、フル スコープの AT の作成を制限すると、一部のワークフローがブロックされる可能性があります。 Microsoft では、すべてのパブリック API を特定し、文書化し、適切なスコープに関連付ける作業を行っています。
Pipelines
パイプラインのスケーラビリティの向上
YAML パイプラインの使用は、上位のお客様の間で引き続き増加しています。 同時に、パイプラインの複雑さは、ステージ、ジョブ、ステップ、条件、チェック、テンプレートの数の点でも増加し続けます。 これにより、はるかに大きなオーケストレーション グラフが作成されます (各パイプラインの実行を追跡するために内部的に使用するデータ構造)。 これらのグラフ サイズの爆発的なもう 1 つの理由は、クラシック リリース パイプラインから YAML パイプラインへの移行です。 クラシック リリースでは、各ステージは個別のオーケストレーション グラフとして処理されました。 YAML パイプラインでは、実行全体が 1 つのオーケストレーション グラフです。
長年にわたって行われたさまざまなアーキテクチャの選択の結果として、私たちは一部の最大の顧客に対していくつかのサポート ケースに取り組んでいます。 これらの問題は、毎日数千のジョブを実行し、オーケストレーション グラフの複雑さが高い場合にのみ発生します。 この取り組みでは、オーケストレーション エンジンのスケーラビリティを向上させるために、いくつかのアーキテクチャの改善に取り組みます。 これは、次のボトルネックを減らすのに役立ちます。
- パイプライン実行ごとに数百のアクティビティ ノードを実行する
- データベースにアクセスして大きなグラフを格納または取得する
- ステージ間のチェックに対する多数の再実行を行うこと