Faire gagner du temps aux développeurs de CucumberStudio

Interview réalisée avec Christophe Bliard, développeur et co-fondateur de HipTest, la première plateforme de tests continus, dédiée aux équipes Agiles et DevOps.

Présentation

Je suis Christophe Bliard, développeur chez SmartBear et l'un des 5 co-fondateurs de HipTest, aujourd'hui CucumberStudio.

EN mai 2018, nous avons rejoints SmartBear, le leader du marché du test. SmartBear possède également d'autres entreprises telles que Swagger, SoapUI, TestComplete and Zephyr.

Qu’est-ce que CucumberStudio et quels problèmes résout la plateforme ?

CucumberStudio est une plateforme collaborative de test continus, dédiée aux équipe agiles et DevOps. Elle favorise la collaboration entre les équipes métiers et techniques grâce à son support natif de la méthodologie BDD (Behavior Driven Development).

Le problème majeur que CucumberStudio pallie est le manque de collaboration et de compréhension dans les équipes. Grâce à l’utilisation de BDD, les différentes parties d’une équipe sont à même de comprendre la fonctionnalité à développer.

Combiner à cela, CucumberStudio propose une fonctionnalité nommée « Living Documentation ». Celle-ci permet d’avoir accès à une documentation vivante, c'est-à-dire toujours à jour. Ainsi, on peut savoir en un coup d’oeil ce qui a été développé. Le petit plus est que cette documentation est écrit en langage naturel et donc compréhensible par tous.

L’autre point sur lequel CucumberStudio est pertinent concerne l’automatisation des tests. En effet, avec CucumberStudio vous pouvez générer des scripts exécutables pour le framework que vous souhaitez (nous supportons près de 25 frameworks). Un véritable gain de temps !

Qu’est-ce que le Behavior Driven Development (BDD) ? Et quelle difference avec le Test Driven Development (TDD) ?

BDD est une méthode agile qui a pour objectif de favoriser la collaboration entre les différents membres d’un même projet (développeurs, testeurs, product owners, business…), afin de délivrer la fonctionnalité attendue, le plus rapidement possible.

En utilisant des exemples écrits avec une syntaxe et une terminologie commune, toute l’équipe comprend les actions que doit effectuer le produit. Ces exemples sont rédigés grâce à l’utilisation de la syntaxe Gherkin : “Given…When…Then (Étant donné que…. Quand….Alors). On convertit ces exemples en spécifications exécutables, ce qui permet de s’assurer que le code correspond aux critères d’acceptation définis en amont.

Les deux méthodes BDD et TDD sont complémentaires et couvrent des aspects très différents de la qualité logicielle. Dans l’approche TDD, un développeur va écrire une série de tests permettant de s’assurer que le code correspond aux spécifications, tout au long du développement d’une fonctionnalité. Dans l’approche BDD, les scénarios (ou exemples), sont écrits en collaboration entre les développeurs, l’équipe produit et l’équipe qualité. Les discussions menées vont permettre de créer une vision partagée de la nouvelle fonctionnalité, permettant d’assurer ainsi un développement correspondant aux besoins de l’équipe produit. Et pour ne rien gâcher, ces scénarios peuvent ensuite être traduits en tests exécutables, permettant ainsi de compléter ceux écrits par l’approche TDD.

Exemple d’un scénario BDD :

Given user « JohnDoe » is registered on the site
When user « JohnDoe » logs in
Then a welcome message is displayed

Pourquoi et comment utilisez-vous Scalingo ?

Nous avons fait le choix d’héberger CucumberStudio sur un « Platform as a Service » (PaaS) afin de gagner du temps. En effet, utiliser Scalingo nous permet de nous concentrer sur la production de code, ce qui représente notre réelle plus-value.

Pour l’anecdote, nous sommes l’un des plus vieux clients de Scalingo puisque lorsque HipTest a été créé nous avons fait le choix de Scalingo dès 2015.

CucumberStudio est un monolithe Ruby on Rails, ce qui signifie que plusieurs containers XL reçoivent les requêtes web. Les tâches à exécuter sont ensuite empilées dans une base de données Redis puis dépilées par des background jobs delayedjobs ou sidekiq (delayedjobs et sidekiq sont deux bibliothèques Ruby permettant d’exécuter des tâches asynchrones). On a défini plusieurs types de workers consommant des jobs de manières différentes.

Chaque type de worker a un nombre et un type de containers différents afin d’effectuer le travail plus rapidement. Notre fichier Procfile fait plus d’une dizaine de lignes !

Cette architecture nous permet de tenir facilement 1500 RPM en moyenne.

Le déploiement sur Scalingo s’exécute avec un multi-buildpack comprenant les buildpacks Ruby, Node, EmberJS et Datadog.

Nous utilisons Ruby puisque notre application est une API Ruby on Rails. Node et EmberJS parce que l’interface utilisateur est une SPA (Single Page Application) écrite en EmberJS. Nous avons choisi Datadog pour leur agent de remontée de métriques de consommation mémoire, CPU.

Nous utilisons PostgreSQL comme base de données et Elasticsearch comme moteur de recherche. D’ailleurs, tout au début de la société, nous utilisions PostgreSQL comme moteur de recherche, mais avec la charge et la complexité, nous avons préféré passer sur Elasticsearch. A ce jour la base de données PostgreSQL contient 225,5 Go de données.

Notre service open source CucumberStudio Publisher est également hébergé sur Scalingo. Il permet de générer automatiquement des suites de test dans différents langages de programmation à partir des scénarios écrits sur CucumberStudio, Nos clients peuvent également télécharger et exécuter CucumberStudio Publisher depuis leurs machines de développement.

Sur chaque application nous utilisons le Log Drain Scalingo dédié à Datadog et AppSignal pour la remontée d’erreurs.

Enfin la récente annonce au sujet de l’API de base de données Scalingo qui facilite le téléchargement des sauvegardes nous permet d’envisager de nouveaux workflows, comme par exemple reconstruire des environnement de tests locaux sur des serveurs physiques dans nos propres bureaux.

Une anecdote à partager ?

Quand la société HipTest a été créé, nous sommes partis du principe que tous les membres de l’équipe doivent se partager le support. Il me semble que chez Scalingo vous appliquez le même principe d’ailleurs. Assez rapidement il s’est avéré que nos développements “produit” étaient entrecoupées de session de support et nous avions l’impression de perdre en productivité. C’est pourquoi, nous avons décidé de faire un roulement : toutes les semaines chacun allait prendre le support entièrement à sa charge. Nous appelions cette personne le “Batman” : celui qui est là pour sauver les gens.

Évidemment, à certains moments il y a beaucoup de discussions au support. On a donc adjoint à Batman un “Robin” pour le seconder dans les moments difficiles.

Par la suite, nous avons embauché une personne complètement dédiée au support. Le souci que nous avons rencontré est que cette personne est basée en France et que nous avons beaucoup de clients américains. Cette personne passait beaucoup de temps en soirée pour répondre aux diverses demandes de l’autre côté du globe. Nous avons donc réintroduit le rôle de “Batman” pour la seconder, notamment en soirée en heures françaises.