Dans cet article d’introduction à DevOps je vous propose de revenir aux bases du mouvement DevOps : ses origines, motivations et principaux enjeux. J’aborderai les pratiques C.A.L.M.S. (Culture Automation Lean Measurement Sharing) bien connues par tous les “pratiquants” de ce mouvement.
Cet article est destiné tout d’abord à tous ceux qui veulent découvrir les pratiques DevOps et comprendre pourquoi DevOps est devenu quasiment indispensable pour tout nouveau projet agile. Les gourous de DevOps pourront également trouver quelques informations intéressantes pour rafraîchir leur mémoire.
Introduction
Définition
Il n’existe pas de définition de DevOps unique et acceptée par tout le monde. Par conséquent, il y a des dizaines de définitions différentes visant à expliquer ce mouvement.
Voici la définition fournie par Wikipedia :
« Le DevOps est un mouvement visant à l’alignement de l’ensemble des équipes du système d’information sur un objectif commun, à commencer par les équipes de Dev chargées de faire évoluer le système d’information et les Ops responsables des infrastructures. » (Wikipedia)
Cette définition, certes très brève, donne un bon aperçu permettant de comprendre de quoi il s’agit : une collaboration étroite entre les équipes des Devs et des Ops. Voici une autre définition que je trouve intéressante :
« DevOps est la pratique où les ingénieurs de développement (Dev) et d’exploitation (Ops) participent ensemble à l’intégralité du cycle de vie de services : de la conception au support de production en passant par le développement. »
Origines
L’histoire de DevOps commence en Belgique où Patrick Debois, ingénieur de développement, exerce depuis 15 ans les différents rôles suivants au sein de grandes entreprises : développeur, ingénieur réseaux, administrateur système et chef de projet. En 2007, il travaille en tant que testeur pour un grand projet de migration de datacenter. Il est amené à collaborer à la fois avec les équipes de développement et les équipes opérationnelles. Patrick est particulièrement frustré par le contraste entre les façons dont les Devs et les Ops travaillent et le conflit perpétuel entre ces deux mondes. Il est persuadé qu’il existe un moyen d’améliorer cette collaboration et de mieux s’aligner.
En 2009 Patrick assiste à la présentation « 10+ Deploys per Day: Dev and Ops Cooperation at Flickr » donnée par deux employés de Flickr – John Allspaw et Paul Hammond, lors de la conférence O’Reilly. Patrick est tellement inspiré par cette présentation qu’il décide d’organiser sa propre conférence appelée Devopsdays à Gand en Belgique en octobre 2009.
Depuis 2010 le Twitter hashtag #DevOps est la source essentielle d’information liée au mouvement.
Les Rôles
Avant de commencer notre “deep-dive” dans le monde de DevOps, rappelons-nous le rôle de chaque participant pour lever toute ambiguïté possible :
Rôle des Devs : Quand on parle des Devs, on parle de toute personne impliquée dans la fabrication du logiciel avant qu’il n’atteigne la production : les développeurs, les gestionnaires de produits, les testeurs, les Product Owners et les QAs.
Rôle opérationnel : Il s’agit de tout le monde impliqué dans l’exploitation et la maintenance de la production: les ingénieurs systèmes, les DBAs, les ingénieurs réseaux, le personnel de sécurité, etc.
Les Développeurs (Dev) sont chargés de produire de l’innovation et délivrer les nouvelles fonctionnalités aux utilisateurs dès que possible. Les Ingénieurs d’opérations (Ops) sont chargés de s’assurer que les utilisateurs ont accès à un système stable, rapide et réactif :
- Les Dev recherchent des changements ;
- Les Ops recherchent la stabilité organisationnelle.
Bien que le but ultime de Dev et Ops soit de rendre l’utilisateur satisfait (et potentiellement heureux, client payant) des systèmes qu’ils fournissent, leurs visions sur la façon de le faire restent diamétralement opposées.
Dev vs Ops
Dev vs Ops
Quand les Dev et Ops vivaient dans leurs mondes isolés, cette opposition ne posait pas de problème. Les deux travaillaient « on a schedule » en collaborant seulement pendant les rares phases des releases. Les Devs savaient qu’ils devaient délivrer toutes les fonctionnalités désirées pour le jour « J », sinon il leur fallait attendre le prochain créneau. Et les Ops avaient suffisamment de temps pour tester les nouvelles fonctionnalités avant de les envoyer en production. Ils pouvaient ensuite prendre des jours, voire des nuits, pour déployer ces releases aux utilisateurs.
Maintenant les choses ont changé, radicalement !
Les contraintes business ont évolué d’une telle manière que les utilisateurs veulent les nouvelles fonctionnalités très rapidement. Avec l’intégration et la livraison continue les développeurs font de nouvelles releases chaque jour. Il n’y a plus de jour « J » pour délivrer le produit comme auparavant.
Les Ops ne peuvent plus prendre des jours pour déployer des fonctionnalités une fois qu’elles ont été testées, néanmoins ils doivent maintenir la stabilité.
Dev AND Ops
DevOps et ses pratiques visent à mettre fin à cette bataille entre Dév et Ops – pour parvenir à l’équilibre entre l’innovation et la stabilité. Dev et Ops doivent comprendre les bénéfices des paradigmes DevOps. Ils ont besoin de changer juste assez pour commencer à travailler ensemble et à trouver le bon alignement entre Dev et Ops dont leur organisation a besoin, et de s’améliorer à partir de là.
Ce que DevOps n’est pas
Nous avons beaucoup d’outils pour le déploiement, le monitoring, etc., mais DevOps ne se limite pas à leur utilisation. Il s’agit des changements organisationnels profonds qui peuvent être appuyés par ces outils.
Le cycle de vie d’un logiciel
Le cycle de vie traditionnel
Le besoin en DevOps est né de la popularité croissante du développement en mode agile qui conduit à un nombre accru de versions. L’un des objectifs de DevOps est d’établir un environnement qui favorise les release fiables, délivrées plus fréquemment et plus rapidement. Essentiellement, les méthodes agiles ont été utilisées uniquement pour la partie de développement de logiciel. Les Ops n’étaient pas habituellement inclus dans ce processus.
Par la suite, le code a été donné aux Ops – ou plutôt jeté par-dessus le Mur de la Confusion.
Cycle de vie DevOps
Alors vous pouvez demander « en quoi le cycle de vie de DevOps est-il différent ? »
Il peut être résumé avec l’acronyme C.A.L.M.S. :
- Culture
- Automation
- Lean
- Measurement
- Sharing
Culture
DevOps est plus qu’un simple outil ou un changement de processus. Il exige le changement de la culture organisationnelle. Ce changement culturel est particulièrement difficile à cause des rôles conflictuels des départements. Les Ops recherchent la stabilité organisationnelle ; les développeurs cherchent les changements ; et les testeurs cherchent à réduire les risques. Faire travailler ces groupes de manière cohérente est un défi crucial de l’adoption de DevOps dans l’entreprise.
Une grande source d’inspiration pour DevOps est l’Agile, et l’un des points-clés agiles dit :
« Les individus et les interactions plutôt que les processus et les outils »
Automation
Les machines sont vraiment bonnes à faire la même tâche encore et encore.
Automatiser autant que possible ! C’est quelque chose que les Ops ont fait pour rendre leur travail plus facile, mais qui n’a pas été reconnu comme une fonction vitale de l’organisation. Aujourd’hui l’organisation peut avoir des milliers de serveurs. À cette échelle cela n’est plus gérable à la main. Nous avons besoin d’automatisation pour faire le travail.
Lean
« Lean » est également la source d’inspiration pour la culture DevOps. Lean est centré sur la rationalisation des opérations, en réduisant les déchets et maximisant la valeur du client.
Lean dit qu’il est indispensable d’améliorer l’ensemble du flux et non seulement certains points dans le pipeline de production.
Les équipes Devs et les équipes Ops doivent trouver des moyens pour réduire les déchets et rationaliser les processus en entier.
Measurement
Si vous voulez améliorer quelque chose, vous devez être capable de le mesurer. Supposons qu’une nouvelle version du logiciel devrait rendre l’application plus rapide. Comment savez-vous qu’elle est plus rapide ? Le seul moyen est de le mesurer.
Dans les organisations informatiques traditionnelles, la surveillance des infrastructures était la responsabilité des Ops. Cette approche est quand-même réductrice, car le service ne se limite pas à un ensemble de serveurs. Avec la participation de l’équipe de développement nous pouvons fortement améliorer le monitoring. Les développeurs peuvent s’assurer que l’application exporte des données utiles.
Sharing
Il est très important d’aligner toutes les parties prenantes sur les mêmes objectifs – les pratiques et les flux. Tous les intervenants devraient participer et travailler ensemble pour formuler les objectifs finaux, car cela crée le sens de la propriété. Les gens sont prêts à travailler ensemble quand leurs pensées et leurs opinions sont entendues.
- Il est important d’éliminer les goulets d’étranglement à l’intérieur des départements ou entre eux ;
- Il est également important de partager les avantages entre les équipes.
Conclusion
L’automatisation des tests unitaires et des tests d’integration est l’Intégration Continue ! Cela aide au développement itératif et assure que les changements des nouvelles fonctionnalités ne cassent pas d’autres fonctionnalités. L’automatisation de tout le processus jusqu’à la “release” est couverte par la Livraison Continue. Pour s’assurer que tout fonctionne bien et améliorer l’ensemble des processus au fil du temps, il est nécessaire de tout Mesurer (Monitoring). Pour que cette mesure soit possible il est nécessaire d’avoir une bonne Communication dans la Culture du Partage et de la Collaboration, quand toute l’équipe est impliquée.
Avoir de l’automatisation c’est bien, mais ce n’est qu’en la combinant avec la culture de la communication et la collaboration entre les équipes qu’on obtient l’Approche DevOps pour le cycle de vie du logiciel.
Dans notre prochaine article nous allons continuer le deep dive dans le monde DevOps avec l’infrastructure-as-code.