Le débat sur le code n’est plus d’actualité. Le secteur de l’IT s’oriente nettement depuis quelques temps vers l’approche everything-as-code. De plus en plus, les entreprises acceptent l’idée de modéliser les composants du développement et de la livraison de logiciels sous forme de code. Si elles ne sont pas en mesure de traiter littéralement tout sous forme de code, elles en intègrent le plus possible, notamment au niveau des infrastructures, des réseaux, des workflows de livraison et des environnements. Pourquoi ? Car la capture de ces éléments sous forme de code permet de les versionner, de les partager, de les réutiliser et de les affiner par le biais de la collaboration. En bref, les entreprises qui adhèrent au concept everything-as-code appliquent à d’autres domaines des pratiques de développement de logiciels éprouvées. Elles accroissent ainsi l’automatisation et la reproductibilité, réduisent les erreurs et accélèrent les pipelines de déploiement.

Dans le contexte actuel, où les entreprises doivent fournir rapidement des logiciels d’excellence si elles veulent rester compétitives, les entreprises informatiques se tournent vers des pratiques telles que le déploiement continu et le DevOps. Celles-ci visent à assurer en permanence une livraison fiable de logiciels. Examinons plus en détails les bénéfices de la codification de la livraison grâce à l’approche everything-as-code pour les entreprises.

Application des bonnes pratiques de développement de logiciels à de nouveaux domaines

Foncièrement le code est un jeu de fichiers texte. Au cours des dernières décennies, un vaste éventail d’outils et de bonnes pratiques a été développé, dans le but de créer ces fichiers texte le plus rapidement possible, tout en réduisant au maximum le nombre d’erreurs. Par exemple, quasiment toutes les équipes de développement utilisent GitHub ou un autre outil de gestion de sources, conjointement à des pratiques de gestion des versions courantes, afin de gérer plusieurs variantes de leur code lors de son développement. Ces outils et pratiques sont intégralement dévolus à une collaboration plus efficace et plus transparente entre les équipes et au suivi des différences dans le code. La vérification et la traçabilité étant assurées, les équipes savent qui a apporté des modifications et à quel moment. En outre, les équipes peuvent construire en toute fiabilité et à tout moment une version de leur application depuis leur code versionné, la restauration et la reproductibilité étant prises en charge par ces outils.

Le concept everything-as-code permet d’étendre les avantages des outils et des pratiques de gestion des versions, ainsi que des nombreux autres outils et pratiques de développement de logiciels, à la quasi-totalité de tous les autres aspects du processus de développement et de livraison logiciels.,. Par exemple, lorsqu’une configuration, un workflow ou un environnement a été capturé(e) via YAML, JSON ou toute autre syntaxe lisible, il est toujours possible de le ou la recréer. Les outils et pratiques de développement de logiciels classiques offrent les mêmes avantages de vérification, de traçabilité, de reproductibilité, de réutilisation que vous obtenez pour votre code applicatif dans d’autres domaines de livraison de logiciels.

Quels autres domaines peuvent être gérés par le biais d’une approche everything-as-code ?  Ils sont étonnamment nombreux :

  • Réseaux: avec les réseaux définis par logiciel, les équipes initialisent, contrôlent, modifient et gèrent dynamiquement, par le biais de programmes, le comportement du réseau via des interfaces ouvertes.[1]
  • Workflows de création et de déploiement: les équipes chargées du développement et des opérations modélisent les pipelines de livraison de logiciels en code afin d’assurer une livraison continue et d’accélérer les cycles de développement.
  • Infrastructure: le concept d’infrastructure-as-code, faisant appel à des outils comme Chef, Puppet, Ansible, etc, permet aux entreprises d’orchestrer rapidement les configurations des systèmes et des environnements, et ce, à grande échelle.
  • Environnements: à l’aide de la technologie de conteneurs, les développeurs définissent des environnements entiers sous forme de code, en tant que systèmes autonomes. Par exemple, Docker fait appel aux Dockerfiles textuels pour créer des images partageables adaptées à des exigences d’infrastructure spécifiques.
  • Tests: les tests non fonctionnels (notamment les tests unitaires, de performance et de charge), ainsi que les tests fonctionnels (notamment les tests d’acceptation et les tests créés pour un développement piloté par les comportements) sont définis et gérés par le biais d’un programme, via une large gamme d’outils et de langages de script

Exploitation de la puissance d’une représentation programmatique normalisée

L’approche everything-as-code permet également de fournir une représentation normalisée du processus de livraison de logiciels. Une représentation normalisée est une vue partagée entre les parties prenantes, qui définit le processus clairement et sans ambiguïté, offrant des informations pouvant par ailleurs être difficiles à obtenir, ainsi qu’un mécanisme améliorant la collaboration entre les parties prenantes.

La quasi-totalité des entreprises dispose d’une gamme étoffée d’outils propres aux domaines, régissant le pipeline de développement et de livraison. Traditionnellement, l’accès à chaque outil doit s’effectuer via son interface utilisateur dédiée, pour pouvoir configurer des aspects du processus. Dans cet environnement, l’intégralité du processus est répartie sur des interfaces utilisateur disparates, ce qui complexifie l’obtention d’une vue commune du pipeline de livraison.

Contrairement à une approche de type everything-as-code, les outils sont contrôlés et configurés à l’aide de programmes via des API (interfaces de programmation d’applications), des SDK et des représentations textuelles, permettant la codification du processus en une représentation normalisée et partagée. De telles représentations peuvent aisément être partagées avec d’autres équipes, dans l’entreprise ou hors de celle-ci via GitHub, qui peuvent alors fournir un feedback et apporter des améliorations. Le fait de définir l’environnement de production par le biais d’un programme, en faisant par exemple appel à des conteneurs, permet de modéliser au plus tôt l’état final du processus, ce qui réduit les erreurs.

Tous les aspects du développement et de la livraison implémentés dans le code peuvent être validés à l’aide d’outils utilisant des contrôles syntaxiques ou à une logique de niveau supérieur. Enfin, tous les changements étant capturés et versionnés, quand une erreur est identifiée en aval dans le processus de livraison, les équipes sont en mesure d’effectuer une restauration immédiate vers une version sûre connue, de diagnostiquer l’erreur et de la corriger.

Avertissements et attraits futurs

La transition d’une approche code-as-code à une approche everything-as-code sera bien sûr plus facile pour certaines entreprises et plus complexe pour d’autres, certaines considérations devant être prises en compte. Une entreprise qui adopte une approche de type everything-as-code, par exemple, aura tendance à évoluer vers une culture plus collaborative, un peu comme une transformation DevOps. Le fait de sortir les configurations et les processus hors des interfaces utilisateur et de les exposer sous forme de code partagé et versionné augmente la transparence. Les entreprises agiles connaissent peut-être déjà cette transparence et cette culture, mais, pour des entreprises logicielles plus traditionnelles, le changement initial peut s’avérer plus perturbant.

Les entreprises doivent aussi être conscientes du fait que coder n’est pas à la portée de tous. Les interfaces utilisateur ont été développées dans le but de permettre aux utilisateurs de réaliser plus facilement des tâches sans devoir éditer de fichiers ni exécuter d’outils dans la ligne de commande. Certaines entreprises mettront plus de temps à apprendre à passer d’interfaces guidant les utilisateurs pas à pas à l’implémentation de ces dernières sous forme de code. Heureusement, cet obstacle potentiel a été identifié dès les premières phases du mouvement everything-as-code ; tout a donc été mis en œuvre pour fournir des solutions et des technologies facilitant la transition.

Dans cette même optique visant à rendre les technologies plus accessibles pour les utilisateurs quel que soit leur niveau de compétence, l’espace Jenkins s’est doté du projet Blue Ocean, qui permet aux équipes de créer visuellement une représentation basée sur du code de leur pipeline de livraison continue, sans code détaillé. L’expérience utilisateur allie à la fois conseils en définition de pipelines de livraison continue et avantages de l’approche everything-as-code. De même, le nouveau Declarative Pipeline permet aux équipes de définir le mode de fonctionnement de leurs pipelines à l’aide de fichiers de configuration plutôt que de scripts. Il s’agit d’indiquer les actions à accomplir dans un fichier texte plat, puis d’utiliser des outils qui interprètent les déclarations y figurant, les convertissent en opérations plus complexes, puis exécutent ces dernières.

Figure 1 : Exemple d’une visualisation Jenkins Pipeline via l’interface utilisateur Blue Ocean. De tels outils permettent aux utilisateurs de comprendre ce qu’il se passe, quel que soit leur niveau de compétence, sans devoir chercher dans des centaines ou des milliers de lignes de code.

Dans les mois et années à venir, il est fort probable qu’une telle approche hybride se généralise, car elle combine les avantages de deux environnements. En effet, les divers composants du développement et de la livraison de logiciels seront, au final, représentés sous forme de code, mais les interfaces utilisateur offriront un point d’entrée accessible pour le créer. L’approche everything-as-code sera ainsi intégrée plus aisément, et l’entreprise bénéficiera déjà de ses avantages, à savoir une transparence et une automatisation accrues, réduisant ainsi les erreurs et accélérant les livraisons.

 

[1] https://www.rfc-editor.org/info/rfc7426

__________
Brian Dawson est DevOps Evangelist de CloudBees