Les DAG avc Gitlab CI/CD

Lorsque des membres de l’équipe | Dans cet article, j’explique comment utiliser les jobs parallèles dans GitLab CI pour accélérer les pipelines en exécutant plusieurs tests ou builds simultanément. J’explore l’utilisation du parallel: X pour lancer des clones de jobs avec des variables comme CI_NODE_INDEX et CI_NODE_TOTAL, puis je montre comment utiliser l’option matrix pour exécuter des jobs sur plusieurs versions d’un langage, par exemple Python. Cela permet d’optimiser les temps d’exécution dans vos pipelines DevOps. 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:

• En utilisant des images optimisées
• En mettant en œuvre les DAG pour Directed Acyclic Graphs
• Et en utilisant les parallel jobs. C’est ce que nous allons voir ici.

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…