Optimiser vos CI gitlab avec les DAG

En bon devops on cherche tous à optimiser les temps de déploiement de nos applications, et bien voici une nouveauté du CI de Gitlab qui va permettre d’y parvenir : les DAG pour Directed Acyclic Graphs.

les DAG de Gitlab

Arrivés avec la version 12.2 de Gitlab, les DAG apporte les outils nécessaires pour optimiser les pipelines. Dans le contexte des pipelines GitLab, un DAG est une chaîne de travaux créée en spécifiant les dépendances entre les travaux. Cela permet la parallélisation des travaux, mais par contre ne permet pas la création de plusieurs pipelines.

Prenons l’exemple d’un simple pipeline composé de trois stages : build, test et deploy. Dans l’exemple ci-dessous j’ai omis de mettre la partie script pour simplifier au possible l’exemple.

stages:
  - build
  - test
  - deploy

build-image:
  stage: build
  script:
    - echo toto

deploy-hors-prod:
  stage: build
  script:
    - echo titi

scan-image:
  stage: test
  script:
    - echo tata

test-integration:
  stage: test
  script:
    - echo tutu

deploy:
  stage: deploy
  script:
    - echo tete

Par exemple on aimerait que le scan de l’image docker puisse démarrer sans attendre la fin du déploiement en hors prod. Eh bien il suffit d’ajouter la clé needs :

stages:
  - build
  - test
  - deploy

build-image:
  stage: build
  script:
    - echo toto

deploy-hors-prod:
  stage: build
  needs:
    - build-image
  script:
    - echo titi

scan-image:
  stage: test
  needs:
    - build-image
  script:
    - echo tata

test-integration:
  stage: test
  script:
    - echo tutu

deploy:
  stage: deploy
  needs:
    - test-integration
  script:
    - echo tete

Les artefacts dans les DAG

Faites attention, car si vous oubliez un needs certaines taches se lancerons en cas d’échec. Vous pouvez valider votre CI directement dans l’outil “Editor”

Attention lorsqu’un job utilise needs, il ne télécharge pas les artefacts des étapes précédentes par défaut, car les travaux avec needs peuvent avoir démarré avant la fin des étapes précédentes. Il faut donc l’indiquer.

build-image:
  stage: build
  script:
    - echo toto
  artifacts:
    paths:
      - binaries/

deploy-hors-prod:
  stage: build
  needs:
    - job:build-image
      artifacts: true
  script:
    - echo titi

Le nombre maximum de jobs pouvant être définis par needs :défaut est 50.

Les jobs optionnels

Il peut arriver que parfois, via les rules, un job ne soit pas présent dans le pipeline d’exécution. Par défaut si le job le liste dans ses needs, le pipeline passera en erreur. Il est possible d’ajouter la clé optional: true.

build-image:
  stage: build
  script:
    - echo toto

deploy-hors-prod:
  stage: build
  needs:
    - job:build-image
      optional: true
  script:
    - echo titi