Quand on m’a présenté les principes du DevOps il y a quelques années, j’ai vraiment été enthousiasmé par les idées véhiculées par cette nouvelle mouvance. Une manière de travailler permettant une meilleure fluidité et moins de perte d'énergie pour la livraison des applications ne peut qu’apporter un meilleur service.

De manière consciemment naïve, je voyais déjà la fin des échanges stériles formalisés par des documents inadaptés et la destruction du mur entre des équipes en charge, au final, de produire ensemble un même résultat.

Les années ont passé et DevOps semble être le nouvel agile. Difficile de faire une conférence sans en entendre parler. Tout le monde veut s’y mettre ou annonce en faire au quotidien. Cependant, est-ce que, comme pour l'agilité, nous n’allons vers une transgression des idées de base pour, au final, "adapter" DevOps à ce que l’on a toujours plus ou moins fait ?

Je vais donner ici ma vision de dev sur l’avancée de cette mouvance au combien essentielle à l’état actuel de nos métiers.

Ce que j’attends du DevOps

Je suis un dev, je veux pouvoir livrer en production les features dès qu’elles sont terminées. Je veux pouvoir faire ça de manière sereine et avec un coût réduit à son minimum.

Pour être serein, j’ai besoin :

• D’être certain de la reproductibilité de tous les éléments nécessaires à une livraison ;
• De pouvoir exécuter simplement toutes les typologies de tests dont j’ai besoin pour valider le fonctionnement de la solution ;
• Que les tests soient exécutés sur des environnements en tous points identiques à la production ;
• De feedbacks adaptés sur les étapes de construction et de validation de la solution (même après la mise en production) ;
• De mécaniques permettant les livraisons sans arrêt de service ;
• De pouvoir revenir simplement sur une modification qui entraînerait un problème ;
• De pouvoir faire tout cela de manière autonome au quotidien.

La promesse du DevOps était de faire travailler les dev et les ops au sein des mêmes équipes pluridisciplinaires. L’idée était que chaque "camp" puisse profiter des outils et expériences de "l’autre". Le but était aussi de trouver un juste milieu entre les devs et leur "si ça fonctionne c’est que ça ne fait pas assez de choses" et les ops et leur "tant que ça marche on ne touche à rien".

J’attends surtout du DevOps de ne plus perdre de temps et d'énergie dans des querelles de clocher et d’utiliser ces ressources pour aller vers du Continuous Delivery.

Ce que j’entends sur le DevOps

Aujourd’hui tout le monde fait du DevOps, en tout cas dans le discours. Cependant, en discutant avec les personnes c’est souvent : "On (les ops) a un Jenkins à nous et on fait tourner nos Terraform et Ansible dessus. On a donné des accès à certains devs qui peuvent lancer les déploiements en lançant un Job".

On parle bien ici d’équipe distinctes, les ops ne travaillent pas dans les mêmes équipes que les devs, ne dépendent pas des mêmes directions et donc, personne n’a les mêmes objectifs et contraintes.

Certes, les choses ont bien évolué ces dernières années, on trouve de plus en plus d’Infrastructure as Code et de moins en moins de personnes qui installent manuellement des solutions sur des machines configurées manuellement. Cependant, c’est là la partie "facile" du changement, celle qui ne demande pas vraiment un changement de mentalité.

Cette manière de travailler n’est "qu’une" automatisation du process de chaque côté du mur séparant ces équipes. Le catapultage des livrables dans les deux sens reste douloureux mais permet de ne pas prendre de responsabilités en cas de problèmes.

Comment je vois les choses

Un fonctionnement qui me parait vraiment sain est celui de GitHub, tout est automatisé à l'extrême (c’est Hubot qui se charge de l’orchestration), les tests sont réalisés en production avant la fusion sur master (avec du vrai trafic). Cependant, ce fonctionnement n’est possible que dans les structures avec d’importants moyens et construites avec une culture tech.

Dans les structures plus modestes ou n’ayant pas encore une culture tech il est possible de mettre en place des fonctionnements tout à fait sains et rassurants dès lors que cette transformation est souhaitée. Quelques points essentiels :

• Un produit doit être géré par une seule équipe. Toutes les personnes nécessaires (de l’idée au suivi de production) doivent travailler dans la même équipe avec la même chaîne managériale (si elle est nécessaire, se passer de chaîne managériale pouvant aussi être une très bonne solution).
• Il ne doit y avoir qu’une seule base de code contenant les fonctionnalités et ce qui est nécessaire pour livrer ces fonctionnalités. Comme cela a toujours été fait en dev, les ops doivent mettre en place des "librairies" de déploiement (en utilisant les modules Terraform et Ansible Galaxy par exemple). Ces librairies faciliteront la maintenance du parc (mises à jour des composants ou des pratiques).
• Il faut tout coder, que ce soit les opérations sur les environnements ou les tests. Il est essentiel que tout soit totalement automatisé (et que ce code soit correctement versionné).
• Les outils doivent être utilisables simplement, dès que c’est possible leur utilisation doit être transparente.

Ces quelques points permettront d’aller rapidement vers du déploiement automatisé (sans forcément parler de déploiement continu).

Les prérequis

On pense rapidement à l’outillage nécessaire pour pouvoir faire du DevOps, certes, il faut :

• Un gestionnaire de version ;
• Une mécanique de construction de livrables applicatifs ;
• Une mécanique de construction des environnements ;
• Une mécanique d'orchestration des tests et déploiements.

Cependant, c’est la partie facile de cette mise en place (surtout avec des outils comme GitLab).

Un autre point essentiel pour permettre la livraison automatisée de nos solutions est la confiance qu’on leur apporte. Pour que des livraisons sans multiplication des contrôles humains à chaque étape soient acceptées il faut que la qualité de ces solutions soit irréprochable. Sur ce point les pratiques du Software Craftsmanship sont clairement la clé pour la partie dev mais aussi pour la partie ops.

Le dernier prérequis essentiel est la culture de la structure qui doit accepter ce type de déploiement et la constitution d’équipes autonomes sur les produits. Il est extrêmement compliqué (au mieux) de mettre en place des équipes pluridisciplinaires dans les structures qui n’ont pas cette culture. C’est, je pense, la raison pour laquelle on voit aujourd’hui cette adaptation du DevOps. Cependant, changer les mentalités à tous les niveaux pour mettre en place ces équipes est la seule manière pour livrer efficacement des solutions de plus en plus complexes techniquement.

Qu’est-ce qu’on peut faire ?

Les actions possibles dépendent de la latitude que l’on a. Cependant, à tous les niveaux il est possible de changer les choses.

La première chose à faire est de comprendre et de se convaincre de la nécessité de ces pratiques, quelques livres sur ce sujet :

• The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win : Un livre très facile à lire puisqu’écrit comme un roman qui raconte la transformation d’une entreprise vers du DevOps. Au travers des étapes rythmées par des crises de production les protagonistes vont comprendre et mettre en place certains des grands principes du DevOps. Même si l’histoire n’est pas tirée d’un seul cas réel elle est bien trop criante de vérité pour être tout à fait inventée :).
• Building Microservices : Dans cet excellent livre sur la construction de microservices, Sam Newman nous explique aussi l’importance de l’automatisation de toutes les opérations.
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation : Ce livre date de 2010, les outils qui y sont présentés ne sont plus tous au goût du jour. Cependant les méthodes à suivre pour arriver vers ce fonctionnement restent tout à fait valables.

Il est aussi tout à fait possible d’aller parler aux personnes dans les conférences ou événements locaux pour comprendre l’importance de ces pratiques au quotidien.

Une fois cette première étape passée il faut simplement mettre en place des choses petit à petit. Si vos déploiements ne sont pas codés : codez-les. Si le code "ops" a un cycle de vie différent, faites des "librairies" et ne faites qu’une base de code. Si vos équipes sont clairement séparées essayez de les rapprocher (cela peut commencer simplement par prendre des pauses en commun).

Cette transformation est tout sauf simple mais elle est le meilleur moyen de passer son énergie et son temps à construire des solutions et de la valeur plutôt qu'à se renvoyer la balle au moindre problème.