Phases de test de l'intégration continue et de la livraison continue

Les trois équipes d'intégration continue/livraison continue doivent intégrer les tests dans le cycle de vie du développement logiciel aux différentes phases du pipeline CI/CD. Dans l'ensemble, les tests doivent commencer le plus tôt possible. La pyramide de tests ci-dessous est un concept fourni par Mike Cohn dans son ouvrage Succeeding with Agile. Elle illustre les différents tests logiciels en fonction de leur coût et de leur rapidité d'exécution.

Pyramide de tests CI/CD

Les tests unitaires se trouvent au bas de la pyramide. Ils sont les plus rapides à exécuter et les moins chers. Par conséquent, les tests unitaires doivent constituer l'essentiel de votre stratégie de tests. En règle générale, ils doivent représenter environ 70 % des tests. Les tests unitaires doivent avoir une couverture de code quasi complète car les bogues détectés à cette phase peuvent être corrigés rapidement et à moindre coût.

Dans la pyramide, les tests de service, de composants et d'intégration se situent au-dessus des tests unitaires. Ils nécessitent des environnements détaillés et sont donc plus coûteux en termes d'infrastructure et plus lents à exécuter. Les tests de performances et de conformité constituent le niveau supérieur. Ils nécessitent des environnements de qualité de production et sont encore plus coûteux. Les tests de l'interface utilisateur et d'acceptation par les utilisateurs se situent au sommet de la pyramide. Ils nécessitent eux aussi des environnements de qualité de production.

Tous ces tests s'inscrivent dans le cadre d'une stratégie complète visant à produire un logiciel de haute qualité. Cependant, dans une optique de développement rapide, l'accent est mis sur le nombre de tests et la couverture dans la moitié inférieure de la pyramide.

Les sections ci-dessous traitent des phases d'intégration continue/livraison continue.

Configuration de la source

Au début du projet, il est essentiel de configurer une source dans laquelle vous pouvez stocker votre code brut, ainsi que les modifications de configuration et de schéma. À la phase source, choisissez un référentiel de code source, tel qu'un référentiel hébergé dans GitHub ou AWS CodeCommit.

Configuration et exécution de générations

L'automatisation des générations est essentielle au processus d'intégration continue. Lors de la configuration de l'automatisation des générations, la première tâche consiste à choisir l'outil de génération adapté. Il existe de nombreux outils de génération, tels que :

• Ant, Maven et Gradle pour Java

• Make pour C/C++

• Grunt pour JavaScript

• Rake pour Ruby

L'outil de génération qui vous convient le mieux dépend du langage de programmation de votre projet et des compétences de votre équipe. Après avoir choisi l'outil de génération, toutes les dépendances et les phases de génération doivent être clairement définies dans les scripts de génération. Il est également recommandé de créer une version des artefacts de la génération finale, ce qui facilite le déploiement et le suivi des problèmes.

Phase de génération

Lors de la phase de génération, les outils de génération considèrent comme une entrée toute modification apportée au référentiel du code source, génèrent le logiciel, puis exécutent les types de tests suivants :

Tests unitaires : testent une section de code spécifique pour s'assurer que le code agit comme il est censé le faire. Les tests unitaires sont effectués par les développeurs de logiciels pendant la phase de développement. À ce stade, une analyse de code statique, une analyse du flux de données, une couverture de code et d'autres processus de vérification logicielle peuvent être appliqués.

Analyse de code statique : ce test se réalise sans exécuter réellement l'application après la génération et les tests unitaires. Cette analyse peut aider à détecter les erreurs de codage et les failles de sécurité ; elle peut aussi garantir la conformité aux directives de codage.

Phase intermédiaire

Au cours de la phase intermédiaire, des environnements complets sont créés pour refléter l'environnement de production final. Les tests suivants sont réalisés :

Tests d'intégration : contrôlent les interfaces entre les composants par rapport à la conception du logiciel. Il s'agit d'un processus itératif qui facilite la génération d'interfaces robustes et l'intégrité du système.

Tests des composants : testent le passage des messages entre les différents composants et leurs résultats. Ceci permet entre autres de contrôler l'idempotence des tests de composants. Les tests peuvent inclure des volumes de données extrêmement importants ou des situations périphériques et des entrées anormales.

Tests du système : testent le système de bout en bout et vérifie si le logiciel répond aux exigences de l'entreprise. Cela peut inclure le test de l'interface utilisateur (IU), de l'API, de la logique du backend et de l'état final.

Tests de performances : déterminent la réactivité et la stabilité d'un système lorsqu'il fonctionne sous une charge de travail particulière. Les tests de performances servent également à étudier, à mesurer, à valider ou à vérifier d'autres attributs de qualité du système, tels que la capacité de mise à l'échelle, la fiabilité et l'utilisation des ressources. Il peut s'agir de tests de charge, de tests de résistance et de tests de pics de charge. Ils permettent de procéder à une analyse comparative en fonction de critères prédéfinis.

Tests de conformité : vérifient si le changement de code est conforme aux exigences d'une spécification et/ou d'une réglementation non fonctionnelle. Ils déterminent si vous mettez en œuvre et respectez les normes définies.

Tests d'acceptation par les utilisateurs : valident le flux d'entreprise de bout en bout. Ce test est exécuté par un utilisateur final dans un environnement intermédiaire et confirme si le système répond aux exigences spécifiées. En règle générale, les clients utilisent à ce stade des méthodologies de test alpha et bêta.

Phase de production

Enfin, une fois les tests précédents réussis, la phase intermédiaire est répétée dans un environnement de production. Au cours de cette phase, un test canary final peut être réalisé en déployant le nouveau code uniquement sur un petit sous-ensemble de serveurs, voire un seul serveur, ou dans une Région AWS avant de le déployer dans l'ensemble de l'environnement de production. Les détails sur le déploiement en production en toute sécurité sont abordés dans la section Méthodes de déploiement.

La section suivante traite de la création du pipeline pour intégrer ces phases et ces tests.