# Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する

Dependabotプル要求を合理化して効率的に管理する方法について説明します。

既定では、 Dependabot は新しいプル要求を開き、各依存関係を更新します。 セキュリティ更新プログラムを有効にすると、脆弱な依存関係が見つかったときに新しい pull request が開かれます。 1 つ以上のエコシステムのバージョン更新プログラムを構成すると、依存関係の新しいバージョンがリリースされたときに、`dependabot.yml` ファイルに定義されている頻度で新しい pull request が開かれます。

プロジェクトに多くの依存関係がある場合は、確認とマージを行う Dependabot プル要求が非常に多く、管理がすぐに困難になる可能性があります。

プロセスに合わせて更新プル要求を最適化するために、実装できるカスタマイズオプションがいくつかあります。例えば次のようなものです。

* \*\*\*\* を使用して、Dependabot が依存関係の新しいバージョンをチェックする`schedule`します。
* **意味のある更新を優先する** は `groups` を使ってください。

## 依存関係の更新の頻度とタイミングを制御する

Dependabot は、構成ファイルで設定した頻度でバージョン更新のチェックを実行します。ここで、必須フィールド `schedule.interval`は、 `daily`、 `weekly`、 `monthly`、 `quarterly`、 `semiannually`、 `yearly`、または `cron` に設定する必要があります ( [`cronjob`](/ja/code-security/reference/supply-chain-security/dependabot-options-reference#cronjob)を参照)。

既定では、 Dependabot は、依存関係の更新のプル要求をチェックして発生させるランダムな時間を割り当てることで、ワークロードのバランスを取ります。

ただし、気が散らないようにするため、またはバージョン更新プログラムを確認して対処するために時間とリソースをより適切に整理するには、頻度とタイミングを変更すると便利な場合があります。 たとえば、Dependabot では、更新のチェックを毎日ではなく毎週実行し、チームのトリアージ セッションの前にプル要求が確実に発行されるような時間帯に実行することもできます。

### 依存関係の更新頻度とタイミングの変更

`schedule`をオプションの組み合わせと共に使用して、Dependabotがバージョンの更新プログラムをチェックする頻度とタイミングを変更できます。

次の `dependabot.yml` ファイルの例では、npm の構成を変更して、 Dependabot が毎週火曜日の 02:00 日本語標準時 (UTC +09:00) に npm 依存関係のバージョン更新を確認する必要があることを指定します。

```yaml copy
# `dependabot.yml` file with
# customized schedule for version updates

version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    # Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00)
    schedule:
      interval: "weekly"
      day: "tuesday"
      time: "02:00"
      timezone: "Asia/Tokyo"
```

「[schedule](/ja/code-security/reference/supply-chain-security/dependabot-options-reference#schedule-)」も参照してください。

### 依存関係の更新のためのクールダウン期間を設定する

`cooldown`をオプションの組み合わせと共に使用して、**Dependabotがバージョン更新プログラム**のプル要求を作成するタイミングを制御できますが、**セキュリティ更新プログラム**は作成できません。

既定では、 Dependabot はバージョン更新プログラムに 3 日間のクールダウン期間を適用するため、新しいバージョンはリリースから 3 日後までバージョン更新プログラムとは見なされません。
**この既定のクールダウンは、セキュリティ更新プログラムには適用されません。**

以下のサンプル `dependabot.yml` ファイルでは、`requests`、`numpy`、プレフィックスが `pandas` または `django` である依存関係にクールダウン期間が適用されていますが、`pandas` リストで除外されている \*\*\*\* (完全一致) という依存関係には適用されていません。

```yaml copy
version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 5
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
      include:
        - "requests"
        - "numpy"
        - "pandas*"
        - "django"
      exclude:
        - "pandas"
```

* クールダウンの日数は 1 から 90 の間で指定する必要があります。
* `include` で使用できる `exclude` リストと `cooldown` リストの項目数の上限は、それぞれ 150 個です。

> \[!NOTE]
> クールダウン期間の**すべての依存関係**を考慮するには、次の方法があります。
> \*
> `include` オプションを省略すると、すべての依存関係にクールダウンが適用されます。
> \*
> `"*"` に `include` を使うと、クールダウン設定がすべてに適用されます。
> クールダウン設定から`exclude`のみを除外するには、\*\*\*\* を使用することをお勧めします。

SemVer はほとんどのパッケージ マネージャーでサポートされています。 クールダウン中の依存関係の新しいバージョンへの更新は、次のように延期されます。

* メジャー更新: 30 日間延期されます (`semver-major-days: 30`)。
* マイナー更新: 7 日間延期されます (`semver-minor-days: 7`)。
* パッチ更新: 3 日間延期されます (`semver-patch-days: 3`)。

参照 [`cooldown`](/ja/code-security/reference/supply-chain-security/dependabot-options-reference#cooldown-).

## 重要な更新プログラムを優先する

### 関連する依存関係のグループ化

`groups` を使うと、複数の依存関係の更新を 1 つの pull request に統合できます。 こうすることで、リスクの高い更新プログラムにレビュー時間を集中させ、マイナー バージョン更新プログラムのレビューに費やす時間を最小限に抑えることができます。 たとえば、開発の依存関係に対するマイナーまたはパッチ更新プログラムの更新プログラムを 1 つの pull request に結合し、コードベースの主要領域に影響を与えるセキュリティまたはバージョン更新プログラムを担当する専用グループを用意することができます。

個々のパッケージ エコシステムごとにグループを構成する必要があります。その後、次の条件の組み合わせを使って、パッケージ エコシステムごとに複数のグループを作成できます。

* Dependabot 更新の種類: `applies-to`
* 依存関係の種類: `dependency-type`。
* 依存関係の名前: `patterns` と `exclude-patterns`
* セマンティック バージョニング レベル: `update-types`

各条件でサポートされているすべての値を確認するには、「[`groups`](/ja/code-security/reference/supply-chain-security/dependabot-options-reference#groups--)」を参照してください。

条件を使って依存関係のグループを作成する複数の方法の例を次に示します。

### 例 1: 3 つのバージョン更新プログラム グループ

この例では、`dependabot.yml` ファイルは次のようになります。

* "`production-dependencies`"、"`development-dependencies`"、"`rubocop`" という 3 つのグループを作成します。
* `patterns` と `dependency-type` を使って、グループに依存関係を含めます。
* `exclude-patterns` を使って、グループから 1 つの依存関係 (または複数の依存関係) を除外します。

```yaml
version: 2
updates:
  # Keep bundler dependencies up to date
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      production-dependencies:
        dependency-type: "production"
      development-dependencies:
        dependency-type: "development"
        exclude-patterns:
          - "rubocop*"
      rubocop:
        patterns:
          - "rubocop*"
```

その結果、次のような影響が出ています。

* バージョン更新プログラムは依存関係の種類ごとにグループ化されます。
* パターン `rubocop*` と一致する開発依存関係は、`development-dependencies` グループから除外されます。
* 代わりに、`rubocop*` と一致する開発依存関係が `rubocop` グループに含まれます。 グループ化により、`rubocop*` と一致する開発依存関係が `production-dependencies` グループに含まれます。
* さらに、`applies-to` キーが存在しないため、すべてのグループは既定でバージョン更新プログラムのみに適用されます。

### 例 2: 依存関係が除外された、グループ化された更新プログラム

この例では、`dependabot.yml` ファイルは次のようになります。

* カスタマイズされた Bundler 構成の一部として、"`support-dependencies`" というグループを作成します。
* 1 つの依存関係 (または複数の依存関係) の名前と一致する `patterns` を使って、グループに依存関係を含めます。
* 1 つの依存関係 (または複数の依存関係) の名前と一致する `exclude-patterns` を使って、グループから依存関係を除外します。
* `applies-to: version-updates` が使われているため、グループ化をバージョン更新プログラムにのみ適用します。

```yaml
version: 2
updates:
  # Keep bundler dependencies up to date
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"

    schedule:
      interval: "weekly"
    # Create a group of dependencies to be updated together in one pull request
    groups:
      # Specify a name for the group, which will be used in pull request titles
      # and branch names
      support-dependencies:
        # Define patterns to include dependencies in the group (based on
        # dependency name)
        applies-to: version-updates # Applies the group rule to version updates
        patterns:
          - "rubocop" # A single dependency name
          - "rspec*"  # A wildcard string that matches multiple dependency names
          - "*"       # A wildcard that matches all dependencies in the package
                      # ecosystem. Note: using "*" may open a large pull request
        # Define patterns to exclude dependencies from the group (based on
        # dependency name)
        exclude-patterns:
          - "gc_ruboconfig"
          - "gocardless-*"
```

その結果、次のような影響が出ています。

* Bundler の依存関係の大部分は、ワイルドカード ("\*") パターンにより、`support-dependencies` グループに統合されます
* `gc_ruboconfig` や `gocardless-*` と一致する依存関係はグループから除外され、Dependabot により、これらの依存関係に対して 1 つの pull request が引き続き生成されます。 これが役立つのは、これらの依存関係の更新プログラムを詳細に確認する必要がある場合です。
* `support-dependencies`、バージョン更新プログラムに対してのみ、Dependabot によって pull request が生成されます。

### 例 3: メジャー更新プログラムの個別の pull request と、マイナーまたはパッチ更新プログラムのグループ化

この例では、`dependabot.yml` ファイルは次のようになります。

* "`angular`" というグループを作成します。
* 依存関係の名前と一致する `patterns` を使って、グループに依存関係を含めます。
* そのグループの `minor` または `patch` の更新プログラムのみを含めるには、`update-type` を使います。
* `applies-to: version-updates` が使われているため、グループ化をバージョン更新プログラムにのみ適用します。

```yaml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      # Specify a name for the group, which will be used in pull request titles
      # and branch names
      angular:
        applies-to: version-updates
        patterns:
          - "@angular*"
        update-types:
          - "minor"
          - "patch"
```

その結果、次のような影響が出ています。

* マイナーまたはパッチ更新プログラムがあるすべての Angular 依存関係に対して、Dependabot によってグループ化された pull request が作成されます。
* すべてのメジャー更新プログラムは引き続き個別の pull request として生成されます。

### 例 4: マイナーまたはパッチ更新プログラムのグループ化された pull request と、メジャー更新プログラムの pull request なし

この例では、`dependabot.yml` ファイルは次のようになります。

* "`angular`" と "`minor-and-patch`" という 2 つのグループを作成します。
* `applies-to` を使うと、最初のグループがバージョン更新プログラムのみに適用され、2 つ目のグループがセキュリティ更新プログラムのみに適用されます。
* 両方のグループの `minor` または `patch` の更新プログラムのみを含めるには、`update-type` を使います。
* `@angular*` パッケージの `major` バージョンへの更新プログラムを除外するには、`ignore` 条件を使います。

```yaml
version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      angular:
        applies-to: version-updates
        patterns:
          - "@angular*"
        update-types:
          - "minor"
          - "patch"
      minor-and-patch:
        applies-to: security-updates
        patterns:
          - "@angular*"
        update-types:
          - "patch"
          - "minor"
    ignore:
      - dependency-name: "@angular*"
        update-types: ["version-update:semver-major"]
```

その結果、次のような影響が出ています。

* Angular 依存関係のマイナーおよびパッチ バージョン更新プログラムは、1 つの pull request にグループ化されます。
* Angular 依存関係のマイナーおよびパッチのセキュリティ更新プログラムも、1 つの pull request にグループ化されます。
* Angular のメジャー更新プログラムに対しては、Dependabot によって自動的に pull request は開かれません。

### monorepo 内のディレクトリ間で更新をグループ化する

共通の依存関係を共有する複数のディレクトリを持つ monorepo を管理する場合は、すべてのディレクトリの依存関係名で更新プログラムをグループ化することで、バージョン更新のプル要求の数を減らすことができます。

Dependabot を複数のディレクトリを監視し、依存関係名でグループ化を有効にするように構成すると、Dependabot では次のことが行われます。

* 複数のディレクトリに影響を与える依存関係の更新ごとに 1 つのプル要求を作成する
* 1 回の操作ですべてのディレクトリで同じ依存関係を同じバージョンに更新する
* 確認する必要があるプル要求の数を減らす
* ディレクトリごとではなく、テストを 1 回実行して CI/CD コストを最小限に抑える

詳細については、「[`group-by`](/ja/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups)」を参照してください。

この構成例では、 `/frontend`、 `/admin-panel`、および `/mobile-app` の各ディレクトリで、依存関係の名前によって更新プログラムをグループ化します。
`lodash` を 3 つのディレクトリすべてで更新する必要がある場合、Dependabot は「monorepo-dependencies グループ内の lodash をバージョンアップ」という名前のプル要求を 1 つ作成し、3 箇所すべてで `lodash` を更新します。

```yaml
version: 2
updates:
  - package-ecosystem: "npm"
    directories:
      - "/frontend"
      - "/admin-panel"
      - "/mobile-app"
    schedule:
      interval: "weekly"
    groups:
      monorepo-dependencies:
        group-by: dependency-name
```