Les tests continus, pilier du DevOps

Sommaire

Introduction

CI et CD

Nous présentons ici les notions de base de l'Intégration Continue et de la Livraison Continue.

La CI vise à accomplir ce qui suit :

• Détecter chaque fois qu'une partie d'un produit a été modifiée
• (Re)construire et (ré)assembler un produit à partir de ses composants
• Installer cet assemblage dans des environnements où il peut être exécuté ou utilisé
• Surveiller ces étapes et faire remonter les succès/échecs aux bonnes parties prenantes

Elle est souvent mise en œuvre sous la forme d'une boucle ou d'un graphe qui lance de multiples outils spécialisés, récupère leurs rapports, les analyse et présente les informations de synthèse dans un tableau de bord. Parmi les outils connus figurent Jenkins, Hudson, Bamboo et TeamCity.

La CD vise à accomplir ce qui suit :

• Détecter chaque fois qu'un produit est prêt
• Identifier et préparer les environnements cibles
• Installer (ou livrer) le produit
• Communiquer avec les bonnes parties prenantes, y compris les utilisateurs
• Déclencher les processus post-installation (marketing, support, maintenance, supervision)

Dans la plupart des organisations, l'essentiel de cela est intégré dans la boucle de CI.

Depuis le moment où vous modifiez une partie de votre produit jusqu'au moment où vous le mettez en production ou le livrez aux consommateurs, un ensemble de vérifications et de validations doit avoir lieu. Vous devez répondre à certaines questions :

• Votre produit fonctionne-t-il toujours comme prévu ?
• Est-il toujours sûr à utiliser ?
• La nouvelle fonctionnalité apporte-t-elle une réelle valeur aux utilisateurs ?
• Sommes-nous prêts à le supporter ?
• Sommes-nous en phase avec nos campagnes marketing ?

Pipeline de livraison

Une autre notion utile, devenue plus répandue, est celle de pipeline de livraison.

Dit simplement, c'est le processus que subit un produit chaque fois qu'il doit être livré à vos utilisateurs et clients. Définir un pipeline de livraison, c'est comme pour tout processus :

• Définir les étapes
• Déterminer les conditions permettant de passer d'une étape à l'autre
• Identifier les tâches de chaque étape
• Définir les conditions (pré et post) et les résultats attendus de ces tâches
• Et ainsi de suite

Voici un schéma d'étapes courant, à ne toutefois pas considérer comme une bonne pratique recommandée :

• Construire et intégrer au sein du système (build & intégration système)
• Tester les fonctions (tests de qualité produit)
• Vérifier que l'utilisation est sûre et sécurisée (vérification sécurité/sûreté)
• Tester l'intégration avec les environnements environnants (tests de bout en bout)
• S'assurer que les utilisateurs en retirent une réelle valeur (tests de recette utilisateur)
• Si nécessaire, vérifier qu'il est robuste, scalable...

Notez que le pipeline de livraison n'impose pas l'ensemble des environnements de test. Les tests d'intégration système et fonctionnels produit peuvent être réalisés sur un environnement de QA, tandis que les tests de sécurité/sûreté, de bout en bout et de recette utilisateur peuvent être réalisés sur un environnement de staging, et les tests de type '-ités' seraient réalisés sur un environnement de pré-production.

Et les CT dans tout ça ?

Un pipeline de livraison réalise donc 4 types de tâches :

• Mettre en place et nettoyer les environnements si nécessaire
• Installer les produits
• Vérifier et valider
• Prendre des décisions ou aider à les prendre entre les étapes

Dans l'industrie pilotée par le logiciel, l'ensemble de tâches le plus chronophage est (enfin... 'devrait être') la Vérification et la Validation.

À chaque étape, vous devez effectuer des tests spécifiques pour vous assurer que votre produit, nouveau ou modifié, répond bien à ses attributs de qualité et aux valeurs attendues.

Chaque fois que vous souhaitez livrer une nouvelle version du produit, vous devez vous assurer qu'elle améliore, ou du moins maintient, le même niveau de qualité et de sécurité perçues que la version précédente, tout en apportant de nouvelles fonctionnalités ou en améliorant les existantes.

Voici ce que les Tests Continus apportent :

• Tester et mesurer les niveaux de qualité sans relâche
• Le faire aussi rapidement et facilement que possible
• Fournir aux décideurs les bonnes informations pour piloter le pipeline de livraison
• Automatiser la décision chaque fois que possible

Si l'on prend l'exemple de l'étape de Tests Fonctionnels, on pourrait observer les étapes suivantes.


Notez que la mise en place de l'environnement et le nettoyage peuvent être extrêmement chronophages et coûteux selon le type de produit concerné (un simple logiciel n'est pas aussi complexe qu'une automobile, par exemple...).

Chaque étape est un test

Toute étape (y compris la mise en place d'un environnement), lorsqu'elle ne nécessite pas trop d'interventions manuelles, devrait être automatisée et son résultat vérifié comme pour tout test.

Par exemple, si vous vous appuyez sur des machines virtuelles (VM), vous pouvez utiliser Vagrant pour les démarrer, puis effectuer quelques vérifications pour vous assurer qu'elles sont bien opérationnelles. Lors de l'installation du produit, vous pouvez utiliser ANSIBLE pour le déployer et le configurer, puis vérifier certains fichiers. Vous pouvez ensuite lancer des tests de fumée de base à l'aide de Robot Framework ou SOAPUI pour les API, et ainsi de suite.
C'est là qu'intervient XQual.

La capacité de XQual à lancer tout type de tests et à interpréter et récupérer les résultats facilite considérablement la gestion d'un pipeline de livraison.

Vous concevez vos campagnes pour chaque étape. Une fois exécutée, chaque session de test fournit les résultats des tests. Ceux-ci servent à décider de la marche à suivre pour l'étape suivante.

Vous utilisez un outil de CI tiers pour orchestrer les différentes campagnes.

Le XContinuousIntegration de XQual est utilisé par ces outils de CI pour lancer les différentes campagnes et en récupérer les rapports et les résultats de test.


XContinuousIntegration fournit tous les rapports détaillés et ajoute un fichier de synthèse au format JUNIT que les différents outils de CI peuvent analyser. C'est l'outil de CI qui reste seul décisionnaire de la gestion de la boucle (par exemple, pour savoir si l'étape suivante peut démarrer ou si l'étape en cours doit être arrêtée).
Quel que soit l'outil de gestion de tests que vous utilisez, l'automatisation est un facteur clé si vous voulez tenir un cycle de livraison plus rapide.

XQual prend en charge près de 90 frameworks de test automatisé et vous pouvez en ajouter un nouveau en quelques heures seulement. Mais rien ne se passera si vous n'investissez pas dans l'automatisation des tests.