Un micro-manifeste sur les tests continus pour DevOps

Tout le monde parle de DevOps ces jours-ci, et je pense que les principes sous-jacents sont assez bien compris.

Que signifie le test continu pour DevOps?

Le consensus général est que DevOps est une «infrastructure en tant que code» - l'unification des équipes de développement et d'exploitation grâce à l'automatisation.

Une autre façon de dire cela est de permettre à une application de passer des lignes de code écrites par les développeurs à une application entièrement déployée. La meilleure façon d'y parvenir est l'automatisation.

Agile dans DevOps

Une chose que nous entendons assez souvent lorsque l'on parle de DevOps est le concept d'Agile. Agile est une méthodologie de développement dans laquelle vous compressez les cycles de développement d'une application en petits morceaux afin que vous puissiez vous concentrer plus facilement sur la création de valeur incrémentielle pour une application.

Dans Agile, un projet qui prendrait traditionnellement 12 mois pour se terminer est divisé en une série de sprints qui durent généralement une à deux semaines.

Dans les sprints, le développement passe par tout le processus de décision d'un ensemble de user stories, de développement de ces user stories, puis de livraison de ces user stories. Sur une période de temps, vous livrerez finalement l'application complète. Mais comme vous le divisez en plus petits morceaux, vous pouvez vous enregistrer à chaque sprint pour vous assurer que vous construisez la bonne chose. C'est un catalyseur essentiel pour DevOps car il nous donne des points de contrôle pour automatiser la livraison de ces petits morceaux.

Qu'est-ce que le test continu?

Test continu est le processus de test continu de l'application. Cela ressemble à une évidence, mais il se présente sous deux formes.

Le premier chemin consiste à exécuter en permanence des tests sur l'application et à mesure que de nouvelles versions deviennent disponibles, ces tests vérifient que l'application fonctionne comme prévu. La nature continue de cette approche de test vous permet d'obtenir des commentaires immédiats chaque fois qu'il y a des changements de code et aide à garantir que quelque chose fait dans une version précédente n'affecte pas l'application dans son ensemble.

L'autre façon de penser aux tests continus est que le processus de test lui-même est continu. Cela signifie que dans le cadre de l'intégration continue de la construction continue et des pipelines de livraison continue, il existe également une piste de test continue. Cela signifie que l'automatisation des tests est intégrée au pipeline de construction et de publication et peut servir de porte qualité pour garantir que les applications répondent à des spécifications spécifiques avant qu'elles ne soient automatiquement déployées via DevOps.

Si vous y réfléchissez bien, les tests continus sont essentiels pour DevOps car ils servent de mécanisme pour arrêter le tapis roulant si quelque chose ne va pas avec l'application. Si vous prenez vos builds et que vous les poussez immédiatement à travers l'automatisation jusqu'au processus de livraison, vous pourriez déployer des défauts en production. Donc, c'est pourquoi je pense que l'image complète est DevOps et tests continus.

De quoi avez-vous besoin pour activer les tests continus pour DevOps?

Il existe de nombreuses technologies que les équipes peuvent exploiter pendant la phase de tests automatisés du Pipeline DevOps. Individuellement, chacune de ces techniques et processus de test est très précieux. Le véritable rapport qualité-prix réside dans l’intégration de chaque technologie et processus de bout en bout.

Analyses de code automatisées

Dans les analyses de code automatisées, vous exécutez essentiellement une vérification orthographique de votre code. Ceci est souvent appelé analyse de code statique et cela se produit dès que les lignes de code sont écrites.

L'idée est que l'outillage recherchera des modèles dans le code connus pour conduire à de mauvaises pratiques ou à des défauts sur toute la ligne. Avec cette approche, vous évitez, plutôt que de détecter, les défauts avant qu'ils ne soient introduits dans vos applications.

Exécution de test automatisée

Une fois qu'une application est créée, le code est masqué. La meilleure façon de tester ensuite votre application est donc de valider les entrées et les interfaces utilisateur. Vos objectifs ici sont Test de l'interface utilisateur, tests d'API, tests de bases de données, tests de performances et tests de sécurité. Vous voulez pouvoir exécuter des tests de régression complets sur les interfaces utilisateur et toucher chacune des API exposées.

Ces tests sont appelés tests fonctionnels et vous permettront de valider que les applications fonctionnent comme prévu. Il y a tout un monde de capacités ici et je pense personnellement que c'est un catalyseur essentiel du processus DevOps, car les choses ont tendance à devenir bizarres lorsqu'elles sont intégrées les unes aux autres. Et donc, un endroit pour vraiment regarder ici est dans les tests d'API.

Gestion des exigences

Lorsque nous construisons une application, nous construisons une association avec les exigences. De cette façon, nous avons un cadre pour la construction de l'application, mais nous connaissons également les attentes de l'entreprise. Les tests doivent suivre le même paradigme. Vous créez des tests associés aux exigences. Cela vous aide non seulement à comprendre si vous avez suffisamment couvert l'application pour garantir aux parties prenantes que l'application présente un niveau de risque suffisant pour la publication, mais vous aide également à comprendre sur quels tests se concentrer lorsque des parties spécifiques de l'application se comportent mal. Le mappage des cas de test aux exigences devient un élément essentiel de la hiérarchisation et de la correction dans l'automatisation des tests.

La Gestion du changement

«Continu» est un effort pour atteindre une plus grande vitesse. Lorsque nous avançons si vite, si quelque chose change et que nous ne nous y attendions pas, notre pipeline pourrait se rompre.

L'automatisation des tests est une sonnette d'alarme pour nous aider à nous assurer que nous fournissons un logiciel précieux sans défaut dans le pipeline de livraison. Si l'application change, le logiciel automatisé doit le savoir et doit s'adapter à ces changements afin que vous n'obteniez pas de faux positifs ou, pire, de faux négatifs. L'intégration d'un processus de gestion du changement dans le pipeline DevOps vous permet de vous assurer que les résultats issus de vos tests automatisés sont valides.

Données de test

L'accès à des données de test utilisables et sûres est un élément essentiel des tests continus pour DevOps. Pour créer un pipeline DevOps évolutif, vous devez être en mesure de disposer d'une combinaison de données de test réalistes et / ou générées synthétiquement qui peuvent être injectées dans votre automatisation de test afin que vous disposiez de suffisamment de données pour effectuer les tests que vous souhaitez réaliser.

Accès à l'environnement de test et simulation

Plus tôt, j'ai mentionné que les tests fonctionnels interviennent lorsque l'application est créée. Un élément clé de ceci est le fait que cette application est construite et déployée dans une sorte d'environnement.

Avec l'essor des architectures et des microservices orientés services, les systèmes distribués sont un ensemble de petites applications et de points finaux qui doivent fonctionner les uns avec les autres. Pour exécuter cette automatisation de test, vous devez disposer d'un environnement de test stable avec toutes les dépendances nécessaires. C'est là que la simulation peut devenir un catalyseur essentiel pour le pipeline DevOps. Grâce à la simulation, vous pouvez créer des jumeaux numériques de points de terminaison qui ne sont pas disponibles ou qui ne disposent pas des données de test appropriées au moment où vous souhaitez exécuter l'automatisation des tests.

En combinant la virtualisation des services avec DevOps, vous pouvez supprimer les contraintes environnementales. Cela permet à l'organisation d'obtenir un accès et un contrôle complets sur l'environnement de test et même de déployer des environnements de test dynamiques.

Dans un environnement de test dynamique, vous déployez un environnement conteneurisé qui contient principalement des composants simulés. Grâce à cette configuration, vous pouvez vous concentrer sur les applications que vous souhaitez valider et supprimer le reste.

Vous pouvez créer plusieurs copies de ces environnements de test dynamiques, car si vous pensez à la manière dont le pipeline DevOps réel se déroulera, les exécutions de test s'exécuteront en fonction des archivages de code. Il peut y avoir plusieurs enregistrements de code à un moment donné, et vous ne voulez pas que les gens font la queue en attendant qu'un véritable environnement de test soit disponible. Les environnements de test dynamiques peuvent être l'un des catalyseurs les plus critiques requis pour les tests continus et DevOps.

Rétroaction continue

Tout ce que nous faisons dans les tests continus de DevOps consiste à obtenir des résultats significatifs sur lesquels nous pouvons agir. La dernière pièce du puzzle est la rétroaction continue.

Dans un retour d'information continu, vous prenez les résultats de vos tests automatisés et les combinez avec d'autres mesures liées à la qualité telles que la couverture des exigences, la couverture des API et la couverture du code. Vous pouvez ensuite les évaluer de manière automatisée pour vous assurer qu'ils se situent dans les seuils définis pour l'acceptation de la qualité.

Si l'application est correcte, elle est automatiquement déployée à l'étape suivante. Si ce n'est pas le cas, vous pouvez arrêter le processus de déploiement et le renvoyer au développement associé à l'archivage d'origine. Ce mécanisme de rétroaction rapide et itératif vous permet d'avoir vraiment confiance dans vos tests continus pour DevOps.

Résumé

Il ne s'agit que d'une vue de haut niveau de ce qui est nécessaire pour permettre une stratégie d'automatisation des tests évolutive et fiable pour votre pipeline DevOps. Il y a beaucoup plus d'informations nécessaires au fur et à mesure que vous approfondissez chacun de ces sujets individuels. L'intention de ce blog est de fournir un résumé condensé, facilement consommable.

Je vous encourage à consulter notre livre blanc sur les tests continus pour DevOps. Nous explorons les détails du retour sur investissement, des déploiements et des indicateurs de performance clés pour savoir si vous apportez la bonne technologie au bon moment pour votre pipeline DevOps.