DevOps est la contraction de Developer (au sens large: product owner, concepteur, développeur, testeur…) et de Operations (administrateur système, exploitant, RSSI – responsable sécurité, ingénieur réseau, DBA – administrateur base données…).  Dans les DSI traditionnelles, ces 2 rôles (Etudes / Exploitation) sont souvent en « opposition »: les Devs cherchent le changement et la nouveauté pour apporter de la valeur aux client tandis que les Ops veulent satisfaire le client en lui garantissant la stabilité, les temps de réponse et la sécurité des infrastructures. Cette opposition structurelle est illustrée par le « mur de la confusion ».

Le DevOps propose donc une approche pour briser ce mur de la confusion.

Si on ne trouve pas de définition officielle, ni de manifeste comme dans l’approche agile, voici la définition du State of DevOps Report 2017 :

Aujourd’hui, DevOps est un ensemble compréhensible de pratiques et de valeurs qui ont prouvé, pour des entreprises de toutes tailles, leur efficacité à améliorer: les cycles de livraison logicielle, la qualité logicielle, la sécurité et la capacité à avoir un retour rapide des clients sur le produit.

Traduction de :
Today, DevOps is an understood set of practices and cultural values that has been proven to help organizations of all sizes improve their software release cycles, software quality, security, and ability to get rapid feedback on product development.

L’origine de DevOps est attribuée à Patrick Debois en 2009 en Belgique à la suite d’une conférence de flickr sur l’intégration continue. Parmi, les nombreuses personnalités ayant contribué à l’émergence du mouvement DevOps, on peut citer Jez Humble, co-auteur d’un des ouvrages de référence intitulé Continous Delivery.

Quelles sont les raisons ce succès ?

La raison est simple, les organisations ayant adopté DevOps développent un avantage concurrentiel déterminant en réduisant leur time to market ainsi que le nombre / temps de résolution des incidents.

Afin d’illustrer ce constat, voici les résultats de l’étude State of DevOps Report 2017 sur plus de 3 000 interviews à travers le monde.
Les High IT performers sont en mesure de déployer plusieurs fois / jour alors que les Low IT performers sont à un rythme mensuel ou semestriel (facteur x180). Idem pour le lead time qui passe de 1h à plusieurs mois (facteur x4320) ou encore le temps de réparation d’un incident en production en dessous de l’heure pour les High IT performers comparé à 1 journée pour les Low IT performers (facteur x24):

Extrait de: Forecasting The Value Of DevOps Transformations, Measuring ROI of DevOps

Le parallèle avec l’agilité

Avec l’approche agile (Scrum, XP ou Kanban…), les équipes de développement et métier (MOA) ont appris à collaborer pour livrer plus régulièrement du logiciel à chaque fin de sprints en s’approchant du rythme souhaité par le client. Hélas, dans beaucoup de DSI traditionnelles, les équipes Ops sont exclues de cette agilité et restent sur le rythme du cycle en V avec des livraisons mensuelles ou trimestrielles via des comités de validation. La mise en place de DevOps permet briser le mur de la confusion entre les équipes Etudes et les équipes Exploitation pour délivrer la valeur plus fréquemment sur la totalité de la chaîne de production: depuis l’idée jusqu’à la livraison au client.

De nouveaux rôles pour les Devs et les Ops

Auparavant, le rôle du Dev était de développer du code, de le confier à un testeur, puis de passer le  »relais », souvent sous forme de package applicatif et d’une documentation d’installation à l’Ops afin que ce dernier l’installe dans un environnement de production.  Cette étape, souvent douloureuse était source de tension car malgré tous les points de contrôle qualité (tests intégration, recette, tests préproduction…), de nombreux incidents accompagnaient les mises en production.

Qui n’a pas connu la fameuse règle du « Pas de mise en production le vendredi ! » ?
Jez Humble cite d’ailleurs régulièrement lors de ses conférences qu’une de ses premières motivations pour promouvoir le DevOps était de: « Boire sereinement un mojito au bord de la piscine le vendredi soir ! ».

Avec DevOps, le rôle de chacun évolue. Le Dev développe, teste et déploie son package lui-même en production. C’est le concept du « You build it, you run it ». Le rôle de l’Ops est tout aussi essentiel mais il se concentre davantage sur des activités à forte valeur comme industrialiser les plateformes en Infra as a code, de trouver les meilleurs fournisseurs cloud, de fournir toute la métrologie nécessaire et enfin d’optimiser les coûts. Il devient donc un partenaire essentiel du Dev en lui fournissant par exemple en libre service des environnements  »prêts à l’emploi ». Les rôles sont donc redessinés, les frontières s’estompent pour améliorer le flux de valeur en réduisant le lead time.

Et de nouvelles pratiques

Si DevOps est souvent réduit à l’utilisation de nouveaux outils et techniques, c’est parce qu’ils sont tout simplement indispensables à une transformation réussie. Passons en revue les éléments principaux:

• Outil de gestion des configurations / sources : mêmes s’ils ne sont pas nouveaux (plusieurs dizaines d’années, la préhistoire à l’échelle de l’IT), ils ont considérablement évolués d’une architecture centralisée type SVN à une architecture distribuée type GIT beaucoup plus « souple ». Cela répond aux enjeux de décentralisation des équipes souvent à distance, en télétravail… et aussi au process de développement agile itératif où les branches ont une durée de vie courte qu’en cycle en V. Ce nouveau process de versionning du code appelé trunk based developpement vise à limiter l’utilisation des branches et plus particulièrement la durée de vie des branches qui doivent rapidement être fusionnées sur le tronc. C’est la condition nécessaire pour livrer des petites pièces de code rapidement plutôt que de grandes évolutions rarement. Autre nouveauté, ces outils ,traditionnellement réservés aux Devs, sont maintenant également utilisés par les Ops pour scripter la génération d’environnements, la créations de VM, le déploiement d’application dans un environnement donné…

  

• Outils de développements IDE – Integrated Developpement Environment: là encore, les outils ne sont pas nouveaux mais ils ont évolué pour s’intégrer complètement avec les plateformes d’intégration continue, le cloud computing et la qualité du code via l’ajout de plugins. Ils sont donc l’outil de travail quotidien du développeur.
• Tests automatiques: les tests unitaires étaient déjà une pratique fortement ancrée par les équipes adeptes de XP – eXtreme Programming -, avec l’approche DevOps, ces tests deviennent tout simplement indispensables et généralisés. On ne peut envisager d’accéler le cycle de déploiement s’il faut repasser par une longue phase de tests de non-régression manuelle. Ils sont donc le socle nécessaires pour bâtir la « pyramide des tests » équilibrée de votre application:

  

  Source: DevOps Research & Assessment

   

• Qualité du code: l’objectif est d’être en mesure à chaque instant de s’assurer de la qualité de son code via des outils de qualimétrie: robuste, maintenable, évolutif et conforme aux standards de la profession. Les outils de qualimétrie sont intégrés à l’IDE et aux plateformes d’intégration continue qui permettent des remonter une alerte en direct si un violation apparait (violation = bug potentiel en production ou de la dette technique pour plus tard). La qualité du code passe par des revues de code, par exemple via le principe du pull request où le Dev va soumettre son code à un de ses collègues avant de le fusionner avec le tronc. Encore une fois, certaines de ces pratiques étaient déjà très largement répandues dans XP.
• Intégration continue: l’intégration continue consiste à compiler et construire l’application au fil des mises à jour du référentiel des sources. Cela permet d’éviter les problèmes de fusion de code entre les Devs. Les outils d’intégration continue, citons Jenkins, un des plus connus, sont donc en mesure de détecter une mise à jour du code a été réalisée, de récupérer cette mise à jour, de la compiler avec l’ensemble des autres codes sources puis de déclencher d’autres actions comme les tests unitaires pour détecter d’éventuelles régressions, la qualimétrie globale du code, le taux de couverture des tests automatiques, le versionning du code… Bien entendu, en cas d’échec d’une des étapes, un mail est envoyé à l’ensemble de l’équipe pour que la correction soit réalisée au plus vite.
• Déploiement automatique : la phase de déploiement était souvent fastidieuse et présentait peu de valeur ajoutée: se connecter à une machine, copier des fichiers, arrêter un serveur, redémarrer un serveur… Avec les outils de déploiement automatique, ces étapes ont été scriptées (ou automatisée) par les équipes DevOps. Le déploiement peut donc être réalisé en sélectionnant la version du code à déployer et en cliquant sur un simple bouton pour réaliser l’installation dans un environnement donné. Là encore, le gain de temps est conséquent et l’opération est fiabilisée.
• Gestionnaire d’artefact: probablement l’outil le moins connu, cet outil est pourtant indispensable afin de conserver des archives de toutes les versions du code et accessoirement servir de proxy pour limiter le téléchargement de dépendances

En plus de ces outils et pratiques, la culture DevOps encourage à les équipes :

• à expérimenter, ce qui signifie que l’équipe n’est pas  à 100% focalisée sur les besoins provenant du métier. Le droit à l’expérimentation est essentiel pour continuer à innover et s’améliorer.
• à comprendre la chaîne de création de valeur délivrée par les Devs et les Ops ainsi que la chaîne de valeur du produit délivrée (du point du client cette fois)
• à obtenir le feedback du client ou de l’utilisateur pour comprendre l’usage du produit et les attentes
• à travailler sur des petites pièces, ce qui revient à découper les user-stories ou tâches de développement en petites unités de quelque jours maximum. C’est une condition assez évidente pour être en mesure d’accélérer le time to market mais qui dans les faits s’avère difficile à réaliser.

Stay CALMS, do DevOps !

On ne pourrait parler du DevOps sans citer les 5 concepts sous-jacents résumés dans l’acronyme C.A.L.M.S. :

• Culture : plus qu’un ensemble d’outils et de pratiques, DevOps est une vraie culture qui trouve ses sources d’inspiration dans le Lean et dans le manifeste agile. Parmi ces principes et valeurs, on trouve l’amélioration continue (être dur avec le code ou les situations mais doux avec les personnes) ou encore la volonté de casser les silos traditionnels et challenger le statut quo.
• Automation : on cherche à accélérer le processus de bout en bout (time to market) en automatisant les tâches répétitives et pénibles pour le collaborateur. La capacité ainsi libérée tant chez les Devs que chez les Ops est une opportunité pour l’amélioration continue. Cette automation est réalisée via les plateformes d’Intégration Continue (CI) ou de Déploiement continue (CD). Elle concerne aussi la mise à disposition des environnements avec l’Infrastructure As A Code – IAAS.
• Lean: certains grands principes du Lean sont présents: satisfaire le client par une qualité irréprochable (tests automatiques, dojo, peer programming, right first time…) au rythme de sa demande (Just in time) et en éliminant les gaspillages (attentes, transport, gestes inutiles, stock…)
• Measure: traduit souvent par « l’obsession de la mesure ». Mesurer est indispensable pour factualiser (l’implicite devient explicite) et montrer l’amélioration continue.
• Sharing ou Solidarité: le partage de la connaissance est essentiel, le code n’est plus la propriété des Devs et l’infrastructure, la propriété des Ops. Le produit devient collectif, tout comme l’apprentissage. Chaque problème ou erreur devient une occasion d’apprendre plutôt que de rechercher un coupable.

Pour conclure, comme vous avez pu le voir à travers ce court article, DevOps est un enjeu de transformation vitale pour la compétitivité des entreprises. Cette transformation est bien d’ordre culturel et doit donc être soutenue par l’ensemble de l’organisation. Les prévisions du Gartner Group vont même d’ailleurs encore plus loin en prévoyant que d’ici 2020: « 50% of CIO’s that have not transformed their capabilities will be displaced from the digital leadership team » !

Et vous, comment vous situez vous par rapport la transformation DevOps ?
Si vous souhaitez en discuter avec nous, n’hésitez pas à nous contacter !

Par Thomas Deligny
Merci à Pierre Jannez et Christian Ignace pour la relecture et Frédéric Buono pour l’illustration.

Pour aller plus loin, je vous recommande:
The DevOps handbook
MOOC: Intro to DevOps