Что такое обновления для нескольких экосистем?
Обновления мультиэкосистем позволяют Dependabot группировать обновления зависимости между разными экосистемами пакетов, такими как npm, Docker, Python и Terraform, в один pull-запрос для каждой группы.
Вместо того чтобы получать отдельные pull-запросы для каждой экосистемы, вы получаете один консолидированный pull request, содержащий все обновления для экосистем этой группы.
Как работают обновления мультиэкосистем
Когда вы настраиваете мультиэкосистемную группу:
- Вы определяете группу с помощью расписания в
multi-ecosystem-groupsразделе вашегоdependabot.ymlфайла. - Вы назначаете отдельные экосистемы пакетов группе с помощью ключа
multi-ecosystem-group. - Вы указываете, какие зависимости включать, используя ключ
patternsдля каждой экосистемы. - Dependabot проверяет обновления по расписанию группы.
- Создаётся один pull request, содержащий обновления из всех экосистем группы.
- PR использует идентификатор группы как в названии филиала, так и в названии.
Когда использовать обновления мультиэкосистем
Обновления с несколькими экосистемами особенно полезны для:
-
**Инфраструктурные** проекты, использующие несколько технологий (Docker, Terraform, скрипты на Python) -
**Full-stack приложения** с фронтенд-зависимостью и бэкендом, которые нужно обновлять вместе -
**Кроссплатформенные библиотеки** , требующие синхронизированных версий протоколов между языками -
**Монорепо** с сервисами на разных языках, которые используют общие версии
Мультиэкосистемные и одноэкосистемные группы
Dependabot поддерживает два типа группировки:
**Мультиэкосистемные группы:**
-
Охватывайте несколько
package-ecosystemзаписей в вашемdependabot.ymlфайле -
Требуется, чтобы
patternsключ указывал, какие зависимости включать -
Пусть в разделе будет определено
multi-ecosystem-groupsсвоё собственное расписание -
Используйте
multi-ecosystem-groupключ, чтобы назначить экосистемы группе**Группы одной экосистемы:** -
Работа в рамках одной экосистемы пакета
-
Используйте
groupsключ внутриupdatesзаписи -
Наследуйте расписание от родительской
updatesзаписи -
Лучше для организации зависимостей внутри одного пакетного менеджера
Используйте мультиэкосистемные группы, когда хотите объединить обновления между разными менеджерами пакетов. Используйте одноэкосистемные группы, когда хотите организовать зависимости внутри одного менеджера пакетов (например, объединяйте все пакеты, связанные с AWS, NPM-пакеты).
Поведение слияния конфигураций
Некоторые настройки можно задать как на уровне группы, так и на уровне экосистемы. Dependabot комбинирует эти значения по-разному в зависимости от опции:
**Аддитивные опции** (значения объединяются):
*
assignees - Все получатели с обоих уровней назначаются на pull request
*
labels - Все метки с обоих уровней применяются к pull requestу
Например, если вы назначаете @platform-team на уровне группы и @docker-admin на уровне экосистемы Docker, полученный pull-запрос будет назначен обоим @platform-team и @docker-admin.
**Опции только для групп** (могут быть установлены только на уровне группы):
milestonecommit-messagetarget-branchpull-request-branch-name
Попытка настроить эти параметры на уровне экосистемы приведёт к ошибке в конфигурации.
Для полного справочника всех доступных опций конфигурации и их поведения см. Справочник по параметрам зависимостей.
Случаи использования
Проекты инфраструктуры
Код инфраструктуры часто использует несколько технологий — контейнеры Docker, Terraform для облачных ресурсов и скрипты на Python для автоматизации. Объединение этих обновлений упрощает обзор и координацию развертывания.
**Почему стоит объединить их вместе:** Изменения инфраструктуры часто приходится внедрять совместно. Наличие отдельных PR для каждой технологии создаёт накладные расходы на координацию и усложняет отслеживание, что нужно развернуть как единое подразделение.
**Пример сценария:** У вас есть образы Docker для ваших сервисов, модули Terraform для ресурсов AWS и скрипты на Python для задач автоматизации. Один еженедельный «инфраструктурный» pull request содержит обновления для всех трёх, что облегчает совместный просмотр и развертывание изменений в инфраструктуре.
Приложения с полным стеком
Веб-приложения с фронтенд-компонентами и бэкендом выигрывают от совместного обновления зависимостей для обеспечения совместимости и оптимизации тестирования.
**Почему стоит объединить их вместе:** Фронтенд и бэкенд часто зависят друг от друга. Обновление их вместе позволяет тестировать весь стек приложений за один раз, а не объединять изменения фронтенда и потом обнаруживать несовместимость бэкенда.
**Пример сценария:** Ваш фронтенд React и бэкенд Rails обновляются ежедневно в одном pull request-запросе «зависимости от приложений», что позволяет тестировать всё приложение вместе перед объединением.
Кроссплатформенные библиотеки
Библиотеки или сервисы, использующие одни и те же протоколы на разных языках (например, gRPC и Protocol Buffers), должны поддерживать синхронизацию версий библиотек во всех реализациях.
**Почему стоит объединить их вместе:** Библиотеки протоколов должны быть совместимы с разными языковыми реализациями. Совместное обновление предотвращает несоответствия версий, которые могут привести к сбоям связи между сервисами.
**Пример сценария:** Ваши сервисы Node.js и Ruby используют gRPC. Один pull-запрос обновляет как `@grpc/grpc-js` (npm), так `grpc` и (bundler), обеспечивая совместимость протоколов.
Монорепо с несколькими сервисами
Крупные репозитории, содержащие несколько сервисов на разных языках, выигрывают от группировки обновлений по ответственности команды или частоте развертывания.
**Почему стоит объединить их вместе:** Разные команды владеют разными частями монорепо, и обновления следует направлять соответствующим рецензентам. Или сервисы развёртываются вместе и требуют скоординированных обновлений.
**Пример сценария:** В вашем монорепозиторе есть сервис API на Python, сервис Go worker и фронтенд Node.js. Вы создаёте отдельные группы для «бэкенд-сервисов» (Python + Go) и «фронтенда» (Node.js), каждая из которых имеет свои расписания и назначения.
Пример: Сложная многогрупповая конфигурация
Этот пример показывает, как сложный проект может использовать несколько групп с разными стратегиями обновления:
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"
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)