Bien des définitions du DevOps cohabitent, certaines étant même contradictoires et une lecture trop rapide de ces définitions peut amener plus de confusion que de succès. Mais surtout, au-delà de potentiels méthodes et outils, il s’agit avant tout d’un état d’esprit, ce qui s’avère souvent plus difficile à modéliser et concrétiser.

Tout comme la musique se base sur des notes pour obtenir des symphonies adaptées au style de chacun, nous donnerons les éléments principaux qui font partie de la philosophie au travers de ce papier. Nous verrons que les notes seules ne font pas une musique et que c’est ce lien qui permet la création d’une mélodie, voire d’une symphonie, pérenne dans le temps.

Le DevOps c’est quoi ?

C’est en 2008 que le terme Agile Infrastructure a fait son apparition et a très rapidement été repris par la communauté, ce qui était déjà en soi une révolution. Dès l’année suivante, le mouvement était né au travers des premières présentations d’une seule voie sur l’agilité au sein des développements et l’agilité de l’infrastructure avec comme leitmotiv de casser les silos et d’améliorer la flexibilité au sens large.

A une époque où le hashtag arrivait en force, #devops s’est alors imposé. Pourtant ce terme représente assez mal ce mouvement et ne met en exergue que le rapprochement voire la collaboration entre les développeurs et les opérations ou encore ce qui est en amont et en aval du livrable. Pourtant, dans un contexte agile, le livrable évolue et n’est plus le point de référence.

Le rapprochement entre les Devs et les Ops a permis de mettre en avant d’autres silos au sein même de cette seconde catégorie. En effet, bien que cela ne fasse pas toujours plaisir à tout un chacun, Ops englobe bien des choses : les bases de données, le réseau, les sauvegardes, les logs, la sécurité etc.

Mais dès lors comment être agile quand, en pratique, bien des silos existent ? Chaque élément du système se doit d’être agile, c’est un fait mais surtout il est nécessaire de faire en sorte que chacun partage « un état d’esprit DevOps » qui repose sur quelques fondements que nous allons aborder ci-dessous.

Que peut-on attendre de DevOps ?

Les objectifs de DevOps sont multiples. Nous ferons le choix de les grouper en 6 grandes catégories et qui se caractérisent par des mots clés spécifiques :

• Déploiement accéléré

déploiement en continu, automatisation, connaissance des environnements

• Robustesse

micro-services, architecture, tests réguliers

• Evolutivité

élasticité de la charge, architecture modulaire

• Cohésion des équipes

interdisciplinarité, compréhension transverse, expertise, rapport d’activités commun

• Sécurité

security by design, déploiements automatisés

• Mesurabilité

accès à l’information de production, connaissance des environnements, micro services et architecture, traçabilité complète

Nous pouvons, d’ores et déjà, remarquer que bien des mots clés se retrouvent dans différents objectifs, ce qui explique la complexité de mise en œuvre. Nous y reviendrons.

Que faire pour implémenter DevOps ?

La vraie question à se poser est : que veut dire « implémenter DevOps » ?

Sur base du manifeste Agile avec lequel DevOps partage les enjeux, il est possible de définir un manifeste DevOps en définissant un état d’esprit, des valeurs, des principes, des méthodes et des pratiques. Une approche DevOps réussie repose sur l’ensemble des éléments de la pyramide :

De nombreux livres existent sur le sujet. Nous n’abordons ici que les mots clés et des pistes de réflexion.

Un état d’esprit …

Un mouvement repose tant sur les aspects techniques que sur les personnes et ne peut s’effectuer que si chacun a la volonté d’aller dans une direction commune, en collaborant et en acceptant le changement en tant que tel, ayant pour but de permettre un gain tant pour le collaborateur que l’utilisateur final du produit.

… des valeurs …

Sans pour autant négliger la valeur des éléments en second, il s’agit de garder certaines valeurs en mémoire lors de la mise en œuvre de DevOps :

• Les individus et leurs interactions, plus que les processus et les outils
• Des logiciels opérationnels, plus qu’une documentation exhaustive
• La collaboration avec les clients, plus que la négociation contractuelle
• L’adaptation au changement, plus que le suivi d’un plan

… des principes…

Il existe de nombreuses variantes de cette liste. De ce fait, le choix s’est porté sur celle de la DevOps Agile Skills Association[1] qui est plutôt représentative de l’état d’esprit :

• Le client est au centre de l’activité
• La finalité est la cible
• La co-création et la responsabilité sont partagées entre tous
• Les silos font partie du passé et une équipe produit représente le présent
• L’amélioration fait partie du quotidien, l’organisation doit la permettre
• L’automatisation doit être favorisée dès que cela est possible

… des méthodes …

Toutes les variantes des méthodes agiles peuvent être utilisées dans ce contexte et se doivent d’être choisies en fonction des objectifs et de la maturité de l’organisation.

…et finalement des pratiques

Les pratiques sont multiples avec notamment l’Infrastructure as Code qui permet de stocker et de gérer l’ensemble des configurations mais aussi l’automatisation des déploiements, tant des systèmes hôtes que des applicatifs. Cette automatisation peut s’étendre aux tests qui, également, peuvent être effectués en continu. La virtualisation et le cloud computing complèteront ces pratiques afin d’à nouveau améliorer les déploiements accélérés, la robustesse, l’évolutivité. Pour répondre aux objectifs de mesurabilité, de robustesse et d’évolutivité, le monitoring doit faire le lien entre applications et les systèmes hôtes.

Les architectures jouent un rôle prédominant dans la mise en œuvre de l’ensemble des pratiques citées précédemment. Ainsi les micro-services et la containerisation sont autant de pratiques facilitant la mise en œuvre d’architectures évolutives et robustes, permettant notamment de mettre le focus sur un composant donné.

Enfin, il s’agit ainsi de mettre en place une culture de communication et de collaboration dans laquelle tout un chacun peut se permettre l’erreur afin d’en tirer avantage. Pour leur gestion au quotidien, les équipes produit (et non « les équipes opérationnelles ») se doivent de mettre en place des méthodes telles que Scrum ou encore Lean, notamment au travers d’outils comme le Kanban, nommé parfois LeanKanban ou ScrumBan.

[1] https://www.devopsagileskills.org/dasa-devops-principles/