Actualizaciones de varios ecosistemas

Las actualizaciones de varios ecosistemas combinan las actualizaciones de dependencia en varios ecosistemas de paquetes en una sola solicitud de incorporación de cambios, lo que reduce la sobrecarga de revisión y simplifica el flujo de trabajo de actualización.

En este artículo

¿Qué son las actualizaciones de varios ecosistemas?

Las actualizaciones de varios ecosistemas permiten a Dependabot agrupar actualizaciones de dependencias de diferentes ecosistemas de paquetes como npm, Docker, Python y Terraform en un solo pull request por grupo.

En lugar de recibir solicitudes de incorporación de cambios independientes para cada ecosistema, recibirá una solicitud de incorporación de cambios consolidada que contiene todas las actualizaciones de los ecosistemas de ese grupo.

Funcionamiento de las actualizaciones de varios ecosistemas

Al configurar un grupo de varios ecosistemas:

  1. Tú defines el grupo con un horario en la sección multi-ecosystem-groups de tu archivo dependabot.yml.
  2. Asigne ecosistemas de paquetes individuales al grupo mediante la multi-ecosystem-group clave .
  3. Usted especifica qué dependencias se van a incluir usando las patterns claves de cada ecosistema.
  4. Dependabot comprueba si hay actualizaciones según la programación del grupo.
  5. Se crea una única solicitud de incorporación de cambios que contiene actualizaciones de todos los ecosistemas del grupo.
  6. La PR usa el identificador de grupo tanto en el nombre de la rama como en el título.

Cuándo usar actualizaciones de varios ecosistemas

Las actualizaciones de varios ecosistemas son especialmente útiles para lo siguiente:

  •         **Proyectos de infraestructura** que usan varias tecnologías (Docker, Terraform, scripts de Python)

  •         **Aplicaciones de pila completa** con dependencias de front-end y back-end que deben actualizarse juntas

  •         **Bibliotecas multiplataforma** que necesitan versiones de protocolo sincronizadas entre lenguajes

  •         **Monorepos** con servicios en diferentes idiomas que comparten control de versiones

Varios ecosistemas frente a grupos de un solo ecosistema

Dependabot admite dos tipos de agrupación:

          **Grupos de varios ecosistemas:**

  • Abarcar varias entradas package-ecosystem en su archivo dependabot.yml

  • Requerir la patterns clave para especificar qué dependencias incluir

  • Tener definida su propia programación en la sección multi-ecosystem-groups

  • Uso de la multi-ecosystem-group clave para asignar ecosistemas a un grupo

            **Grupos de un solo ecosistema:**

  • Trabajo en un ecosistema de paquetes

  • Usar la groups clave dentro de una updates entrada

  • Heredar la programación de la entrada principal updates

  • Mejor para organizar las dependencias dentro de un único administrador de paquetes

Use grupos de varios ecosistemas cuando quiera combinar actualizaciones en distintos administradores de paquetes. Use grupos de un solo ecosistema cuando quiera organizar las dependencias dentro de un único administrador de paquetes (por ejemplo, agrupar todos los paquetes npm relacionados con AWS).

Comportamiento de combinación de configuración

Algunas opciones de configuración se pueden establecer en el nivel de grupo y en el nivel del ecosistema. Dependabot combina estos valores de forma diferente en función de la opción:

          **Opciones de aditivo** (los valores se combinan):

  •           `assignees`: todos los usuarios asignados de ambos niveles se han asignado a la solicitud de incorporación de cambios.

  •         `labels` - Todas las etiquetas de ambos niveles se aplican al pull request.

Por ejemplo, si asigna @platform-team en el nivel de grupo y @docker-admin en el nivel del ecosistema de Docker, la solicitud de incorporación de cambios resultante se asignará a ambos @platform-team y @docker-admin.

          **Opciones exclusivas del grupo** (solo se pueden establecer en el nivel de grupo):
  • milestone
  • commit-message
  • target-branch
  • pull-request-branch-name

Si intenta establecer estas opciones en el nivel del ecosistema, se producirá un error de configuración.

Para obtener una referencia completa de todas las opciones de configuración disponibles y su comportamiento, consulte Referencia de opciones de Dependabot.

Casos de uso

Proyectos de infraestructura

El código de infraestructura suele usar varias tecnologías: contenedores de Docker, Terraform para recursos en la nube y scripts de Python para la automatización. La agrupación de estas actualizaciones simplifica la revisión y la coordinación de la implementación.

          **Por qué agruparlos:** Los cambios de infraestructura a menudo deben implementarse juntos. Tener solicitudes de incorporación de cambios independientes para cada tecnología crea sobrecarga de coordinación y hace que sea más difícil realizar un seguimiento de lo que debe implementarse como una unidad.

          **Escenario de ejemplo:** Tiene imágenes de Docker para los servicios, módulos de Terraform para recursos de AWS y scripts de Python para tareas de automatización. Una única solicitud de incorporación de cambios semanal de "infraestructura" contiene actualizaciones para los tres, lo que facilita la revisión e implementación de los cambios de infraestructura juntos.

Aplicaciones de pila completa

Las aplicaciones web con componentes front-end y back-end se benefician de actualizar las dependencias juntas para garantizar la compatibilidad y simplificar las pruebas.

          **Por qué agruparlos:** El front-end y el back-end suelen depender entre sí. Actualizarlos juntos garantiza que puede probar la pila de aplicaciones completa en un solo uso, en lugar de combinar los cambios de front-end y, a continuación, detectar incompatibilidades de back-end más adelante.

          **Escenario de ejemplo:** Su frontend de React y backend de Rails se actualizan diariamente en una única "pull request" de "app-dependencies", lo que le permite probar la aplicación completa en conjunto antes de fusionarla.

Bibliotecas multiplataforma

Las bibliotecas o servicios que usan los mismos protocolos en distintos lenguajes (como gRPC y búferes de protocolo) deben mantener las versiones de biblioteca sincronizadas en todas las implementaciones.

          **Por qué agruparlos:** Las bibliotecas de protocolo deben ser compatibles en diferentes implementaciones de lenguaje. Al actualizarlos juntos, se evitan errores de coincidencia de versiones que podrían provocar errores de comunicación entre los servicios.

          **Escenario de ejemplo:** Los servicios Node.js y Ruby usan gRPC. Una única solicitud de incorporación de cambios actualiza `@grpc/grpc-js` (npm) y `grpc` (agrupador) juntos, lo que garantiza la compatibilidad del protocolo.

Monorepos con varios servicios

Los repositorios grandes que contienen varios servicios en distintos idiomas se benefician de la agrupación de actualizaciones por responsabilidad del equipo o cadencia de implementación.

          **Por qué agruparlos:** los distintos equipos poseen diferentes partes del monorepo y las actualizaciones deben enrutarse a los revisores adecuados. O los servicios se implementan juntos y necesitan actualizaciones coordinadas.

          **Escenario de ejemplo:** El monorepo tiene un servicio de API de Python, un servicio de trabajo de Go y un front-end de Node.js. Cree grupos independientes para "backend-services" (Python + Go) y "frontend" (Node.js), cada uno con diferentes horarios y asignados.

Ejemplo: Configuración compleja de varios grupos

En este ejemplo se muestra cómo un proyecto complejo podría usar varios grupos con diferentes estrategias de actualización:

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"

Pasos siguientes

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