Aller au contenu principal

Accélérer vos pipelines d'Intégration Continue grâce au graphe orienté acyclique (DAG)

· 4 minutes de lecture · Par Christophe Chaudier

Un graphe orienté acyclique permet d’exécuter les différentes étapes du pipeline dans le désordre, faisant fi du séquençage des étapes et permettant relier les tâches entre elles directement.

  

Récemment, GitLab a lancé une fonctionnalité exceptionnelle qui permet de réduire le temps d’exécution du pipeline et qui offre un gain de flexibilité dans l’ordre d’exécution des tâches. Cette fonctionnalité : le graphe orienté acyclique (DAG : Directed Acyclic Graph) est maintenant disponible gratuitement sur froggit.fr, et sur la version auto-hébergée de GitLab.

Tâches et étapes du pipeline

Dans un pipeline CI/CD classique, il existe de multiples étapes représentant l’automatisation du processus DevOps telles que la compilation, les tests, les packages, la configuration et le déploiement. Chaque étape est constituée d’une ou plusieurs tâches. Dans le fichier de configuration CI/CD : .gitlab-ci.yml vous définissez l’ordre de vos étapes. Généralement, le pipeline commence avec les tâches de compilation, une fois toutes ces tâches terminées, ce sont celles de tests qui débutent, puis celles de l’étape suivante et ainsi de suite.

Bien que cet ordre soit parfaitement sensé, dans certains cas cela peut ralentir le temps d’exécution quand on le considère dans son ensemble. Imaginez que l’étape de compilation est composée de la tâche A qui prend une minute et de la tâche B qui est très lente (disons qu’elle prend 5 minutes). La tâche C appartient à l’étape de test, mais elle ne dépend que de la tâche A. La tâche C devra quand même attendre 5 minutes avant d’être exécutée, ce qui représente une perte de 4 minutes.

Faites connaissance avec le graphe orienté acyclique

Le DAG vous permet de lancer les étapes du pipeline dans le désordre, brisant ainsi le séquençage des étapes et permettant aux tâches de se renvoyer les unes aux autres directement sans tenir compte de l’étape à laquelle elles appartiennent.

Avec le DAG, les tâches peuvent démarrer directement après que les tâches dont elles dépendent sont terminées, même si d’autres tâches de l’étape précédente sont encore en cours. Cette nouvelle fonctionnalité accélère le processus CI/CD et permet un déploiement plus rapide.

Dans l’exemple ci-dessous, un projet génère à la fois des applications Android, iOS et web grâce à un pipeline multi-étapes. Les tests iOS commencent dès que la compilation iOS est terminée au lieu d’attendre que les compilations pour Android et pour le web ne soient également finies. De même pour le déploiement iOS : il s’est lancé après que les tests iOS soient finis, sans attendre que les autres tests ne se terminent. Le temps de calcul total peut être le même, mais le temps réellement écoulé est différent. Dans des cas plus complexes, il est possible de réduire le temps réellement écoulé pour le pipeline de manière significative en déclarant quelle tâche est dépendante de quelle autre tâche.

Déclaration des dépendances entre tâches

Le fichier .gitlab-ci.yml introduit un nouveau mot clé : needs qui prend pour paramètre un tableau des tâches dont il dépend.

`ios: stage: build script:

- echo "build ios..."

ios_test: stage: test script:

- echo "test something..."

needs: ["ios"]`

La tâche ios_test, qui fait partie de l’étape test, débutera immédiatement après la tâche ios qui se trouve dans l’étape build et elle s’exécutera, peu importe le statut des autres tâches de l’étape build.

Quand est-ce utile ?

Cela peut être très utile dans le cadre du modèle de plus en plus populaire du mono dépôt dans lequel vous disposez de plusieurs dossiers dans votre dépôt qui peuvent compiler, tester et possiblement même déployer de manière indépendante, tout comme dans notre exemple ci-dessus où les applications iOS, Android et web peuvent être compilées, testées et déployées individuellement.

Une autre utilisation pourrait être lorsque votre pipeline contient des tests très lourds prenant beaucoup de temps pour s’exécuter. Il serait logique de lancer ces tests le plus tôt possible plutôt que d’attendre que des tâches sans aucun lien ne se terminent pour enfin les lancer.

Vous trouverez une démonstration de DAG ci-dessous

Vous cherchez des utilisateurs ou une instance GitLab hébergée en France ? Rejoignez la Communautés Froggit.

Crédits Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction issue du site de GitLab.

Illustration de James Eades via Unsplash