Aller au contenu principal

Les DAG avc Gitlab CI/CD

· 2 minutes de lecture
Stéphane ROBERT
Stéphane ROBERT
Consultant DevOps

Lorsque des membres de l'équipe attendent qu'un pipeline en cours d'exécution se termine pour pouvoir apporter une contribution à son projet, la productivité en prend un coup.

Dans un pipeline basique, tous les jobs d'une étape s'exécutent simultanément et les jobs de l'étape suivante doivent attendre qu'ils se terminent pour commencer.

Mais il existe des solutions pour augmenter la productivité des CI:

Job Parallel​

Toutes les tâches d'un pipeline n'ont pas la même durée d'exécution. Alors que certains peuvent ne prendre que quelques secondes, d'autres vont prendre beaucoup plus de temps.

GitLab à ajouter une méthode pour créer des clones de jobs et les lancer en parallèle.

Les jobs de tests sont souvent les plus longs à s'exécuter. Prenons l'exemple sur les tests d'une application en ruby. (Ça doit exister également pour d'autres langages, mais va falloir chercher. Perso je vais regarder pour Django.)

test:
  parallel: 5
  script:
    - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL

Chaque job parallèle se verra affecter une variable CI_NODE_INDEX et une variable CI_NODE_TOTAL.

Entrez dans la matrix​

Blague à part. Voici une autre utilisation de parralel. Imaginez que vous deviez compiler votre application avec plusieurs versions du langage. Eh bien en utilisant l'option matrix vous pouvez définir des variables et leur affecter différentes valeurs qui seront utilisées dans jobs qui tourneront en //.

Un exemple avec du python :

wheel:
  image: python:$PYTHON_VERSION-slim
  stage: build
  before_script:
    - pip install build
  script:
    - python -m build --wheel .
  artifacts:
    paths:
      - dist/
    expire_in: 1 day
  parallel:
    matrix:
      - PYTHON_VERSION: ['3.6', '3.7', '3.8', '3.9']

Je suis sûr que vous voyez le gain, d'autres cas d'utilisation. On pourrait imaginer construire plusieurs images docker en // par exemple...