Azure DevOps のマネージド DevOps プール (プレビュー)

開発およびプラットフォーム エンジニアリング チームがカスタム DevOps プールを迅速に設定および管理できるように設計された、Managed DevOps プールのプレビューをお知らせします。

さらに、GitHub Advanced Security の測定使用量見積もり API が強化され、ユーザーの識別に役立つ新機能が提供されています。

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

GitHub Advanced Security for Azure DevOps

• Advanced Security Meter Usage API がユーザー ID を返すようになりました
• ビルドのない C# および Java プロジェクトの GitHub Advanced Security コード スキャン

Azure Pipelines

• マネージド DevOps プール (プレビュー)
• Azure Pipelines タスクで Node 20 を使用する
• ビルド パイプラインのアクセス許可を作成する
• ステージ レベルでの排他ロック チェック
• パイプライン実行のテンプレート情報
• 手動でトリガーされた YAML パイプライン ステージ

GitHub Advanced Security for Azure DevOps

Advanced Security Meter Usage API がユーザー ID を返すようになりました

高度なセキュリティ ユーザーの識別に役立つよう、測定使用量見積もり API は、表示名、CUID、電子メール識別子、ID 記述子など、各ユーザーの Azure DevOps ID を返すようになりました。 この機能は、組織、プロジェクト、リポジトリのレベルで使用できます。 この新しいエンドポイントを使用するには、構文は既存のメーター使用状況 API エンドポイントに似ています。エンドポイントに /details を追加します。

• 組織レベル: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
• プロジェクト レベル: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
• リポジトリ レベル: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

ビルドのない C# および Java プロジェクトの GitHub Advanced Security コード スキャン

CodeQL を使用したコード スキャンでは、リポジトリ内のコードを表す 1 つの言語のデータベースに対してクエリを実行する必要があります。 C/C++、C#、Go、Java、Swift などのコンパイル済み言語の場合、通常は最初にコードをビルドする必要があります。

ただし、GitHub Advanced Security for Azure DevOps の背後にある静的分析エンジンである CodeQL では、ビルドを必要とせずに C# および Java プロジェクトをスキャンできるようになりました。 ビルド モードが "none" に設定されている場合、 CodeQL データベースはコードベースから直接生成され、ビルド ステップはバイパスされます。

すべてのコンパイル済み言語で、既定のビルド モードは "manual"です。 ただし、C# と Java の場合、ビルド モードを "none" に変更できます。

ビルド モードは、AdvancedSecurity-Codeql-Init@1 セットアップ中に構成できます。 Azure DevOps を使用して GitHub Advanced Security でコード スキャンを構成する方法の詳細については、 コード スキャンの設定に関するページを参照してください。

配慮：

• "none"が選択され、サポートされている準拠言語 C# または Java 以外の言語が選択されている場合、パイプライン タスクが期待どおりに動作しない可能性があります。

• ビルド モード "none" は現在、他の解釈された言語 (JavaScript、Python、Ruby など) と組み合わせて動作します。

• 有効な例: ビルド モードが "none"に設定されている C# と JavaScript。" (解釈された言語での JavaScript)

• 無効な例: ビルド モードが "none" に設定されている C#、JavaScript、Swift (Swift はビルド モード "none"ではサポートされていません)。

Azure Pipelines

マネージド DevOps プール (プレビュー)

エンジニアリング チームは、ユーザー向けのアプリケーションとサービスを開発するコードの記述に集中できる場合に優れています。 ただし、実際には、DevOps インフラストラクチャの維持など、他のタスクの管理にかなりの時間がかかることがよくあります。

開発チームとプラットフォーム エンジニアリング チームが独自のニーズに合わせてカスタマイズされた DevOps プールをデプロイできるように設計された新しい Azure DevOps 機能である Managed DevOps Pools (MDP) のパブリック プレビューをお知らせします。 MDP では、スケール セット エージェントの柔軟性と、Microsoft がホストするエージェントに関連するメンテナンスの容易さを組み合わせることで、チームは一貫性とベスト プラクティスを確立しながら、パフォーマンス、セキュリティ、コンプライアンス、コスト効率を最適化できます。

マネージド DevOps プールの主な利点は次のとおりです。

• ユーザーに代わってホストされる: MDP は Microsoft によってホストおよび管理され、仮想マシンは、Microsoft 所有の Azure サブスクリプション内で作成および管理されるエージェントに電力を供給します。
• Management: MDP に費やされた時間により、エージェントの管理に費やす時間が大幅に短縮されます。特に、オンプレミスのインフラストラクチャまたは手動で管理されたシステムに基づくエージェントの管理に費やされる時間が大幅に短縮されます。
• 特定のプール: 新しいプールを簡単に作成できるため、組織は複数のチーム固有またはワークロード固有のプールを簡単に作成できます。
• DevOps Billing: MDP は、多くの機能を通じてチームの DevOps 課金を最適化するのに役立ちます。 これにより、チームはプールの QoS/パフォーマンスとコストの最適なバランスを簡単に見つけることができます。
• スケーラブル: MDP は、1 つのプール内の 1000 のエージェントにスケーリングされます。

Teams は、microsoft ホスト型エージェントに存在するのと同じソフトウェアを含む クイック スターター イメージ 、またはチームがシナリオに固有の前提条件で作成したイメージを含むプールを作成できます。

Managed DevOps プールの詳細については、 ブログの投稿 またはその ドキュメントを参照してください。

Azure パイプライン タスクで Node 20 を使用する

ほとんどのパイプライン タスクでは、ランナーとして Node が使用されます。 ランナーとして NodeJS を使用する Azure パイプライン タスクでは、すべて NodeJS 20 が使用されるようになりました。 タスク拡張機能の作成者は、Node 20 を使用するようにタスクを更新する必要があります。 アップグレード方法に関するガイダンスについては、「 カスタム タスクを最新の Node にアップグレードするにはどうすればよいですか?。

ビルド パイプラインのアクセス許可を作成する

パイプラインのセキュリティを強化するために、パイプライン レベルで新しいアクセス許可 ( Create build pipeline) を導入します。

以前は、パイプラインを作成または編集するには、 Edit build pipeline アクセス許可が必要でした。 これにより、パイプラインを作成する機能を持つすべてのユーザーが、自分が作成しなかったパイプラインも編集できるため、セキュリティ 上のリスクが生じていました。 これを防ぐには時間が必要でした。

セキュリティを損なうことなくパイプラインエクスペリエンスを強化するために、 Edit build pipeline アクセス許可を持つすべてのユーザーとグループも Create build pipeline アクセス許可を受け取ります。

パイプラインが作成されると、その作成者に Edit build pipeline アクセス許可が付与されます。

パイプラインのセキュリティを強化するために、Contributors、Readers などのユーザー グループからEdit build pipelineアクセス許可を削除することを選択できます。 これにより、既定では、パイプラインの作成者のみが編集できるようになります。

Note

Edit ビルド パイプラインアクセス許可は、他のユーザーによる YAML パイプラインの編集を妨げるものではありません。パイプラインのプロパティの編集のみが保護されます。

新しいプロジェクトの場合、 Edit build pipeline アクセス許可を持つユーザーとグループにも Create build pipeline アクセス許可が付与されます。 これは将来変更される可能性があります。

ステージ レベルでの排他ロック チェック

一部のユース ケースでは、パイプラインが特定のリソースに一度に 1 回だけアクセスする必要があります。 このケースをサポートするために、 Exclusive ロック チェックがあります。

同様の状況は、ある時点で 1 つのステージにアクセスする必要があるパイプライン実行が 1 つだけの場合に発生します。 たとえば、Azure リソース グループにデプロイするステージがある場合は、複数のパイプライン実行で同じリソース グループが同時に更新されないようにすることができます。 現時点では、これを実現するには、環境などのプロキシ リソースを使用し、その環境に排他ロック チェックを配置する必要があります。 この方法では、時間がかかり、複雑さが増し、メンテナンス作業が増える可能性があります。

このスプリントでは、ステージ レベルで排他ロックを指定するためのサポートが導入されています。 ID を持つステージがあり、その lockBehavior プロパティを指定すると、そのステージに対してロックが自動的に作成されます。 sequentialの動作は、リソース レベルとステージ レベルのロックの両方で一貫しています。 ただし、 runLatest の動作は異なります。これは、パイプラインのすべてのブランチではなく、同じブランチ runLatest ビルドを取り消すだけなので異なります。

パイプライン実行のテンプレート情報

パイプライン実行に含まれるテンプレートに関する情報を使用して、 Pipelines の実行 - Get REST API を更新しました。

たとえば、次の YAML パイプライン コードがあるとします。

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

新しい REST API には、次の新しいプロパティがあります。

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

手動でトリガーされた YAML パイプライン ステージ

手動でトリガーされた YAML パイプライン ステージに関する要求を頻繁に受け取ります。 これらは、統合パイプラインが必要な場合に役立ちますが、必ずしも完了まで実行するとは限りません。

たとえば、パイプラインには、ビルド、テスト、ステージング環境へのデプロイ、本番環境へのデプロイのためのステージが含まれる場合があります。 準備ができたら手動でトリガーする本番デプロイを除き、すべてのステージを自動的に実行できます。

このスプリントにより、手動でトリガーされる YAML パイプライン ステージのサポートが追加されます。 この機能を使用するには、 trigger: manual プロパティをステージに追加する必要があります。

次の YAML パイプラインの例を考えてみましょう。

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

このパイプラインを実行すると、エクスペリエンスは次のようになります。

手動でトリガーされるステージには依存関係がなく、いつでも実行できます。 パイプラインの実行は、手動でトリガーされたステージのみが残っている場合に完了します。

次のステップ

Note

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

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

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

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

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

シルヴィウ アンドリカ