Quão complexos têm sido os pipelines no GitLab CI usando includes e anchors?

Trabalhei com pipelines do GitLab CI que utilizam inclusões e âncoras para estruturar e reutilizar código em projetos de diferentes níveis de complexidade.

Cenários típicos de uso: pipelines de build para microserviços com diferentes ambientes (dev, staging, prod).

Utilizo:

• Inclusões externas: para conectar modelos comuns de build, teste e deploy a partir de um repositório central.
• Inclusões locais: para dividir um .gitlab-ci.yml grande em partes menores e mais legíveis (por exemplo, por tipo de build ou etapa).
• Ancoras (&) e referências (*): para reutilizar secções repetitivas, como configuração de imagens Docker, scripts comuns ou parâmetros de tarefas.

Exemplos de complexidade:

• Pipelines com ramificações lógicas dependendo do tipo de commit, arquivos afetados ou branch.
• Uso de rules ou only/except em combinação com inclusões para incluir/excluir tarefas ou pipelines específicos.
• Combinação de âncoras e inclusões para criar modelos de tarefas parametrizados, facilmente reconfiguráveis em ficheiros filhos.

# .gitlab-ci.yml - exemplo de estrutura
include:
  - project: 'common/ci-templates'
    ref: main
    file: '/templates/build-java.yml' # Modelo comum de build Java

  - local: '.gitlab-ci/deploy-prod.yml' # Ficheiro local de deploy em prod

variables:
  SERVICE_NAME: my-service

stages:
  - build
  - test
  - deploy

# Uso de âncoras para configurações comuns
.base_job: &base_job
  image: ubuntu:latest
  before_script:
    - echo "Starting job..."

build-job:
  <<: *base_job # Aplicação da âncora
  stage: build
  script:
    - echo "Building $SERVICE_NAME"

# Tarefa definida na inclusão de common/ci-templates
# java-build:
#    <<: *base_job
#    stage: build
#    script:
#      - mvn clean package
# ... (outras tarefas)

O uso eficaz de inclusões e âncoras permite criar pipelines escaláveis e fáceis de manter, reduzindo a duplicação de código e simplificando a gestão da configuração. A complexidade geralmente é determinada pelo número de serviços, diversidade de tecnologias e flexibilidade requerida no pipeline.