サービス接続やエージェントプールのように、Azure GitリポジトリをYAMLパイプラインで保護されたリソースとして扱うことができるようになりました。レポジトリーのコントリビューターとして、チェックやパイプラインの権限を追加して、リポジトリの管理に役立てることができます。
詳細については、以下の機能説明を確認してください。
このたび、Personal Access Tokens（PAT）のライフサイクル管理APIを一般提供されます。この豊富なAPIセットにより、お客様のチームは所有するPATの管理を簡素化できるようになり、希望する範囲や期間で新しいパーソナル・アクセス・トークンを作成したり、既存のPATを更新したり期限切れにしたりするといった、新しい機能を提供します。
今まで、PAT（Personal Access Tokens）を管理する方法として、主にUIや、プロジェクトコレクション管理者向けに限定されたAPIを提供していました。この新しいAPIを使うことで、組織がビルドパイプラインの設定やワークアイテムとのやりとりといった、PATに関わる自動化を設定できるようになります。
Delivery Plans 2.0は、昨年10月にパブリックプレビューを開始しました。お客様からのフィードバックをもとに、問題点を解決してきました。今回のリリースでは、それらの問題の修正が含まれています。具体的には、一貫性のない拡大やスクロールバーのフリーズなどが修正されています。カードは、プラン上のスペースをより有効に使うために、バックログの優先順位ではなく、日付順に並べられます。
Azure DevOpsプロジェクトでは、それぞれが独自のAzure DevOps Gitリポジトリと1つまたは複数のパイプラインを持つ、多くのサブプロジェクトが提供可能です。この構造では、どのパイプラインがどのリポジトリにアクセスできるかを制御したい場合があります。たとえば、同じプロジェクトに2つのリポジトリAとBがあり、これらのリポジトリを通常構築する2つのパイプラインXとYがあるとします。パイプラインYがリポジトリAへアクセス不可としたい場合があります。一般的には、Aのコントリビューターがどのパイプラインにアクセスを提供するかを制御したいと考えています。
これは、Azure Gitリポジトリーとパイプラインで部分的には可能でしたが、それを管理するためのUIがありませんでした。この機能は、そのギャップを解消するものです。Azure Gitリポジトリーは、サービス接続やエージェントプールのように、YAMLパイプラインで保護されたリソースとして扱うことができるようになりました。
レポAのコントリビューターとして、チェックとパイプラインのパーミッションをリポジトリに追加できます。これを行うには、プロジェクト設定に移動し、"Repositories"を選択し、自分のリポジトリを選択します。"Checks"という新しいメニューが表示されます。ここでは、すぐに使える検証機能や、Azure Functionsを使った独自の検証機能が設定できます。
"Security"タブでは、リポジトリーにアクセスできるパイプラインのリストを管理可能です。
YAMLパイプラインがリポジトリーを使用するたびに、Azure Pipelinesインフラストラクチャが、すべてのチェックと権限が満たされているかどうかを検証し、確認します。
注意事項
これらのパーミッションとチェックは、YAMLパイプラインにのみ適用されます。Classicなパイプライン（訳注:GUI使う旧来のパイプライン）ではこれらの新機能は使用できません。
今回の更新では、リテンションポリシーから外れたアーティファクトをごみ箱を空にして、永久削除できるようになりました。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Vijay Machiraju