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:
- En utilisant des images optimisées
- En mettant en œuvre les DAG pour Directed Acyclic Graphs
- Et en utilisant les
paralleljobs. 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...