L’une des règles fondamentales qui permettent au DevOps de livrer efficacement des logiciels est de « tester tôt et souvent ». En effet, la création de builds et leur test automatisé font partie intégrante de la CI/CD (intégration continue/livraison continue). Ces tests ne portent pas uniquement sur les composants individuels, mais sur l’ensemble de l’application.
Le développement piloté par les tests (TDD) est une méthode ; une autre consiste simplement à intégrer les tests unitaires et système au processus même de compilation et de publication. Les tests fonctionnels et de non-régression sont indispensables et, dans les environnements très agiles, ils sont souvent déclenchés par un simple « commit » dans le dépôt.
Ainsi, on peut espérer qu’au moment où le logiciel est « livré » aux personnes chargées de son déploiement en production, celles-ci ont pleinement confiance dans le fait qu’il est prêt.
Bien sûr, si c’était le cas, je ne serais pas en train d’écrire cet article, n’est-ce pas ?
Le mur par-dessus lequel les logiciels sont livrés en production (et ne vous y trompez pas, ce mur existe toujours) est précisément l’endroit où nous nous heurtons souvent à ce que la philosophie appelle le « sophisme de composition ». Ce sophisme logique s’applique généralement aux raisonnements et aux démonstrations, mais, fait intéressant, c’est le logiciel qui sert de base à une explication simple de ce « mauvais argument » proposée par l’auteur Ali Almossawi dans The Book of Bad Arguments (que je recommande vivement aux philosophes en herbe et aux futurs champions du débat, quel que soit leur âge) :
Sophisme informel, hypothèse injustifiée, composition et division
Chaque module de ce système logiciel a été soumis à une série de tests unitaires et les a tous réussis. Par conséquent, une fois les modules intégrés, le système logiciel ne violera aucun des invariants vérifiés par ces tests unitaires. En réalité, l’intégration de composants individuels introduit de nouvelles complexités dans un système en raison de dépendances qui peuvent à leur tour créer d’autres sources de défaillance potentielles. -- https://bookofbadarguments.com/ p. 46
À présent, au stade final du processus CI/CD, le logiciel n’est pas nécessairement sujet à ce sophisme. Il a été soumis non seulement à des tests unitaires, mais aussi à des tests d’intégration de ces unités afin de former un « système » ou une application complète.
Cependant, une fois l’application mise en production, nous revenons à la case trois. Ces tests ne nous permettent pas de présumer que le système continuera à fonctionner comme prévu. En effet, la définition de l’application vient de changer : elle englobe désormais non seulement ses logiciels et ses plateformes, mais aussi les composants réseau et les services applicatifs nécessaires pour la faire fonctionner, pour ainsi dire, et l’acheminer jusqu’aux écrans de consommateurs et d’utilisateurs professionnels impatients.
Le réseau et les services applicatifs ont une incidence sur le chemin de données que doivent emprunter les requêtes et les réponsesNombre de ces services, mais pas tous, peuvent en effet modifier ces requêtes et ces réponses d’une manière que les développeurs n’avaient pas anticipée. Il est donc possible (et même souvent probable) qu’une fois dans l’environnement de production, l’application rencontre un défaut, même si chaque service et chaque composant applicatif a été rigoureusement testé. Une défaillance. Une erreur.
Cela s’explique par le fait que nous avons succombé au sophisme de composition dans l’environnement de production. Si les développeurs d’applications (et les équipes DevOps) comprennent ce sophisme et en tiennent compte lors des tests de préproduction, nous omettons encore souvent de reconnaître que l’intégration au niveau de la couche réseau reste une forme d’intégration et qu’elle peut, de fait, compromettre l’intégrité opérationnelle de l’ensemble.
La réponse semble évidente : eh bien, nous n’aurons qu’à tester directement en production !
Sauf que nous ne le ferons pas, et vous le savez aussi bien que moi. Car la production est un environnement partagé, et des tests rigoureux dans cet environnement augmentent le risque de dommages collatéraux sur les ressources et systèmes partagés, susceptibles d’entraîner des interruptions de service. Ces interruptions se traduisent par une baisse des bénéfices et de la productivité, et personne ne veut en être tenu responsable. Il est bien plus facile d’effectuer en production les quelques tests individuels qui y sont possibles, puis de rejeter la faute sur les développeurs lorsque quelque chose finit par tomber en panne ou ne fonctionne pas comme prévu.
C’est en définitive l’un des moteurs discrets de la révolution logicielle qui gagne les réseaux de production. Autrefois, il était trop difficile et coûteux de reproduire et de maintenir un environnement de test identique à celui de production. Une partie de cette infrastructure partagée est onéreuse et occupe beaucoup d’espace. Dupliquer ce réseau n’est judicieux ni sur le plan financier ni sur le plan opérationnel.
Mais l’introduction, puis l’adoption des logiciels grâce au cloud computing et à la virtualisation ont commencé à mettre en avant l’idée que la réplication de réseaux logiciels est non seulement abordable, mais aussi plus facile grâce à des concepts tels que l’infrastructure en tant que code. Qui plus est, vous pouvez répliquer un tel réseau, y effectuer des tests, puis le démanteler, ce qui permet de réutiliser les ressources afin de procéder de même pour d’autres applications.
Nous n’y sommes pas encore, mais nous nous en rapprochons. L’intégration de services réseau et applicatifs virtuels (logiciels) dans le pipeline CI/CD est en réalité bien plus concrète qu’on pourrait le penser. Les services traditionnellement liés à l’infrastructure (réseau) — équilibrage de charge, routage des applications, sécurité des applications web — sont désormais étroitement intégrés au cycle de développement logiciel grâce à leur intégration dans des environnements tels que les architectures basées sur des conteneurs. En tant que solutions logicielles, ils peuvent être inclus au moins dans la phase de test du processus de développement, ce qui permet d’avoir davantage confiance dans le fait que le déploiement en production n’introduira ni défaillances ni erreurs.
Dans le prolongement de cette approche logicielle, l’application du concept d’« infrastructure en tant que code » permet d’aller encore plus loin. Lorsque les politiques et les configurations peuvent être conçues et affinées au cours des cycles de compilation et de publication, puis déployées en production avec peu ou pas de modifications, nous nous rapprochons indéniablement de l’élimination des erreurs de composition qui surviennent en production.
Plus ces services – les plus centrés sur les applications parmi les services applicatifs – sont intégrés à la phase de test CI/CD, plus chacun peut avoir confiance dans la réussite du déploiement en production.
Car une autre idée fausse répandue aujourd’hui consiste à penser que tester en « production » signifie tester les « systèmes de production ». Or, cela n’inclut souvent pas les services applicatifs qui constituent le chemin des données en production. Il faut les inclure afin de limiter les erreurs aux cas véritablement complexes et de disposer réellement du temps et des ressources nécessaires pour les résoudre.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.