今回の更新で、リポジトリとコンテナリソース定義におけるテンプレート式のサポートが追加されました。これにより、YAML パイプラインでrepositoryリソースのrefプロパティを定義する際にテンプレート式を使用して、リポジトリ リソースのブランチを選択できるようになりました。さらに、YAMLパイプラインでcontainerリソースのendpoint、volumes、port、optionのプロパティを定義する際に、テンプレート式をサポートするようになりました。
詳しくは、リリースノートをご覧ください。
- Work itemのリンクタイプの編集が簡単になりました
- temporary queryを作成するためのRESTエンドポイントを用意いたしました
- Batch delete APIのPrivate Previewを開始します
- Delivery Plansで@CurrentIterationマクロをサポートします
- Repository Resource定義でTemplate式の記述が可能になりました
- Container Resource定義でTemplate式の記述が可能になりました
- ビルドキュー投入時に特定のバージョンのテンプレートの参照ができるようになりました
- Approvals(承認)でのAudit Eventの挙動が変更されました
- Task libraryでAgent提供モデルの判定ができるようになりました
今まで、Work itemリンクの変更には少なくとも3つのステップが必要でした。例えば、親リンクを関連リンクに変更するには、ワークアイテムIDをコピーし、親リンクを削除し、関連タイプの既存のリンクを新規に追加し、最後にコピーしたIDを貼り付けて保存する必要があります。これは面倒な作業です。
そこで、リンクタイプを直接編集・変更できるようにすることで、この問題を解決しました。たった一度の操作で、素早くリンクタイプの変更が可能です。
注意事項
この機能はNew Boards Hubs previewを有効にする必要があります。
拡張機能の作者が、WIQL（Work Item Query Language）ステートメントをクエリ文字列で渡して、保存されていないクエリを実行しようとする例をいくつか見かけました。これは、クエリ文字列の長さがブラウザの制限に達するような大きな WIQL ステートメントでない限り、うまくいきます。これを解決するために、ツールの作者が一時的なクエリを生成できるように、新しいRESTエンドポイントを作成しました。レスポンスに含まれるidをクエリ文字列として使用することで、この問題を解決することができます。
詳しくは、temp queries REST API documentation pageをご覧ください。
現在、ごみ箱からワークアイテムを削除するには、このREST APIを使用して一度にひとつずつ削除するしかありません。この方法では、処理に時間がかかり、大量に削除しようとするとレート制限を受ける可能性があります。そこで、ワークアイテムを一括で削除・破棄するための新しいREST APIエンドポイントを追加しました。
この新しいエンドポイントのプライベートプレビューに参加することに興味がある方は、私たちに直接メールを送ってください。
今回の更新で、Delivery Plansのスタイルに @CurrentIteration マクロのサポートが追加されました。このマクロにより、計画のチーム コンテキストの各行から現在のイテレーションの取得が可能になります。
YAMLパイプラインでrepositoryリソースのrefプロパティを定義する際に、テンプレート式をサポートします。これはDeveloper Communityから強く要望されていた機能です。
パイプラインで同じリポジトリリソースの異なるブランチをチェックアウトしたい、というユースケースが存在します。
例えば、独自のリポジトリを構築するパイプラインがあり、そのためにリソースリポジトリからライブラリをチェックアウトする必要があるとします。さらに、パイプラインは自分自身が使っているのと同じライブラリーのブランチをチェックアウトするようにしたいとします。例えば、パイプラインがmainブランチで動作している場合、ライブラリリポジトリのmainブランチをチェックアウトする必要があります。パイプラインがdevブランチで実行されている場合は、devライブラリブランチをチェックアウトしたいといった状況です。
これまでは、チェックアウトするブランチを明示的に指定し、ブランチが変更されるたびにパイプラインのコードを変更する必要がありました。
今回の更新で、テンプレート式を使ってリポジトリリソースのブランチの選択が可能となりました。パイプラインの非メインブランチに使用する YAML コードの例を以下に示します。
resources:
repositories:
- repository: library
type: git
name: FabrikamLibrary
ref: ${{ variables['Build.SourceBranchName'] }}
steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.shパイプラインの実行時に、libraryリポジトリをチェックアウトするブランチを指定できます。
Templateは、コードの重複を減らし、パイプラインのセキュリティを向上させるための素晴らしい方法です。
一般的な使用例としては、テンプレートを独自のリポジトリに格納することが挙げられます。これにより、テンプレートとそれを拡張するパイプラインの間の結合を減らし、テンプレートとパイプラインを独立して進化させることが容易になります。
次の例では、あるテンプレートを使って、ステップのリストの実行を監視しています。テンプレートのコードは Templatesリポジトリにあります。
# template.yml in repository Templates
parameters:
- name: steps
type: stepList
default: []
jobs:
- job:
steps:
- script: ./startMonitoring.sh
- ${{ parameters.steps }}
- script: ./stopMonitoring.shFabrikamFiberリポジトリにあるこのテンプレートを拡張するYAMLパイプラインがあるとします。これまで、テンプレートソースとしてリポジトリを使用する場合、templatesのリポジトリリソースのrefプロパティを動的に指定することはできませんでした。つまり、パイプラインを実行するブランチに関係なく、別のブランチのテンプレートを拡張したい場合、パイプラインのコードを変更する必要がありました。
リポジトリリソース定義にテンプレート式を導入することで、パイプラインを以下のように記述できます。
resources:
repositories:
- repository: templates
type: git
name: Templates
ref: ${{ variables['Build.SourceBranchName'] }}
extends:
template: template.yml@templates
parameters:
steps:
- script: echo ./build.sh
- script: echo ./test.shこのように書くことで、パイプラインが実行されるブランチと同じブランチにあるテンプレートで拡張するため、パイプラインのブランチとテンプレートのブランチを常に一致します。つまり、devブランチでパイプラインを実行すると、テンプレートリポジトリのdevブランチにあるtemplate.ymlファイルによって指定されたテンプレートを拡張します。
あるいは、YAMLコードを以下のように書くことで、ビルドキュー時にどのテンプレートリポジトリのブランチを使用するかという選択も可能です。
parameters:
- name: branch
default: main
resources:
repositories:
- repository: templates
type: git
name: Templates
ref: ${{ parameters.branch }}
extends:
template: template.yml@templates
parameters:
steps:
- script: echo ./build.sh
- script: echo ./test.shこのため、パイプラインのコードを変更することなく、mainブランチのパイプラインでdevブランチのテンプレートを拡張し、別の実行でmainブランチのテンプレートを拡張することができるようになりました。
リポジトリリソースのrefプロパティにテンプレート式を指定する場合、parametersやシステム定義済みの変数は使用できますが、YAMLやPipelinesのUIで定義された変数は使えないので、注意してください。
YAML パイプラインでcontainerリソースのendpoint、volume、ports、およびoptionsプロパティを定義する際に、テンプレート式をサポートするようになりました。これは、Developer Communityから非常にリクエストの多かった機能です。
今回の更新で、以下のようなYAMLパイプラインの記述が可能になりました。
parameters:
- name: endpointName
default: AzDOACR
type: string
resources:
containers:
- container: linux
endpoint: ${{ parameters.endpointName }}
image: fabrikamfiber.azurecr.io/ubuntu:latest
jobs:
- job:
container: linux
steps:
- task: CmdLine@2
inputs:
script: 'echo Hello world'テンプレート式では、parameter..とvariables.が使用可能です。variablesについては、YAMLファイルで定義されたもののみ使用可能で、Pipelines UIで定義されたものは使用できません。エージェントのログコマンドなどを使って変数を再定義しても、何の効果もありません。
Approvalsは、ステージがいつ実行されるべきかを制御できます。これは、一般的に本番環境へのデプロイメントを制御するために使用されます。Auditingにより、コンプライアンス要件を満たし、Azure DevOps organizationのセキュリティの監が可能です。
ユーザーが特定のステージにデプロイするパイプラインを承認するよう求められたとき、そのユーザーは承認を他の誰かに再割り当てするか、選択可能です。
これまでは、このようなアクションはAuditログに記録されませんでした。この問題は現在修正されています。
Auditログには、以下のようなエントリーが含まれるようになります。
[
{
"Id": "2517368925862632546;00000264-0000-8888-8000-000000000000;839ad1ba-f72b-4258-bc3f-88be7a4553b5",
"CorrelationId": "8392d1ba-f76b-4258-bc3f-88be7a4553b5",
"ActivityId": "a298a06c-965f-4e60-9643-2593f2066e37",
"ActorCUID": "fe950802-bf07-755b-826d-e8dcc066252c",
"ActorUserId": "fe950802-bf07-755b-826d-e8dcc066252c",
"ActorUPN": "silviu@fabrikam.app",
"AuthenticationMechanism": "AAD_Cookie",
"Timestamp": "2022-10-10T11:26:53.7367453Z",
"ScopeType": "Organization",
"ScopeDisplayName": "Fabrikam (Organization)",
"ScopeId": "547a7316-cdf4-40d2-af16-3215f97d053e",
"ProjectId": "4bf16944-3595-421f-9947-79d9eb190284",
"ProjectName": "FabrikamFiber",
"IpAddress": "127.0.0.1",
"UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.37",
"ActionId": "ApproverReassigned",
"Data": {
"ApprovalId": "dae6e7c9-2a10-4cd8-b63a-579a6e7ba78d",
"OldApproverUserId": "692b6e2a-dd61-4872-866a-85498da390fc",
"OldApproverDisplayName": "[FabrikamFiber]\\Build Administrators",
"NewApproverUserId": "fe95080b-bf07-655b-226d-e8dcc066252c",
"NewApproverDisplayName": "Jack Fabrikam",
"Comment": "All admins are OOO"
},
"Details": "Reassigned approver of Approval dae6e7c9-9a10-4cd8-b63a-579a6e7ba78d in Project \"FabrikamFiber\" from \"[FabrikamFiber]\\Build Administrators\" to \"Jack Fabrikam\" with comment \"All admins are OOO\".",
"Area": "Checks",
"Category": "Modify",
"CategoryDisplayName": "Modify",
"ActorDisplayName": "Silviu"
}
]さらに、Audit UIに表示されるようになります。
エージェントがMicrosoftホストプールで実行されているかどうかを判断したいタスクオーナーは、Task Library関数getAgentMode()を使用して、ホスティングモデルを判断できるようになりました。これは、タスクが顧客のネットワークにアクセスできるかどうかに基づいて動作に影響を与えたいシナリオで有益です。タスクは、セルフホストエージェントまたは顧客のネットワークに存在するスケールセットエージェントから実行される場合、プライベートエンドポイントを介してAzureサービスへのアクセスができるという判断が可能になります。タスクのリファレンスを参照してください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
Azure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Vijay Machiraju