Rapide rappel sur les fondements et les avantages d’une culture DevOps.
DevOps est la contraction des mots “Developpers” et “Ops”, mais vous le savez probablement déjà. La culture DevOps vise à casser la séparation entre les développeurs qui produisent de nouvelles fonctionnalités, et les Ops qui ont pour objectif la fiabilité du site. Des intérêts a priori antagonistes comme l’a illustré Andrew Shafer en 2008 lors d’une conférence avec un schéma devenu mondialement connu : “The wall of confusion”.
L’objectif du DevOps est de casser cette barrière et le fonctionnement en silo. Cette collaboration passe par de nombreux moyens que nous allons aborder dans la suite de cet article, mais l’objectif est toujours le même : faire collaborer développeurs et Ops pour atteindre des objectifs communs.
L’objectif de cette collaboration, au final, est de mettre en place de nouvelles features plus rapidement, sans altérer la qualité. C’est ce qu’on appelle le déploiement continu. Cette idée est illustrée par un concept essentiel du DevOps, la “feedback loop” :
Impossible donc de mettre en place une démarche DevOps si l’on n'est pas à l’écoute de l’utilisateur, et impliqué pour améliorer en continu les produits mis à sa disposition.
C’est l’éternelle question, à quel moment le domaine du développeur s’arrête-t-il pour laisser place aux missions de l’Ops ? Quelle que soit l’organisation mise en place, quels que soient les principes de collaboration, nous parlons de deux métiers différents. De deux stacks techniques différentes. Voici quelques moments où une distinction floue entre les 2 postes va vous jouer des tours :
D’un point de vue technique, la question se pose aussi. Exemple : qui gère les variables d’environnement et comment faire pour qu’elles soient sécurisées mais n’impactent pas le flux de développement ?
Toutes ces questions doivent être tranchées. Chacun doit connaître son rôle, sa responsabilité. Les règles du jeu changeront au cours du temps, mais elles doivent rester claires et connues (acceptées) de tout le monde.
La conférence de Shafter en 2008 marque le début du DevOps.
En 2009, la première conférence “DevOpsday” se tient en Belgique, à Ghent. Créée par Patrick Debois, consultant en organisation agile, elle se développe ensuite à l’international et continue à être un des piliers du monde du DevOps avec plus de 30 conférences programmées pour 2019.
En 2012, le premier rapport “State of DevOps” est produit par Alanna Brown de Puppet. Quelques mois plus tard, en 2013, “The Phoenix project” sort à son tour. Cette nouvelle raconte l’histoire d’un manager IT impliqué dans une situation qui semble désespérée.
Une des clés de sa réussite sera l’application des concepts lean et DevOps. Cet ouvrage va largement contribuer à la diffusion de la culture DevOps.
En 2019, selon IDC, la démarche DevOps est une tendance lourde de l’organisation IT mais le DevOps ne concerne encore que 20% des projets applicatifs. Selon les estimations, ce chiffre passera en 2021 à 35% voire 40%.
Une démarche DevOps vous fera gagner du temps. Beaucoup de temps.
Petit exemple :
Sur le site d’e-commerce de l’un de nos prospects, certains produits étaient affichés en double. Il a fallu 19 jours-homme de travail aux équipes internes pour en trouver la cause : un cron s’exécutait à deux endroits différents mais touchait à la même base de données. Les Ops avaient l’info “où le cron tourne” et les développeurs l’info “que fait le cron”.
À partir du moment où les 2 équipes ont commencé à travailler sur ce bug dans la même pièce, il a été résolu en 2 heures...
D’une manière générale, le DevOps vous permettra :
Selon le rapport State of DevOps de 2016, les entreprises qui ont mis en place une organisation DevOps affichent une fréquence de déploiements 200 fois plus élevée et des délais de production 2 555 fois plus courts (entre la volonté de déployer et la mise en production).
Autant que la collaboration de toutes les parties, l’automatisation des processus va permettre de réduire les risques de défaillance. Un processus d’amélioration continue, clé en DevOps, permettra ainsi de rendre les déploiements de plus en plus fiables et fluides.
La démarche d’automatisation sous-tendue par le DevOps doit permettre de mieux réagir aux inévitables incidents. La bonne communication entre les développeurs et les Ops (comme dans l’exemple de notre client) facilitera aussi cette réaction.
Avoir des cycles de déploiement courts et mettre régulièrement en production de nouvelles features va mécaniquement améliorer la satisfaction de vos clients et votre adéquation au marché. Voir leurs retours pris en compte et le produit s’améliorer les valorise, règle leurs problèmes, et fait la différence avec la concurrence.
Vos équipes de développement et vos Ops ont-ils un temps dédié à collaborer ? Ou est-ce une charge supplémentaire qui vient s’ajouter à la pression de leurs sprints ?
Quelques exemples de manières dont on peut dédier du temps à cette collaboration, et faciliter l’implémentation d’une culture DevOps dans l’entreprise :
La conception d’une nouvelle feature ou de l’ajout d’une nouvelle technologie doit faire l’objet d’une concertation en amont entre développeurs et Ops. Pour le faire proprement, ce workshop doit être pris en compte dans les sprints des 2 équipes sous la forme d’un ticket estimé. Sinon vous avez toutes les chances que ce soit fait à la va-vite entre 2 features, et vous le paierez après.
L’architecture conçue par vos Ops est-elle correctement utilisée par vos développeurs ? Le processus est-il simple pour eux, ou manquent-ils de connaissances techniques ? Surtout si le turnover est important dans vos équipes techniques, prévoir un temps de formation hebdomadaire sur les outils DevOps mis en place peut régler beaucoup de problèmes.
Vous allez me dire “qu’est-ce qu’un test utilisateur vient faire dans le monde du DevOps ?”. Vous avez tort. Cette vision peut agacer, mais vos développeurs sont les utilisateurs des outils mis en place par vos Ops, autant vérifier que ces outils sont pratiques et répondent à leurs besoins.
Une autre manière de permettre à vos Ops et à vos développeurs de travailler ensemble est de leur fixer des objectifs communs. Cela crée un cercle vertueux où les réussites des uns sont les réussites des autres, et où tout le monde a intérêt à collaborer. Il faut alors fixer des objectifs avec 2 mesures, une venant des objectifs “naturels” des développeurs, et l’une venant du monde des Ops.
Si vous fixez un objectif “brandé” Ops, du type “la plateforme est disponible à 99,9%”, vous pouvez être certain que vos Ops vont partir en croisade contre les développeurs qui viendront mettre cet objectif en péril avec leur volonté de mettre des features en production.
Peu importe à quel point vous essayez d’onboarder vos Ops sur la roadmap de développement, vous avez créé une culture où l’infrastructure domine l’application. Fixez un objectif de delivery, et vous obtiendrez le processus inverse avec une obsession de la livraison chez les développeurs qui rendra la vie de vos Ops infernale.
Exemple d’objectif : 1 mise en production par semaine avec 0 downtime de l’application
À vous de gérer la reconnaissance et la célébration que vous mettez en place pour motiver vos troupes, on entre alors plus dans le domaine du management. Mais gardez en tête que vous posez ainsi les bases d’une collaboration DevOps saine et efficace.
C’est un peu iconoclaste, mais une équipe Ops est une équipe support, transverse, qui a donc ses propres utilisateurs. En interne, pour une bonne partie de ses tâches, une équipe Ops a des “clients”. Il faut développer dans votre équipe infrastructure une culture du service client :
Cela nécessite une vraie dose d’humilité, et c’est un changement d’état d’esprit qui sera très difficile à mettre en place dans bon nombre d’entreprises où la culture DevOps n’est pas encore bien implémentée. Il ne faut pas non plus tomber dans un mode de communication dictatorial et malsain où les développeurs se servent de cette étiquette de “client” pour dominer l’équipe Ops.
Mais développer une culture du service et de la satisfaction client dans votre équipe Ops vous permettra d’améliorer la qualité, la vitesse de vos livraisons, et la communication entre vos Ops et vos développeurs.
Nous vous donnions dans un précédent article les différentes étapes afin d’aligner vos Dev et vos Ops, afin d’avoir une culture DevOps parfaitement implémentée au sein de votre entreprise.
Agile : Le DevOps est souvent vu comme une manière d’appliquer l’agilité au monde de la production. Les méthodes agiles appliquées au développement permettent de réduire la distance entre les besoins utilisateurs et l’équipe de développement. Le DevOps peut être considéré comme venant en complément, permettant à l’équipe de développement de mettre rapidement en production les nouvelles fonctionnalités.
Nous avons rédigé un précédent article traitant un peu plus en détail de la culture DevOps et surtout de comment l’adapter à une méthodologie Agile.
ArchOps : Extension du DevOps en partant de l’architecture logicielle et non du code pour les opérations de déploiement.
DataOps : Application du déploiement continu et du DevOps à l’analyse de données. DataOps cherche à intégrer le data engineering, la data intégration, la sécurité des données et la privatisation des données avec les opérations (Ops).
Site Reliability Engineer (SRE) : le Site Reliability Engineering est une approche développée par Google depuis 2003, dans le but de déployer de nouvelles fonctionnalités en continu tout en maintenant un haut niveau de qualité et de disponibilité de l’infrastructure. DevOps et SRE reprennent des problématiques largement similaires.
WinOps : WinOps est le terme utilisé pour les pratiques DevOps centrées autour de l’environnement Windows
En 2019, la démarche DevOps était intégrée dans 20% des projets applicatifs en France. En 2021 les prévisions montent à 40% de projets reprenant cette organisation. Il y a encore bien des choses à dire sur la culture DevOps, mais ce rapide panorama vous permettra de poser les premières bases de cette collaboration dans votre entreprise. Si vous souhaitez plus d’informations, n’hésitez pas à parcourir nos autres articles ou à nous poser des questions sur le DevOps !