マルチエコシステム更新

複数のエコシステムの更新では、複数のパッケージ エコシステムにわたる依存関係の更新が 1 つのプル要求に結合されるため、レビューのオーバーヘッドが削減され、更新ワークフローが簡素化されます。

この記事で

マルチエコシステムの更新とは

複数エコシステムの更新により、 Dependabot を使用して、npm、Docker、Python、Terraform などのさまざまなパッケージ エコシステム間の依存関係の更新をグループごとに 1 つのプル要求にグループ化できます。

エコシステムごとに個別のプル要求を受け取る代わりに、そのグループ内のエコシステムのすべての更新を含む 1 つの統合プル要求を受け取ります。

マルチエコシステム更新のしくみ

マルチエコシステム グループを構成する場合:

  1. グループは、multi-ecosystem-groups ファイルの dependabot.yml セクションでスケジュールを使用して定義します。
  2.        `multi-ecosystem-group` キーを使用して、個々のパッケージ エコシステムをグループに割り当てます。
  3. 各エコシステムの patterns キーを使用して、含める依存関係を指定します。
  4. Dependabot は、グループのスケジュールに従って更新プログラムをチェックします。
  5. グループ内のすべてのエコシステムからの更新を含む 1 つのプル要求が作成されます。
  6. PR では、ブランチ名とタイトルの両方でグループ識別子が使用されます。

マルチエコシステム更新プログラムを使用する場合

マルチエコシステム更新は、特に次のような場合に役立ちます。

  • 複数のテクノロジを使用するインフラストラクチャ プロジェクト (Docker、Terraform、Python スクリプト)
  • フロントエンドとバックエンドの依存関係を一緒に更新する必要があるフル スタック アプリケーション
  • 言語間でプロトコル バージョンを同期する必要があるクロスプラットフォーム ライブラリ
  • バージョン管理を共有するさまざまな言語のサービスを含む Monorepos

複数のエコシステムと単一のエコシステム グループ

Dependabot では、次の 2 種類のグループ化がサポートされています。

          **マルチエコシステム グループ:**
  • dependabot.yml ファイル内の複数の package-ecosystem エントリにまたがる
  • 含める依存関係を指定するには、 patterns キーが必要です
  •         `multi-ecosystem-groups` セクションで独自のスケジュールを定義する

  •         `multi-ecosystem-group` キーを使用してエコシステムをグループに割り当てる

        **単一エコシステム グループ:**
  • 1 つのパッケージ エコシステム内で作業する
  •         `groups` エントリ内で`updates` キーを使用する
  • 親 updates エントリからスケジュールを継承する
  • 1 つのパッケージ マネージャー内で依存関係を整理する場合に適しています

複数のパッケージ マネージャー間で更新プログラムを組み合わせる場合は、複数のエコシステム グループを使用します。 1 つのパッケージ マネージャー内で依存関係を整理する場合は、単一エコシステム グループを使用します (たとえば、AWS 関連のすべての npm パッケージをまとめてグループ化するなど)。

構成のマージ動作

一部の構成オプションは、グループ レベルとエコシステム レベルの両方で設定できます。 Dependabot では、オプションに応じて、これらの値が異なる方法で結合されます。

          **加算オプション** (値がマージされます):

* assignees - 両方のレベルのすべての担当者が pull request に割り当てられます * labels - 両方のレベルのすべてのラベルがプル要求に適用されます

たとえば、グループ レベルで @platform-team を割り当て、Docker エコシステム レベルで @docker-admin すると、結果のプル要求は @platform-team と @docker-adminの両方に割り当てられます。

          **グループのみのオプション** (グループ レベルでのみ設定できます):
  • milestone
  • commit-message
  • target-branch
  • pull-request-branch-name

これらのオプションをエコシステム レベルで設定しようとすると、構成エラーが発生します。

使用可能なすべての構成オプションとその動作の完全なリファレンスについては、 Dependabot オプション リファレンス を参照してください。

利用事例

インフラストラクチャ プロジェクト

インフラストラクチャ コードでは、多くの場合、Docker コンテナー、クラウド リソース用の Terraform、自動化用の Python スクリプトなど、複数のテクノロジが使用されます。 これらの更新プログラムをグループ化すると、レビューと展開の調整が簡単になります。

          **これらをグループ化する理由は次のとおりです。** インフラストラクチャの変更は、多くの場合、一緒にデプロイする必要があります。 テクノロジごとに個別の PR を使用すると、調整オーバーヘッドが発生し、ユニットとしてデプロイする必要のあるものを追跡することが困難になります。

          **シナリオの例:** サービス用の Docker イメージ、AWS リソース用の Terraform モジュール、自動化タスク用の Python スクリプトがあります。 1 週間に 1 回の "インフラストラクチャ" プル要求には、3 つすべての更新プログラムが含まれており、インフラストラクチャの変更をまとめて簡単に確認してデプロイできます。

フルスタック アプリケーション

フロントエンド コンポーネントとバックエンド コンポーネントを備えた Web アプリケーションは、互換性を確保し、テストを合理化するために依存関係を更新することでメリットがあります。

          **これらをグループ化する理由は次のとおりです。** フロントエンドとバックエンドは、多くの場合、相互に依存します。 それらを一緒に更新することで、フロントエンドの変更をマージし、後でバックエンドの非互換性を検出するのではなく、アプリケーション スタック全体を一度にテストできます。

          **シナリオの例:** React フロントエンドと Rails バックエンドは、1 つの "アプリ依存関係" プル要求で毎日更新されるため、マージする前に完全なアプリケーションをまとめてテストできます。

クロスプラットフォーム ライブラリ

異なる言語 (gRPC やプロトコル バッファーなど) で同じプロトコルを使用するライブラリまたはサービスは、すべての実装でライブラリ バージョンの同期を維持する必要があります。

          **これらをグループ化する理由は次のとおりです。** プロトコル ライブラリは、さまざまな言語実装間で互換性を維持する必要があります。 それらを一緒に更新すると、サービス間の通信エラーを引き起こす可能性のあるバージョンの不一致を防ぐことができます。

          **シナリオの例:** Node.js と Ruby の両方のサービスで gRPC が使用されます。 1 つのプル要求によって、 `@grpc/grpc-js` (npm) と `grpc` (bundler) の両方が一緒に更新され、プロトコルの互換性が確保されます。

複数のサービスを含む Monorepos

異なる言語の複数のサービスを含む大規模なリポジトリは、チームの責任またはデプロイの頻度によって更新プログラムをグループ化することでメリットがあります。

          **これらをグループ化する理由は次のとおりです。** チームごとにモノレポのさまざまな部分が所有されており、更新プログラムは適切なレビュー担当者にルーティングする必要があります。 または、サービスが一緒にデプロイされ、調整された更新プログラムが必要です。

          **シナリオの例:** monorepo には、Python API サービス、Go worker サービス、Node.js フロントエンドがあります。 "backend-services" (Python + Go) と "frontend" (Node.js) 用に個別のグループを作成し、それぞれに異なるスケジュールと担当者を設定します。

例: 複雑な複数グループ構成

この例では、複雑なプロジェクトで、異なる更新方法で複数のグループを使用する方法を示します。

YAML
version: 2

multi-ecosystem-groups:
  # Infrastructure updates - weekly, tracked in milestone
  infrastructure:
    schedule:
      interval: "weekly"
    assignees: ["@platform-team"]
    labels: ["infrastructure", "dependencies"]
    milestone: 10

  # Application code updates - daily, with development team
  full-stack:
    schedule:
      interval: "daily"
    assignees: ["@full-stack-team"]
    labels: ["full-stack"]

updates:
  # Docker images - infrastructure group with additional docker expertise
  - package-ecosystem: "docker"
    directory: "/"
    patterns: ["nginx", "redis", "postgres"]
    assignees: ["@docker-admin"]      # Adds to @platform-team
    labels: ["docker"]                 # Adds to infrastructure, dependencies
    multi-ecosystem-group: "infrastructure"

  # Terraform - infrastructure group
  - package-ecosystem: "terraform"
    directory: "/"
    patterns: ["aws", "terraform-*"]
    multi-ecosystem-group: "infrastructure"

  # Frontend - full-stack group with frontend focus
  - package-ecosystem: "npm"
    directory: "/frontend"
    patterns: ["react", "lodash", "@types/*"]
    labels: ["frontend"]               # Adds to full-stack
    multi-ecosystem-group: "full-stack"

  # Backend - full-stack group with backend specialist
  - package-ecosystem: "bundler"
    directory: "/backend"
    patterns: ["rails", "pg", "sidekiq"]
    assignees: ["@backend-dev"]        # Adds to @full-stack-team
    multi-ecosystem-group: "full-stack"

次のステップ

  •         [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates)