¿Qué tan complejos han sido los pipelines en GitLab CI que has tenido que escribir, usando inclusiones y anclajes?

Trabajé con pipelines de GitLab CI que utilizan inclusiones y anclajes para estructurar y reutilizar código en proyectos de diferentes niveles de complejidad.

Escenarios típicos de uso: pipelines de compilación para microservicios con diferentes entornos (dev, staging, prod).

Utilizo:

• Inclusiones externas: para conectar plantillas comunes de compilación, prueba y despliegue desde un repositorio central.
• Inclusiones locales: para dividir un .gitlab-ci.yml grande en partes más pequeñas y legibles (por ejemplo, por tipo de compilación o etapa).
• Anclajes (&) y referencias (*): para reutilizar secciones repetitivas, como configuración de imágenes Docker, scripts comunes o parámetros de tareas.

Ejemplos de complejidad:

• Pipelines con ramificación lógica según el tipo de commit, archivos afectados o rama.
• Uso de rules o only/except en combinación con inclusiones para incluir/excluir tareas o pipelines específicos.
• Combinación de anclajes e inclusiones para crear plantillas parametrizadas de tareas, que se pueden reconfigurar fácilmente en archivos hijos.

# .gitlab-ci.yml - ejemplo de estructura
include:
  - project: 'common/ci-templates'
    ref: main
    file: '/templates/build-java.yml' # Plantilla común de compilación Java

  - local: '.gitlab-ci/deploy-prod.yml' # Archivo local de despliegue en prod

variables:
  SERVICE_NAME: my-service

stages:
  - build
  - test
  - deploy

# Uso de anclajes para configuraciones comunes
.base_job: &base_job
  image: ubuntu:latest
  before_script:
    - echo "Starting job..."

build-job:
  <<: *base_job # Aplicación del anclaje
  stage: build
  script:
    - echo "Building $SERVICE_NAME"

# Tarea definida en la inclusión de common/ci-templates
# java-build:
#    <<: *base_job
#    stage: build
#    script:
#      - mvn clean package
# ... (otras tareas)

El uso efectivo de inclusiones y anclajes permite crear pipelines escalables y fáciles de mantener, reduciendo la duplicación de código y simplificando la gestión de la configuración. La complejidad generalmente se determina por la cantidad de servicios, la diversidad de tecnologías y la flexibilidad requerida en el pipeline.