GitLab CI avancé : matrices, pipelines dynamiques et optimisation des temps de build

Un pipeline qui prend 45 minutes n’est pas un pipeline CI/CD — c’est un obstacle à la livraison. Voici les techniques GitLab qui font passer les builds de 45 à 8 minutes.

Le cache : la première optimisation

default:
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - node_modules/
    policy: pull-push

La clé de cache basée sur package-lock.json garantit que le cache est invalidé uniquement quand les dépendances changent. policy: pull-push permet aux jobs de lire ET d’écrire le cache.

Les matrices de jobs pour le test parallèle

test:
  stage: test
  parallel:
    matrix:
      - NODE_VERSION: ["18", "20", "22"]
        DATABASE: ["postgres", "mysql"]
  image: node:${NODE_VERSION}
  script:
    - npm test -- --db=${DATABASE}

6 jobs en parallèle au lieu d’un seul séquentiel. Si chaque job prend 5 minutes, vous passez de 30 minutes à 5 minutes.

Les pipelines dynamiques avec include et rules

# .gitlab-ci.yml principal
include:
  - local: '.gitlab/ci/backend.yml'
    rules:
      - changes: ['backend/**/*']
  - local: '.gitlab/ci/frontend.yml'
    rules:
      - changes: ['frontend/**/*']

Si vous ne touchez qu’au frontend, le pipeline backend ne se lance pas. Économie de ressources et de temps.

Artifacts et dépendances entre stages

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour

deploy:
  stage: deploy
  needs: [build]  # N'attend pas les autres jobs du stage build
  script:
    - deploy dist/ to production

Le mot-clé needs permet de créer des dépendances directes entre jobs sans attendre tous les jobs du stage. Vos pipelines deviennent un DAG (graphe acyclique dirigé) plutôt qu’une séquence linéaire de stages.

Environnements et déploiements

deploy-production:
  environment:
    name: production
    url: https://myapp.com
  rules:
    - if: $CI_COMMIT_TAG
  when: manual

La combinaison rules: if: $CI_COMMIT_TAG + when: manual déclenche le déploiement production uniquement sur un tag, et uniquement si quelqu’un clique sur “Démarrer”.

Runner caching avec runner executor Docker+Machine

Pour les équipes avec des pipelines très fréquents, un GitLab Runner avec autoscaling (Docker Machine ou Kubernetes) permet d’absorber les pics sans payer pour des runners idle.

Notre formation CI/CD avec GitLab couvre ces optimisations avec des pipelines réels.