|
Comment C3BS a mise en place des systèmes de tests automatisés avec l'intégration continue?
Après le développement d'une application et avant sa livraison à l'équipe Ops, l'une des tâches les plus chronophages est la mise en œuvre des différents tests afin de s'assurer que l'application répond exactement aux besoins du demandeur.
Dans le cas de C3BS qui intervient dans le développement d'applications orienté métier avec les ERP Open source Odoo et Tryton, les tests représentent une tâche primordiale.
En effet, il est nécessaire, entre autres, de s'assurer que:
- la mise en place de l'application ne crée pas de bug sur l'environnement (ou le serveur du demandeur),
- l'application permet d'enregistrer les données input précisées lors de la collecte des besoins,
- l'application permet de générer sans erreur les outputs demandés (variables, reporting, etc...).
La difficulté de leur mise en œuvre se crée par la différence entre les environnements de développement, les environnements de tests et les environnements de production. Certains développeurs travaillent sur Windows et y effectuent leur test. D'autres développent et testent sous différents versions de linux (Ubuntu, Debian ou Mint). Alors que les serveurs de productions sont sous Debian, Ubuntu ou CentOS.
Afin d'avoir l'assurance des points précédents, nous avions mis en place une batterie de tests qui nous permettaient de réduire au maximum les risques. Il s’agissait d'un protocole de tests en local puis en cloud sur bases de données vierges ou des copies de bases de données client et enfin un test ultime sur une copie de la base de production. Malgré toutes ces sécurités, nous n'étions pas à l'abri de surprises, de bugs ou d'erreurs difficiles à comprendre à cause de la diversité des environnements de travail.
D'une part, il était aussi difficile de contraindre un développeur aguerri à changer l'environnement dans lequel il est efficace au risque d'affecter ses performances. La solution de la virtualisation d'environnement client était intéressante, mais demandait énormément de ressources machine afin de travailler sur plusieurs projets simultanément.
D'autre part, la mise en place de l'environnement, le déploiement de l'application à tester, des base de test, l'enregistrement des données de tests ou autres tâches liées étaient répétitives et consommaient énormément de temps car elles étaient manuelles. Il était parfois difficile de reprendre tout une série de test juste pour la modification de 2 lignes du code source. Alors cette négligence pouvait aussi devenir une source d'erreur.
Ajouter à cela un bon système de versionning permettant au équipes de Dev d’accélérer la vitesse de production des mises à jour, les équipes Ops de tests ont été rapidement surmenés. Afin de régler ce problème, il était nécessaire pour nous de trouver un système d’intégration continue facile à mettre en place, flexible et fiable.
De nombreux outils d’intégration continue sont disponibles. Il est possible de citer comme exemple Jenkins CI ou Travis CI qui sont tout à fait pertinents. Cependant, nous avons choisi d’utiliser Gitlab CI car déjà habitué à son interface, son recours à Docker pour la gestion de ses environnements de test lui offre une grande flexibilité.
Afin d’automatiser les tests, il nous a fallu comprendre les processus de tests unitaires avec Odoo et Tryton et la conception des protocoles de tests avec les fichiers « .gitlab-ci ».
Tests unitaires avec Odoo et Tryton
Les solutions Odoo et Tryton intègrent des outils de tests via la bibliothèque Python Unitest et les fichiers YAML (Note: le support des tests YAML a été suspendu après la Version 8 de Odoo et Tryton supporte uniquement Unitest). Ces tests permettent de préparer des actions à effectuer lors du déploiement des modules en mode test afin de s’assurer qu’ils correspondent bien aux exigences. Les actions possibles sont nombreuses, on peut entre autres :
- créer, enregistrer des données ou les supprimer,
- changer d’utilisateur,
- exécuter des fonctions,
- modifier les statuts et workflow,
- tester des valeurs…
En somme, il est possible grâce aux tests unitaires d’effectuer l’ensemble des actions réalisées en manuel.
Les fichiers de test .gitlab-ci
Les fichiers de tests gitlab-ci permettent d’ordonner au serveur de test d’effectuer une série d’actions. Nous distinguons lors d’un test 3 grandes phases. La première phase est la mise en place de l’environnement de test. Il s’agira de déployer l’environnement, l’application ou sa version « dockeriser » ainsi que les bases de données, paquets ou applications complémentaires. La seconde phase est la phase de test elle-même ou sera exécuté les actions préparées afin de valider les exigences de l’application (enregistrement de données, exécution des fonctions, compilation, etc). La dernière phase est la phase de nettoyage. Durant cette phase, le serveur de test procède au nettoyage de tous les fichiers générés par la première et la deuxième phase afin que d’autres tests puissent être effectués dans un environnement stérile.
L’utilisation de Docker pour les environnements de test permet de faciliter l’exécution de l’ensemble de ces phases. Avec la technologie Docker, il est possible de créer, de construire des environnements de tests, de les modifier en fonction des besoins et de les supprimer facilement. En outre, son utilisation sous forme de container permet l’exécution simultanée de plusieurs tests sur le même serveur de test sans risques avec une consommation de réduite de ressources.
Exécution des tests
Apres avoir préparer les fichiers de tests unitaires de l’application et le fichier de protocole de test gitlab-ci associé au dépôt, le serveur de test exécutera automatiquement ce protocole à chaque mise à jour du dépôt. Le suivi des pipelines (ensemble des tâches de test) permet d’avoir une vue sur l’ensemble des tests effectués ainsi que leur résultat.
Il est possible de suivre de manière individuelle chaque pipeline afin d’avoir le résultat de chaque tache effectuée (job).
A l’intérieur de chaque job, il est possible d’avoir le log de l’exécution des tâches et le détail des actions effectuées par le serveur de test.
A la fin du test, le résultat et un aperçu des erreurs est automatiquement envoyé par mail à l’utilisateur ayant effectué la mise à jour du dépôt. Il lui est ainsi possible d’analyser les erreurs et d’y apporter des correctifs rapidement.
Le premier avantage est incontestablement le gain de temps et la réduction de la charge de travail de l’équipe chargé des tests. En outre, il est possible d’effectuer rapidement des tests sur une copie exact de l’environnement client grâce aux possibilités offertes par Docker. Les procédures d’intégration continue nous ont ainsi permi d’améliorer la qualité des fonctionnalités livrées aux différents demandeurs tout en augmentant la productivité de l’équipe.
|