• Aurélien Paranavithana

Auto Deploy Custom Actions avec Gitlab


Dans Neoload, les Custom Actions sont des modules développés en Java qui permettent de répondre à des besoins spécifiques. Ils s’intègrent à vos scénarios de tirs, on peut y définir des paramètres à prendre pour ensuite exécuter le code qui aura été développé.


Le développement de Custom Actions dans Neoload peut s’avérer utile pour enrichir les tirs de performance. On peut s’en servir pour écrire dans un fichier de log spécifique, transmettre des informations à une application tiers… Les possibilités sont nombreuses.


Cela devient cependant vite compliqué à maintenir et à déployer, surtout sur une infrastructure de tir complexe (plusieurs contrôleurs, contrôleurs et injecteurs créés à la demande…).


I. Gérer et stocker vos binaires de Custom Actions


Si vos tirs sont récurrents et que ceux-ci s’adaptent à l’évolution de votre SI, il est important d’en faire de même avec vos Custom Actions si celles-ci évoluent. Plusieurs outils permettent de stocker les différents binaires de vos Custom Actions, que ceux-ci soient des versions stables (Release) ou des versions en cours de développement/test (Snapshot). Parmi ceux-ci : Nexus, Artifactory, etc.


Ces outils s’interconnectent facilement avec Maven qui est un composant nécessaire à la réalisation des Custom Actions. Avec quelques lignes de configuration dans le pom.xml du projet et la commande « mvn deploy » il devient très simple d’envoyer votre version courante de Custom Action dans votre outil de gestion de binaires.


Ces binaires pourront par la suite être récupérés depuis vos contrôleurs Neoload à l’aide des différentes API mises à disposition par ces outils.


II. Gitlab Outil de versioning


2.1. Outil de versioning


Afin de faciliter le travail en équipe sur le développement des Custom Actions, ainsi que de garder le code des multiples versions de binaires, il est nécessaire d’utiliser un outil de versionnage. Plusieurs choix s’offrent à vous que ce soit en SaaS ou On-Premise : Bibucket, Github, Gitlab…


Pour cet article nous prendrons comme référence Gitlab. Une autre de ses fonctionnalités servira par la suite.

Gitlab, et plus spécifiquement Git, permet – grâce à son système de branches – d’optimiser le travail en équipe. On peut imaginer la branche principale (master) référençant uniquement les versions stables des Custom Actions. En taguant une version de code avec la même version de binaires déposée sur le gestionnaire de binaires il devient facile d’identifier une version de code source avec une version de Custom Actions pour connaître exactement le fonctionnement de celle-ci.


Ensuite, pour faire les développements nécessaires à l’amélioration des Custom Actions, il est possible de créer des branches « secondaires ». Une fois testées et validées, ces branches pourront être fusionnées avec la branche principale pour créer une nouvelle version de code, qui implique une nouvelle version stable de binaires.


2.2. Outil de déploiement


Gitlab, grâce à son service de CI/CD, permet de déclencher, selon plusieurs critères (push, merge…), un pipeline, depuis le serveur Gitlab ou depuis des runners Gitlab. Un runner est une machine, ou un containeur, qui communique avec le serveur Gitlab par ssh et qui permet d’exécuter des commandes dessus.


On peut donc imaginer créer un runner où est installé un environnement Maven. Ce runner aura pour but, une fois un merge fait sur la branche master, de récupérer le code de la Custom Action, de construire la release et de la déployer avec la commande « mvn deploy » sur le gestionnaire de binaires.


Une fois la release déployée, les runners sur les contrôleurs Neoload peuvent requêter l’API pour récupérer la dernière version des Custom Actions disponible, puis récupérer leurs scénarios sur le serveur Gitlab et lancer un tir pour valider la nouvelle version.


2.3 Schéma



59 vues

Posts récents

Voir tout