Quanto sono stati complessi i pipeline su GitLab CI con l'uso di inclusioni e ancore che hai dovuto scrivere?

Ho lavorato con pipeline di GitLab CI che utilizzano inclusioni e ancore per strutturare e riutilizzare il codice in progetti di diversa complessità.

Scenari tipici di utilizzo: pipeline di build per microservizi con ambienti diversi (dev, staging, prod).

Utilizzo:

• Inclusioni esterne: per collegare modelli comuni di build, test e deploy da un repository centralizzato.
• Inclusioni locali: per dividere un .gitlab-ci.yml grande in parti più piccole e leggibili (ad esempio, per tipo di build o fase).
• Ancore (&) e riferimenti (*): per riutilizzare sezioni ripetitive, come configurazioni di immagini Docker, script comuni o parametri di task.

Esempi di complessità:

• Pipeline con ramificazioni logiche in base al tipo di commit, file interessati o branch.
• Uso di rules o only/except in combinazione con inclusioni per includere/escludere task o pipeline specifici.
• Combinazione di ancore e inclusioni per creare modelli di task parametrizzati, facilmente riconfigurabili in file figli.

# .gitlab-ci.yml - esempio di struttura
include:
  - project: 'common/ci-templates'
    ref: main
    file: '/templates/build-java.yml' # Modello comune di build Java

  - local: '.gitlab-ci/deploy-prod.yml' # File locale di deploy in prod

variables:
  SERVICE_NAME: my-service

stages:
  - build
  - test
  - deploy

# Uso di ancore per configurazioni comuni
.base_job: &base_job
  image: ubuntu:latest
  before_script:
    - echo "Starting job..."

build-job:
  <<: *base_job # Applicazione dell’ancora
  stage: build
  script:
    - echo "Building $SERVICE_NAME"

# Task definita nell’inclusione di common/ci-templates
# java-build:
#    <<: *base_job
#    stage: build
#    script:
#      - mvn clean package
# ... (altre task)

L’uso efficace di inclusioni e ancore permette di creare pipeline scalabili e facili da mantenere, riducendo la duplicazione del codice e semplificando la gestione della configurazione. La complessità è generalmente determinata dal numero di servizi, dalla diversità di tecnologie e dalla flessibilità richiesta dal pipeline.