Hoe complex waren de pipelines op GitLab CI met het…

Ik heb gewerkt met GitLab CI-pijplijnen die inclusies en ankers gebruiken om code te structureren en her te gebruiken in projecten van verschillende complexiteit.

Typische gebruiksscenario's: build-pijplijnen voor microservices met verschillende omgevingen (dev, staging, prod).

Ik gebruik:

Externe inclusies: om gemeenschappelijke build-, test- en deployment-sjablonen te koppelen vanuit een gecentraliseerde repository.
Lokale inclusies: om een grote .gitlab-ci.yml op te splitsen in kleinere, leesbare delen (bijvoorbeeld per buildtype of fase).
Ankers (&) en referenties (*): om herhalende secties zoals Docker-image-instellingen, gemeenschappelijke scripts of taakparameters te hergebruiken.

Voorbeelden van complexiteit:

Pijplijnen met logische vertakkingen afhankelijk van het type commit, betrokken bestanden of branch.
Gebruik van rules of only/except in combinatie met inclusies om specifieke taken of pijplijnen in of uit te schakelen.
Combinatie van ankers en inclusies om parametrische taak-sjablonen te maken die gemakkelijk kunnen worden herconfigureerd in child-bestanden.

# .gitlab-ci.yml - voorbeeldstructuur
include:
  - project: 'common/ci-templates'
    ref: main
    file: '/templates/build-java.yml' # Gemeenschappelijk build-sjabloon voor Java

  - local: '.gitlab-ci/deploy-prod.yml' # Lokale deploy-bestand voor prod

variables:
  SERVICE_NAME: my-service

stages:
  - build
  - test
  - deploy

# Gebruik van ankers voor gemeenschappelijke instellingen
.base_job: &base_job
  image: ubuntu:latest
  before_script:
    - echo "Starting job..."

build-job:
  <<: *base_job # Toepassing van het anker
  stage: build
  script:
    - echo "Building $SERVICE_NAME"

# Taak gedefinieerd in de include van common/ci-templates
# java-build:
#    <<: *base_job
#    stage: build
#    script:
#      - mvn clean package
# ... (andere taken)

Het effectief gebruiken van inclusies en ankers maakt het mogelijk om schaalbare en onderhoudsvriendelijke CI/CD-pijplijnen te creëren, code duplicatie te verminderen en het beheer van de configuratie te vereenvoudigen. De complexiteit wordt meestal bepaald door het aantal services, de diversiteit van technologieën en de vereiste flexibiliteit van de pijplijn.

Hoe complex waren de pipelines op GitLab CI met het gebruik van includes en anchors?