Erreur de composition (pourquoi le déploiement en production est si difficile)
L’une des règles fondamentales qui permettent à DevOps de bien fonctionner pour livrer des logiciels est celle de « tester tôt, tester souvent ». En effet, une partie du domaine CI/CD (Continuous Integration/Continuous Delivery) est celle des builds et des tests automatisés de ces builds. Non seulement des composants individuels, mais de l’application dans son ensemble.
Le développement piloté par les tests (TDD) est une méthode, une autre consiste simplement à intégrer des tests unitaires et système dans le cadre du processus de création et de publication lui-même. Les tests fonctionnels et de régression sont impératifs et, dans les environnements hautement agiles, sont souvent déclenchés par un simple « commit » dans le référentiel.
On peut donc espérer qu’au moment où le logiciel sera « livré » entre les mains des personnes chargées de le déployer en production, il y aura une grande confiance dans son état de préparation.
Bien sûr, si c’était le cas, je n’écrirais pas ce post, 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 l’endroit où nous nous heurtons souvent à ce que l’on appelle en philosophie « l’erreur de composition ». Cette erreur logique est généralement appliquée aux arguments et aux preuves, mais il est intéressant de noter que c’est le logiciel qui constitue la base d’une explication simple de ce « mauvais argument » par l’auteur Ali Almossawi dans The Book of Bad Arguments (que je recommande vivement aux philosophes en herbe/champions de débat de tous âges) :
Erreur informelle, supposition 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, lorsque les modules sont intégrés, le système logiciel ne violera aucun des invariants vérifiés par ces tests unitaires . La réalité est que l'intégration de parties individuelles introduit de nouvelles complexités dans un système en raison de dépendances qui peuvent à leur tour introduire des voies supplémentaires d'échec potentiel. -- https://bookofbadarguments.com/ p.46
Désormais, à l’étape finale du processus CI/CD, le logiciel n’est pas nécessairement sujet à cette erreur. Il a été soumis non seulement à des tests unitaires, mais également à des tests sur l’intégration de ces unités pour former un « système » ou une application complète.
Mais une fois que le produit est mis en production, nous revenons à la case départ. Nous ne pouvons pas supposer que le système continuera à fonctionner comme prévu sur la base de ces tests. C’est parce que la définition de l’application vient de changer pour englober non seulement son logiciel et ses plateformes, mais aussi les composants de réseau et de service d’application nécessaires pour faire fonctionner l’application, pour ainsi dire, et la livrer aux écrans des consommateurs avides et des utilisateurs professionnels.
Les services réseau et applicatifs ont un impact sur le chemin de données le long duquel les requêtes et les réponses doivent transiter . De nombreux services, mais pas tous, peuvent en fait modifier ces demandes et réponses d’une manière que les développeurs n’avaient pas anticipée. Il est donc possible (et souvent probable) qu’une fois dans l’environnement de production – même si chaque service et composant d’application ont été rigoureusement testés – l’application rencontre une défaillance. Un échec. Se tromper.
C’est parce que nous sommes tombés dans le piège de la composition dans l’environnement de production. Bien que les développeurs d’applications (et DevOps) comprennent cette erreur et la corrigent lors des tests de pré-production, nous ne parvenons souvent pas à reconnaître que l’intégration au niveau de la couche réseau reste une intégration et peut en fait avoir un impact sur l’intégrité opérationnelle de l’ensemble.
La réponse semble évidente : eh bien, on va simplement tester en production alors !
Sauf que nous ne le ferons pas, et vous et moi savons que nous ne le ferons pas. Parce que la production est un environnement partagé et que des tests rigoureux dans un environnement de production augmentent le risque de dommages collatéraux aux ressources et systèmes partagés, ce qui peut provoquer des pannes. Les pannes entraînent une baisse des profits et de la productivité, et personne ne veut en être responsable. Il est bien plus facile d’effectuer les tests individuels possibles en production, puis de pointer du doigt les développeurs plus tard lorsque quelque chose ne fonctionne pas comme annoncé.
Il s’agit en fin de compte de l’un des moteurs silencieux de la révolution logicielle qui dévore les réseaux de production. Par le passé, il était trop difficile et coûteux de reproduire et de maintenir un environnement de test correspondant à l’environnement de production. Certaines de ces infrastructures partagées sont coûteuses et occupent beaucoup d’espace. Dupliquer ce réseau n’est pas judicieux d’un point de vue financier ou opérationnel.
Mais l’introduction et l’adoption ultérieure des logiciels grâce au cloud computing et à la virtualisation ont commencé à mettre en évidence l’idée que la réplication des réseaux basés sur des logiciels est non seulement abordable, mais aussi plus facile grâce à des concepts tels que l’infrastructure en tant que code. De plus, vous pouvez le répliquer, le tester et le démonter, ce qui signifie que les ressources peuvent être réutilisées pour faire la même chose pour d’autres applications.
Nous n’y sommes pas encore, mais nous nous en rapprochons. L’intégration de services d’application et de réseau virtuels (logiciels) dans le pipeline CI/CD est en réalité beaucoup plus réelle que certains pourraient le penser. Les services traditionnels basés sur l’infrastructure (réseau) – équilibrage de charge, routage des applications, sécurité des applications Web – sont fortement intégrés au cycle de création de logiciels grâce à leur intégration dans des environnements tels que les architectures basées sur des conteneurs. En tant que solutions logicielles, elles peuvent être incluses au moins dans la phase de test du processus de construction, et ainsi renforcer la confiance que le déploiement en production n'introduira pas de défauts ou d'erreurs.
En s’appuyant sur ce logiciel, l’application de « l’infrastructure en tant que code » va encore plus loin. Lorsque les politiques et les configurations peuvent être conçues et affinées pendant les cycles de création et de publication, puis déployées en production avec peu ou pas de modifications, nous sommes définitivement plus proches d’éliminer les erreurs de composition qui existent en production.
Plus ces services (les plus centrés sur les applications) sont intégrés dans la phase de test CI/CD, plus chacun peut avoir confiance dans un déploiement de production réussi.
Car l’autre erreur qui existe aujourd’hui est que tester par rapport à la « production » signifie « systèmes de production ». Il n’inclut souvent pas les services d’application qui forment le chemin de données en production. Il le faut, pour que nous puissions réduire les erreurs à celles qui sont vraiment ésotériques et avoir réellement le temps et les ressources pour les corriger.