リポジトリとコンテナーリソース定義でのテンプレート式のサポート

[アーティクル]
07/20/2023

この更新プログラムでは、リポジトリとコンテナーリソース定義にテンプレート式のサポートが含まれていました。 YAML パイプラインでリソースのrepositoryプロパティをref定義するときにテンプレート式を使用して、リポジトリリソースのブランチを選択できるようになりました。さらに、YAML パイプラインでリソースの、、volumesports、および options プロパティを定義するときにendpoint、テンプレート式のcontainerサポートを追加しました。

詳細については、リリースノートを参照してください。

Azure Pipelines

リポジトリリソース定義のテンプレート式
コンテナーリソース定義のテンプレート式
承認に対する変更の監査イベント
タスクライブラリでエージェントホスティングモデルを公開する

Azure Boards

作業項目のリンクの種類を編集する

以前は、作業項目のリンクを変更するには、少なくとも 3 つの手順が必要でした。たとえば、親リンクを関連リンクに変更するには、作業項目 ID をコピーし、親リンクを削除し、関連する種類の新しい既存のリンクを追加し、最後にコピーした ID を貼り付けて保存する必要があります。面倒なプロセスです。

リンクの種類を直接編集および変更できるようにすることで、問題を解決しました。リンクの種類は、1 つの手順ですばやく変更できます。

GIF を使用して作業項目のリンクの種類を編集します。する

Note

この機能は、 新しい Boards Hubs プレビューでのみ使用できます。

一時的なクエリ REST エンドポイントを作成する

拡張機能の作成者が、クエリ文字列を介して作業項目クエリ言語 (WIQL) ステートメントを渡すことで、未保存のクエリを実行しようとするインスタンスがいくつか見られます。これは、クエリ文字列の長さに関するブラウザーの制限に達する大きな WIQL ステートメントがない限り、正常に動作します。これを解決するために、ツール作成者が一時的なクエリを生成できるように、新しい REST エンドポイントを作成しました。応答の ID を使用して querystring を介して渡すと、この問題は解消されます。

詳細については、一時クエリ REST API のドキュメントページを参照してください。

バッチ削除 API (プライベートプレビュー)

現在、ごみ箱から作業項目を削除する唯一の方法は、この REST API を使用して一度に 1 つずつ削除することです。これは遅いプロセスである可能性があり、何らかの質量クリーンを実行しようとするとレート制限の対象になります。これに対して、作業項目をバッチで削除または破棄するための新しい REST API エンドポイントを追加しました。

この新しいエンドポイントのプライベートプレビューへの参加に関心がある場合は、直接メールでお問い合わせください。

@CurrentIteration 配信プランのマクロ

この更新プログラムでは、配信プランのスタイルの @CurrentIteration マクロのサポートが追加されました。このマクロを使用すると、プランの各行のチームコンテキストから現在のイテレーションを取得できます。

配信プランで CurrentIteration マクロをデモする Gif。

Azure Pipelines

リポジトリリソース定義のテンプレート式

YAML パイプラインでリソースのプロパティを定義するときに ref 、 repository テンプレート式のサポートを追加しました。これは、Developer Communityによって高く要求された機能でした。

パイプラインで同じリポジトリリソースのさまざまなブランチをチェックするユースケースが存在します。

たとえば、独自のリポジトリを構築するパイプラインがあるとします。そのためには、リソースリポジトリからライブラリをチェックする必要があります。さらに、パイプラインで、それ自体が使用しているのと同じライブラリブランチをチェックするとします。たとえば、パイプラインがブランチでmain実行されている場合は、ライブラリリポジトリのブランチをmainチェックする必要があります。パイプラインがブランチでdev実行されている場合は、ライブラリブランチをチェックするdev必要があります。

今日まで、ブランチを明示的に指定してチェックし、ブランチが変更されるたびにパイプラインコードを変更する必要がありました。

これで、テンプレート式を使用して、リポジトリリソースのブランチを選択できるようになりました。パイプラインのメイン以外のブランチに使用する YAML コードの次の例を参照してください。

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

パイプラインを実行するときに、リポジトリに対してチェックするブランチをlibrary指定できます。

ビルドキュー時に拡張するテンプレートのバージョンを指定する

テンプレートは、コードの重複を減らし、パイプラインのセキュリティを向上させる優れた方法です。

一般的なユースケースの 1 つは、独自のリポジトリにテンプレートを格納することです。これにより、テンプレートとそれを拡張するパイプライン間の結合が減り、テンプレートとパイプラインを個別に簡単に進化させることができます。

手順の一覧の実行を監視するためにテンプレートを使用する次の例を考えてみましょう。テンプレートコードはリポジトリにあります Templates 。

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

リポジトリ FabrikamFiberにあるこのテンプレートを拡張する YAML パイプラインがあるとします。今日まで、リポジトリをテンプレートソースとして使用する場合、templatesリポジトリリソースのプロパティを動的に指定refすることはできませんでした。つまり、パイプラインを実行したブランチに関係なく、別のブランチからテンプレートを拡張してパイプラインと同じブランチ名からテンプレートを拡張する必要がある場合は、パイプラインのコードを変更する必要がありました。

リポジトリリソース定義でのテンプレート式の導入により、パイプラインを次のように記述できます。

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

これにより、パイプラインは、パイプラインが実行されるブランチと同じブランチでテンプレートを拡張するため、パイプラインのブランチとテンプレートのブランチが常に一致することを確認できます。つまり、パイプラインをブランチで実行すると、リポジトリのブランチdev内のファイルでtemplate.yml指定されたテンプレートがdevtemplates拡張されます。

または、次の 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 からテンプレートを 1 回の実行で拡張し、別の実行でブランチ main からテンプレートを拡張できます。

リポジトリリソースのプロパティにテンプレート式を ref 指定する場合は、とシステムの定義済み変数を使用 parameters できますが、YAML または Pipelines UI で定義された変数を使用することはできません。

コンテナーリソース定義のテンプレート式

YAML パイプラインでリソースの、portsvolumesおよび options プロパティをendpoint定義するときに、テンプレート式のcontainerサポートが追加されました。これは、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'

テンプレート式では、と variables. を使用parameters.できます。変数の場合、YAML ファイルで定義されているもののみを使用できますが、Pipelines UI で定義されているものは使用できません。たとえば、エージェントログコマンドを使用して変数を再定義した場合、影響はありません。

承認に対する変更の監査イベント

承認を使用すると、ステージを実行するタイミングを制御できます。これは、運用環境へのデプロイを制御するために一般的に使用されます。監査を使用すると、コンプライアンス要件を満たし、Azure DevOps organizationのセキュリティを監視できます。

特定のステージにデプロイするためのパイプラインの承認をユーザーに求められたら、そのユーザーは承認を他のユーザーに再割り当てすることを選択できます。

承認に対する変更の監査イベント

これまで、このようなアクションは監査ログに記録されませんでした。この問題は現在修正されています。

監査ログには、次のようなエントリが含まれます。

[
    {
        "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"
    }
]

さらに、監査 UI に表示されます。

監査 UI のログエントリ

タスクライブラリでエージェントホスティングモデルを公開する

エージェントが Microsoft ホスト型プールで実行されているかどうかを判断するタスク作成者は、タスクライブラリ関数 getAgentMode() を使用してホスティングモデルを決定できるようになりました。これは、タスクが顧客のネットワークにアクセスするかどうかに基づいて動作に影響を与える必要があるシナリオで役立ちます。タスクは、顧客のネットワークに存在するセルフホステッドエージェントまたはスケールセットエージェントから実行された場合、プライベートエンドポイント経由で Azure サービスに到達しようとする場合があります。「タスクリファレンス」を参照してください。

次の手順

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に進み、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能についてご意見をお聞かせください。ヘルプメニューを使用して、問題を報告したり、提案を提供したりします。

ご提案の送信

Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。

よろしくお願いします。

ヴィジャイ・マクラジュ

リポジトリとコンテナー リソース定義でのテンプレート式のサポート

Azure Boards

Azure Pipelines

Azure Boards

作業項目のリンクの種類を編集する

一時的なクエリ REST エンドポイントを作成する

バッチ削除 API (プライベート プレビュー)

@CurrentIteration 配信プランのマクロ

Azure Pipelines

リポジトリ リソース定義のテンプレート式

ビルド キュー時に拡張するテンプレートのバージョンを指定する

コンテナー リソース定義のテンプレート式

承認に対する変更の監査イベント

タスク ライブラリでエージェント ホスティング モデルを公開する

次の手順

フィードバックの提供方法

フィードバック

フィードバック

その他のリソース

リポジトリとコンテナーリソース定義でのテンプレート式のサポート

バッチ削除 API (プライベートプレビュー)

リポジトリリソース定義のテンプレート式

ビルドキュー時に拡張するテンプレートのバージョンを指定する

コンテナーリソース定義のテンプレート式

タスクライブラリでエージェントホスティングモデルを公開する