Squash AUTOM, Squash DEVOPS, une génèse
Petit retour sur nos projets Squash AUTOM et Squash DEVOPS, et sur leur genèse.
Squash TM est un gestionnaire de cas de test. Il permet de collecter un ensemble de cas de test, de les rédiger, de les organiser, de les exécuter, et de présenter les résultats de ces exécutions.
L’exécution des tests était à l’origine manuelle : une personne exécute l’ensemble des étapes décrites et reporte les résultats.
Ce mode d’exécution manuel permet de couvrir l’ensemble des besoins de tests fonctionnels, mais il n’est pas optimal : si certains tests ne peuvent être fait que de cette manière, manuellement, de nombreux autres tests peuvent faire l’objet d’une automatisation.
Les tests automatisés permettent de nouveaux usages : ils peuvent être exécutés beaucoup plus souvent, en dehors des heures ouvrées le cas échéant, et peuvent donc intervenir plus tôt dans le cycle de développement des applicatifs.
Avec Squash TA et Squash TF nous avions fait un premier pas vers ces nouveaux cas d’usage, en permettant l’implémentation et l’exécution de tests automatisés.
Avec Squash AUTOM et Squash DEVOPS, nous souhaitons aller plus loin.
Fonctionnellement, ce sont des outils d’exécution de tests automatisés. À partir d’une liste de tests automatisés, définis dans un ou plusieurs dépôts de tests, ils coordonnent l’exécution des tests demandés à partir d’environnements d’exécution existants vers un système à tester déployé.
Les rapports d’exécution des tests peuvent être publiés vers un ou plusieurs destinataires, gestionnaires de cas de test ou plateformes de visualisation ou de reporting.
Une douane applicative, alimentée par ces mêmes rapports d’exécution, peut être mise en place.
Le déclenchement de l’exécution des tests est à la demande (Squash AUTOM) ou à l’initiative d’une chaîne d’intégration continue (Squash DEVOPS).
La liste de tests à exécuter est alimentée dynamiquement par un ou plusieurs gestionnaires de cas de test, ou construite explicitement. Les tests à exécuter peuvent faire appel à un nombre quelconque d’automates de tests.
Comme il nous paraît essentiel que ces fonctionnalités soient ouvertes et que tout un chacun puisse contribuer, cela s’appuie sur un ensemble de spécifications ouvertes accompagné d’une implémentation de référence open source, proposés dans le cadre de l’OpenTestFactory.
Squash AUTOM et Squash DEVOP sont de fait deux ‘distributions’ de cette implémentation de référence, adaptées à leurs besoins spécifiques.
Cela permet une adaptation simple, rapide, aux nouveaux besoins : nouvel outil d’intégration continue, nouveau framework d’automatisation, adaptation à un ensemble de tests automatisés existants dans un framework développé en interne, publication des rapports vers un outil de BI, …
Cela permet également l’intégration de nouvelles fonctionnalités par des entreprises tierces ou par des développements internes.
Le cœur de l’implémentation de référence est constitué d’un orchestrateur et d’un ensemble de spécifications qui régissent les interactions entre composants / plugins.
L’orchestrateur n’est plus Jenkins (contrairement à Squash TA / Squash TF), dont le rythme d’évolution s’est avéré non gérable, mais une implémentation propre.
Nous ne sommes pas les seuls à avoir suivi ce cheminement. En l’absence de standard de fait, neutre, permettant à des outils d’intégrer des pipelines, le même chemin a été suivi par GitLab, GitHub, JFrog, Atlassian, pour ne citer que quelques exemples.
Les fonctionnalités de l’orchestrateur sont les mêmes. Les composants / plugins sont orientés vers nos besoins (discussions avec des frameworks d’automatisation, avec des gestionnaires de cas de tests, avec des outils de publication des rapports de tests), mais, in fine, l’orchestrateur fournit les mêmes briques de base que n’importe quel autre orchestrateur.
Les spécifications qui régissent les interactions entre composants / plugins ont fait l’objet d’une attention particulière, afin qu’elles soient simples à comprendre et à mettre en œuvre.
Elles se basent sur des technologies connues, communes, largement supportées (API REST, format d’échange JSON), qui permettent des développements et des déploiement simples.
De par cette utilisation de technologies connues, communes, largement supportées, elles n’imposent pas un langage ou un environnement logiciel spécifique. L’implémentation de référence est ainsi essentiellement écrite en Python et les composants additionnels des ‘distributions’ Squash AUTOM et Squash DEVOPS écrits essentiellement en Java.
L’architecture retenue, un ensemble de micro-services qui échangent via un bus d’événement, apporte une grande souplesse pour le déploiement, qu’il s’agisse d’une installation sur un système isolé, d’un unique conteneur Docker, ou bien encore sur un cluster Kubernetes.
Ce qui permet une intégration facile dans nombre de contextes, là encore sans imposer une technologie ou architecture particulière.
Enfin, la sécurité primant, les demandes d’exécution sont contrôlées via l’utilisation de tokens JWT signés, et les communications avec les environnements d’exécution, à partir desquels les tests seront exécutés, peuvent se faire via SSH (de l’orchestrateur vers un environnement d’exécution) ou via un agent installé sur l’environnement d’exécution qui interroge régulièrement l’orchestrateur (de l’environnement d’exécution vers l’orchestrateur, donc).
Dans de prochains articles nous reviendrons plus en détails sur ce que permettent ces choix, et comment ils peuvent vous aider dans votre quotidien.
Martin Lafaix
Architecte
Pour en savoir plus :
