Quelles opportunités l’Everything as Code permet-il aux équipes DevOps ?

Yann SCHEPENS et Nicolas GIRAUD, vous comptabilisez à vous deux plus de 25 ans d’expérience dans le développement d’applications, dont 10 ans en tant qu’architectes et experts DevOps chez onepoint. Vous accompagnez quotidiennement de grandes entités publiques et privées dans l’organisation de leurs développements et de leurs usines logicielles. Faisons ensemble un état des lieux autour de DevOps et profitons de cet échange pour envisager comment les nouvelles approches du développement exploitant l’Everything as Code vont impacter les organisations.

Pour commencer, faisons un point sur les tendances DevOps dans le cadre de la transformation numérique des entreprises. Vous êtes sur le terrain, qu’observez-vous ?

Nicolas : On observe un réel mouvement de fond autour de la culture DevOps et de l’agilité en général. Les entreprises commencent à parler de leurs réalisations, de leurs succès et parfois de leurs échecs. Au même titre que la transformation numérique, DevOps impacte les pratiques, les applications et les usages, ainsi que la dimension organisationnelle. Les secteurs privés et publics sont indifféremment concernés.

Yann : Les sociétés qui se sont saisies du sujet les premières sont aujourd’hui relativement avancées. Elles ont acquis la culture DevOps, leurs équipes sont aguerries. Elles disposent de retours d’expérience et de bonnes pratiques. L’organisation des entreprises peut toutefois être un frein. C’est par exemple le cas des entreprises organisées en silos, alors que des entreprises plus jeunes ont plutôt la culture de l’échange.

Nicolas : L’adoption de la philosophie DevOps est plus simple pour une entreprise d’une centaine de collaborateurs que pour une société disposant de nombreuses filiales. Quoi qu’il en soit, les chantiers de transformation numériques ont accéléré de manière importante la mise en œuvre des approches agiles et la mise en place des principes DevOps.

Yann : Effectivement, DevOps est une des clés de l’agilité dans les entreprises. Elle pousse à aligner les métiers par rapport aux méthodes agiles. La culture DevOps s’inscrit bien au-delà du développement de logiciels. Il met toutes les parties prenantes autour de la table, ce qui contribue à faire évoluer la communication dans les entreprises.

Figure 1 – Etapes d’un pipeline CI/CD

De quelle manière les entreprises appréhendent-elles la mise en œuvre de DevOps actuellement, quelles sont leurs options ?

Yann : Aborder DevOps seul peut s’avérer long et complexe pour une entreprise, même si le sujet ne manque pas de littérature. L’entreprise va être confrontée à de nombreuses problématiques jusqu’alors inconnues, ce qui peut être fastidieux, voire source d’échec.

Plus généralement les entreprises prennent conscience de la complexité de la tâche et font désormais appel à des équipes expérimentées pour les accompagner. Ces dernières les aident dans la résolution des problèmes, mais aussi pour mettre en place de nouveaux processus destinés à fluidifier les échanges.

Chez onepoint nous intervenons, Nicolas et moi-même, en tant qu’experts DevOps dans des équipes déjà en place.

D’une manière générale, lors des mises en œuvre de DevOps, quelles sont les principales difficultés que vous rencontrez ?

Yann : De nombreuses initiatives DevOps se développent sur la base d’expertises techniques considérées comme transverses. Ces dernières ont pour objectif de diffuser la culture DevOps dans les différents services de l’entreprise. Toutefois, leur expertise technique seule ne suffit pas pour porter les changements attendus et embarquer l’ensemble des parties prenantes.

Dans ce cas quelles réponses pouvez-vous y apporter ?

Onepoint intervient pour produire ce changement avec un ensemble d’actions ciblées telles que l’acculturation, l’analyse de processus existants, la mise en place de la communication entre les équipes, la sélection des outils et leur mise en œuvre, la formation.

Qu’il s’agisse d’intervenir dans des équipes existantes ou non, toute la subtilité réside dans notre capacité à apporter le changement sur la base de solides connaissances techniques. Ces expertises restent essentielles au développement des solutions logicielles et à la mise en place des chaines CI/CD attendues par les entreprises.

A contrario, si le changement est impulsé par le management, il faudra réussir à embarquer les équipes techniques de manière qu’elles s’approprient aussi le sujet.

La culture de l’entreprise peut également être un frein. La mise en œuvre de DevOps reste spécifique à chaque entreprise, sa réussite en est fortement dépendante. Ainsi, en faisant appel à des experts externes, l’entreprise bénéficie de nombreux retours d’expérience, de bonnes pratiques et d’outils qui pourront être adaptés à sa culture et à son organisation.

Une des clés de la réussite de la mise en œuvre de DevOps réside également dans le choix des outils utilisés. Pouvez-vous nous donner quelques détails sur les solutions à privilégier ?

Nicolas : Il y existe une telle quantité d’outils, que cela peut être problématique ! Le tableau périodique des outils DevOps donne un bel aperçu des solutions disponibles. C’est une ressource de référence pour identifier les meilleurs outils tout au long du cycle de vie des logiciels. Il a été mis au point avec la contribution de milliers d’intervenants DevOps, inspiré du tableau périodique de Mendeleïev, il permet d’identifier les outils nécessaires au développement de vos pipelines.

L’intérêt de ces outils réside dans leur capacité à automatiser de nouvelles tâches ou à les systématiser. Ils sont majoritairement configurables par description, ou encore par codage. L’étendue des sujets traités est vaste : documentation, infrastructures (cloud providers ou non), qualité du code…

Figure 2 – Tableau périodique des outils DevOps par digital.ai

Yann : Les processus d’intégration sont généralement déjà en place dans les entreprises, c’est ce que l’on appelle l’intégration continue (CI pour continuous integration), ainsi que les processus de déploiement et mise à disposition des applications, la livraison continue (CD pour continuous delivery). D’un point de vue technique, c’est le cœur de DevOps. Cependant, pour des raisons diverses, les équipes CI et CD sont encore souvent séparées.

Nicolas : La notion de pipeline est apparue il y a une dizaine d’années. Elle a débuté avec l’écriture de scripts pour automatiser des tâches comme l’installation du projet du côté des équipes de développement. Ces scripts étaient utilisés ou déployés par les Ops. Par la suite, de nouveaux outils ont fait leur apparition pour automatiser le déploiement et la diffusion des applications. La notion de pipeline a alors pris tout son sens lorsque les développeurs et les administrateurs système ont commencé à travailler sur un processus commun et à enchainer des actions. Ainsi, les différents systèmes et outils d’automatisation permettent aujourd’hui d’implémenter l’entièreté du processus DevOps.

Le développement des nouvelles applications est majoritairement réalisé avec des architectures distribuées en microservices. Ces applications sont complexes et destinées à supporter des mises à jour très fréquentes. Allons-nous faire face à un nouveau casse-tête pour la mise au point des pipelines ?

Nicolas : Effectivement, la physionomie des applications a totalement changé. Les applications sont désormais découpées en microservices. Les frontaux sont riches, il en est de même pour les backends. Ces applications utilisent de multiples APIs. La complexité de construction des livrables a littéralement explosée ces dernières années.

Yann : Les tests suivent également cette tendance. De nombreux nouveaux tests, jusqu’alors inexistants, sont aujourd’hui indispensables, comme entre autres, l’accessibilité et la sécurité. De la même manière, l’utilisation de librairies externes, développées par des tiers, se généralise. L’automatisation des pipelines devient par conséquent incontournable, tant il parait impossible d’effectuer manuellement ces tâches. Cette tendance va continuer de s’accentuer.

Yann SCHEPENS et Nicolas GIRAUD, architectes et experts DevOps chez onepoint

Dans ces conditions, l’automatisation des pipelines de bout en bout parait incontournable. L’approche Everything as Code, où justement, tout devient programmable jusqu’à l’infrastructure, présente-t-elle des opportunités pour le développement des pipelines ?

Yann : Un seul et unique script, de bout en bout, c’est effectivement ce vers quoi nous nous dirigeons. C’est une tendance forte qui consiste à regrouper le code applicatif et celui des utilitaires au même endroit. Cela est rendu possible depuis que les infrastructures sont également scriptables (Infrastructures as Code).

Et quels en sont les bénéfices ?

Les bénéfices sont nombreux. L’ensemble du code étant regroupé en un endroit, toute la chaîne est commune, du code jusqu’à la mise en service de l’application. Cela apporte un gain très important en matière de visibilité. Toutes les équipes ont accès au code. Elles disposent d’une vision très précise des actions et des enchainements. Il n’y a plus d’effet boîte noire.

Autre bénéfice, la communication entre les équipes s’en trouve grandement améliorée. Cela entraine les équipes à travailler ensemble et à adresser collectivement les mêmes problématiques. On observe les mêmes bénéfices que pour le développement d’applications. Le pipeline devient reproductible, on peut le jouer, revenir en arrière, le tester, le rejouer plusieurs fois, tout simplement. Finalement toute la chaine de mise à disposition de l’application s’en trouve simplifiée.

Nicolas : Le fait de pouvoir reproduire intégralement le comportement d’une application jusqu’à son déploiement et à son infrastructure est une avancée majeure. Nous sommes maintenant sur un socle full code avec une base reproductible, reconstructible et répétable. Cela constitue une évolution essentielle.

Quels sont les impacts d’une mise en œuvre Everything as Code pour le développement et la maintenance des pipelines CI/CD ?

Nicolas : Le recours à l’EaC rend aussi les choses plus complexes, car on retrouve en un même endroit des sujets très différents qui demandent des compétences à chaque fois spécifiques. Donc d’un côté nous obtenons de véritables bénéfices opérationnels avec la capacité de produire et de reproduire, de l’autre, il est nécessaire de maîtriser un périmètre plus vaste.

Yann : De nouveaux risques sont introduits et demandent de l’attention. Les techniques de développement sont acquises du côté CI, ce n’est pas toujours le cas côté CD. Ce qui est normal car ce n’est pas le cœur de métier des Ops. Cela demande l’acquisition de nouvelles compétences de part et d’autre.

De plus, l’approche Everything as Code peut mener à une recherche d’automatisation à outrance, au risque de conduire à une perte de maitrise des pipelines. Attention, c’est tentant !

Nicolas : Autre point de vigilance, l’appel à des intervenants externes pour le développement des pipelines en EaC est à éviter sous peine d’être dans l’incapacité à les maintenir. Nous privilégions toujours un accompagnement qui associe toutes les parties prenantes, gage d’autonomie pour vos pipelines.

Comment l’EaC doit-il être abordé ? Plus précisément, quelles sont les compétences techniques nécessaires et quelle organisation privilégier pour réussir sa mise en œuvre ?

Nicolas : Il s’agit de compétences en développement, mais pas seulement. Chaque étape du pipeline nécessite des compétences très spécifiques. Les connaissances détenues par les Ops et ainsi que la connaissance de leurs contraintes sont indispensables pour aborder l’EaC sereinement.

Dans l’approche EaC, les équipes CI et CD tendent à être indifférenciées. Cela ne veut pas dire pour autant que les Ops vont se mettre à développer du fonctionnel et que les développeurs vont devoir administrer l’infrastructure. En revanche, les équipes sont amenées à s’intéresser à leurs activités respectives, à mieux comprendre les attentes et contraintes de chacun. De cette manière, les Ops apportent de nouvelles connaissances aux développeurs sur des sujets tels que la documentation, la performance, les aspects réseau ou encore la sécurité. Ce sont des notions auxquelles les développeurs ne sont pas forcément sensibles.

Yann : Prenons quelques exemples. Les Ops ont besoin de comprendre ce qui se passe en cas d’erreur. Pour cela, ils doivent disposer d’informations pour diagnostiquer et prévoir des solutions de reprise. La mise en place de logs côté développement facilitera grandement leurs interventions. Toutefois, les développeurs ne réalisent pas toujours l’importance de disposer de logs de qualité et bien organisés.

La mise à disposition de métriques sur la performance et les ressources consommées par les applications par les Ops peut aider les développeurs dans leur démarche d’optimisation des applications, pour les rendre plus performantes au bénéfice des utilisateurs.

Et comment les parties prenantes réagissent-elles ?

Nicolas : Les confrontations entre CI et CD ne manquent pas. Elles décloisonnent les visions de chacun et rapprochent les équipes. Elles impactent positivement la conception et le développement des applications. Les compétences des uns et des autres deviennent nécessaires.

Au risque de remettre l’éternel débat entre les Dev et les Ops sur la table, les approches EaC, et DevOps de manière plus large, auraient plutôt l’avantage de les remettre autour. Cela déclenche la mise en place d’objectifs communs entre CI et CD pour le bénéfice des utilisateurs.

Alors comment faut-il s’y prendre, quels sont vos conseils pour réussir le passage à l’EaC ?

Nicolas : Pour commencer, il s’agit d’arrêter de penser outils. Il faut remettre à plat tous les processus existants et les challenger. C’est que nous faisons au cours de sessions d’event storming. Cela permet, de manière itérative, de remettre à plat les processus, d’identifier les contraintes de chacun, de définir les objectifs, d’évaluer la pertinence de tout automatiser ou non, et enfin, de sélectionner les outils. Intégré à une démarche agile, cela nous permet d’améliorer les processus et d’aborder la complexité progressivement.

Figure 3 – Etapes de définition d’un pipeline

Yann : Avec l’EaC, nous sommes sur du code. Nous disposons donc de nombreux patterns et principes éprouvés. Même s’ils ne sont pas tous applicables, certains d’entre eux demeurent adaptés. Par exemple, l’inversion de dépendances permet de mettre en place des points de débrayage dans l’exécution des pipelines. C’est un élément essentiel pour garder le contrôle sur toute la chaine d’automatisation. Le principe de factorisation est également important pour simplifier le code par réutilisation.

Nicolas : La longue expérience du développement logiciel dont nous disposons nous permet d’appréhender l’ouverture procurée par l’EaC et l’IaC. Ainsi, lorsque se posent des problèmes dans le code, il y a bien souvent des réponses déjà disponibles. Il faut donc avoir le réflexe de rechercher parmi les solutions existantes.

Comment faire pour contenir le niveau de complexité des pipelines développés en EaC ?

Yann : Il ne faut pas se leurrer, développer un pipeline de bout en bout en EaC est un projet complexe qui adresse de nombreux objectifs, contraintes et actions. Il faut à minima appliquer des principes de programmation classiques, tels qu’évoqués précédemment, pour produire un code simple et facile à maintenir.

Nicolas : La méthode des petits pas, avec de petites portions de code, semble parfaitement indiquée pour une meilleure compréhension et facilité de maintenance. Il faut à tout prix éviter de s’aventurer en dehors de standards du moment. Il existe des pratiques et des outillages standards tels que SEMVER, Gitflow, par exemple, qui adressent les problèmes rencontrés par le plus grand nombre. Il faut les privilégier.

Il est également indispensable de mettre en place des lectures à plusieurs niveaux, en procédant à un fin découpage des actions du pipeline. Cela procure une meilleure appréhension de l’ensemble du pipeline.

Nous l’avons vu, l’EaC joue un rôle central pour l’implémentation de DevOps. Cependant, le choix de l’organisation reste un élément clé pour réussir une stratégie de mise à disposition de produits et de services numériques performants et de qualité.

Nicolas : Les organisations doivent s’assouplir, c’est l’un des grands défis qu’elles rencontrent. A l’heure actuelle, nombreuses sont les entreprises où les équipes CI et CD sont séparées. Un premier objectif peut être d’améliorer la collaboration entre elles. Pour cela, l’intervention d’une équipe DevOps tierce peut être conseillée. Elle aura pour objectif d’apporter de la fluidité dans les échanges et de propager la culture DevOps.

Dans tous les cas, il reste essentiel d’adapter l’organisation DevOps à la maturité acquise par l’entreprise. Cela permet de définir une feuille route et des objectifs réalistes pour atteindre d’autres stades. Cette approche peut pareillement être déclinée pour la conception des pipelines et la mise en œuvre des outillages.

Figure 4 – Une équipe DevOps pour fluidifier les échanges

Yann : Dans le cadre d’une organisation fortement cloisonnée, où la communication entre les équipes n’est pas bien établie, faire le choix d’un pipeline de bout en bout à tout prix, n’est peut-être pas la meilleure solution. Parfois, conserver une séparation en les équipes CI et CD peut s’avérer plus adaptée, même si cela apparait être à contre-courant.

Tout comme essayer d’imposer un process qui ne correspond pas à la culture des équipes est cause perdue. Dans ce contexte, une équipe DevOps transitoire peut trouver tout son sens.

Propos recueillis par Laurent ROSSAERT