CONTEXTE
Il s’agit d’ajouter l’automatisation des tests dans une chaîne de build continue d’une application EDI dans le domaine de la logistique.
L’échange de données informatisé (EDI) est une technique qui remplace les échanges physiques de documents entre entreprises (commandes, factures, bons de livraison,…) par des échanges, selon un format standardisé, entre ordinateurs connectés par liaisons spécialisées ou par un réseau (privatif) à valeur ajoutée (RVA). Les données sont structurées selon des normes techniques internationales de référence (ex : Edifact).
Pour notre cas, l’application EDI effectue les échanges entre la grande distribution (AUCHAN, Carrefour, Lerclerc,…) et les sociétés industrielles (Nestlé, Danone, …).
ARCHITECTURE DE L’INTEGRATION CONTINUE DE L’APPLICATION EDI
PROBLEMATIQUE
- A chaque fois qu’une nouvelle version de l’application était disponible, pour y effectuer des tests, nous étions obligés de prendre l’iso, le lancer et d’exécuter toutes les étapes que l’installateur nous suggérait, ce qui était très chronophage. Par conséquent, cela représente une perte de temps :
- à chaque sortie de version pour l’installation,
- pour l’éxécution manuelle de tests à chaque sortie de version de l’application.
Il fallait donc trouver des outils simples qui permettent de réaliser le travail décrit ci-dessus. Après multiples recherches, nous avons identifié deux outils : Docker et Robotframework.
- Docker va nous permettre d’exécuter du code à l’intérieur d’un conteneur, indépendamment de la machine sur laquelle nous sommes.
- Robotframework quant à lui implique l’installation deux autres outils (selenuim2Library et python). Il représente surtout un outil de test de validation des applications web dont la mise en place est assez fastidieuse, bien que sa syntaxe soit facile car proche du langage naturel. Robotframework a finalement été abandonné du fait de sa complexité d’installation et de configuration.
Nous avons donc choisi d’utiliser Docker grâce à sa simplicité dans l’installation et la configuration, moins gourmand en mémoire, et à moindre coût. Et l’existence de plugs-in Docker intégrables dans Jenkins et permettant l’exécution de commandes Docker depuis le serveur d’intégration nous a finalement convaincu.
MISE EN OEUVRE DE LA SOLUTION
Nous avons choisi de nous positionner sur un serveur Linux de notre chaîne de compilation.
Nous avons créé un répertoire « docker » dans notre répertoire de travail en production /[home]/Production/
Puis nous avons créé trois fichiers : Dockerfile, inst_tx_from_tar.sh, et makefile.test
Le fichier Dockerfile
Ce fichier indique à Docker les instructions à éxecuter pour construire l’image de l’application à utiliser par la suite :
P.S:
* FROM : c’est pour charger l’image theloniousmonk/cga-debian32 de l’os Linux Debian de laquelle nous sommes partis.
* RUN : va exécuter le script inst_tx_from_tar.sh sur la branche de l’application indiquée la variable BRANCHE.
* CMD : va démarrer le scanner, qui va activer les tâches de la FIFO.
Le fichier inst_tx_from_tar.sh
Sert à effectuer le travail de l’installateur, car au moment où ce projet se déroulait, on effectuait la migration de l’installeur vers une nouvelle application qui était encore très instable, d’où nous devions exécuter toutes les étapes de l’installation via le script inst_tx_from_tar.sh
On peut remarquer ci-dessus que ce fichier est accessible en http dans le Dockerfile. Ceci est fait exprès pour que la résolution de ce fichier ne se fasse pas par un chemin absolu, et ainsi qu’il puisse être trouvé de n’importe où sur le réseau autorisé.
Par exemple ce script commence par :
- télécharger le patch full qui contient les fichiers binaires et de configuration de l’application EDI à installer.
- décompresser le patch et donner les bons droits aux cgi.
- créer le groupe des utilisateurs EDI
et après plusieurs autres actions - construire le fichier de license
et après plusieurs autres actions - On demarre apache.
Une fois l’installation terminée, l’exécution des tests peut commencer (nous sommes toujours au cours de la construction de l’image) :
- démarrer les tests de communication as2 par exemple :
et après plusieurs autres actions,
- démarrer les tests C concernant les traducteurs EDI en STANDALONE :
Le fichier makefile.test
C’est le fichier de makefile où l’on a définit toutes les dépendances de compilation des sources de C des traducteurs EDI et ainsi que celles de l’excécution des tests lors de la construction de l’image docker de l’application.
Création de image
Il est à noter que le Dockerfile est accessible en http ici et non en chemin absolu, c’est pour permettre le fait que l’image puisse se construire depuis n’importe où sur le réseau autorisé.
Création d’un container
Accès web
Configuration de jenkins
Il faut désormais paramétrer le serveur de gestion de build continue pour qu’il puisse exécuter les commandes docker précédentes de manière automatique.
Le Plug-in à installer est : « docker-build-step ». Il permet d’exécuter les commandes docker depuis Jenkins.
Ouvrir Jenkins avec chrome ou firefox de préférence
Cliquer sur « configurer »
Dans « nom du projet » : taper le nom_du_projet
Dans « Ce build a des paramètres » : on a deux paramètres, BRANCHE et PORT, que l’on a configuré.
Dans « Environnement de build » -> « set build name » : ${ENV,var=« BRANCHE»}#{BUILD_NUMBER}
Dans « Build » -> « SSH site » : nom_de_la_machine
Dans « command »: on execute la commande ci-dessous qui fabrique le patch full et le met dans le format attendu par la suite du traitement.
On supprime les anciennes images si elles existent :
La configuration avait été effectuée pour ne supprimer que des images vieilles de plus de trois jours.
Dans « Docker command » : choisir l’option « Create Build image » dans le menu déroulant et renseigner le champ associé avec la commande :
Dans « Build context folder » : on indique le répertoire de création de l’image.
Dans « Tag of resulting docker image » : Indiquer un nom de TAG
Dans « Docker command » on choisit l’option « Create container » du menu déroulant, dans « container name » on choisit comme nom: TX_${BRANCHE}
On démarre le container en remplissant le champ : « Start Container » avec la commande appropriée.
CONCLUSION
Ce build d’automatisation de tests était synchronisé sur la fin de celui de la compilation dans Jenkins, ce qui nous avait considérablement simplifié les choses.
La puissance de Docker permettait d’aller plus loin , comme avec l’outil Docker rancher qui permet plein d’autres possiblités.
0 commentaire