Back to top icon

Qu’est-ce que le DevOps ?

Améliorez la collaboration entre les équipes informatiques, accélérez les cycles de déploiement et fournissez de meilleures expérience client avec cette méthodologie de développement logiciel moderne.

Contactez-nous

Introduction

Tandis que l’adoption du DevOps continue de s’accélérer dans les grandes entreprises et les organisations Web, la définition exacte du terme reste floue. Le DevOps est-il une culture, un mouvement, une approche, une philosophie ou un amalgame de plusieurs de ces choses ? Ou le terme revêt-il un sens différent selon les personnes ?

Quelle que soit votre définition du DevOps, la réussite DevOps n’arrive pas du jour au lendemain... c’est un périple. Et quelle que soit l’étape de ce périple à laquelle vous vous trouviez, nous pouvons vous aider à répondre à des questions fondamentales, notamment :

  • Qu’est-ce que le DevOps ?
  • D’où vient-il ?
  • Quels problèmes ont débouché sur sa naissance ?
  • Comment fonctionne-t-il ?
  • Dans quelle proportion est-il utilisé aujourd’hui ?
  • Pourquoi les gens choisissent-ils d’adopter le DevOps ?
  • Quels sont les avantages ?

Chapitre 1 : Qu’est-ce que le DevOps ?

Le mot DevOps a été inventé en 2009 par Patrick Debois, qui est en devenu l’un des gourous. Il est né de la combinaison de développement et d’opérations, ce qui nous donne un point de départ pour comprendre exactement ce que les gens entendent généralement par DevOps. Ce n’est pas un processus, une technologie ni une norme. De nombreux adeptes voient le DevOps comme une culture et New Relic partage ce point de vue. Nous utilisons aussi le terme « mouvement DevOps » quand nous parlons de sujets comme les taux d’adoption et les tendances futures, et le terme « environnement DevOps » pour faire référence à une organisation informatique ayant adopté une culture DevOps.

Il y a beaucoup plus à dire au sujet du DevOps, mais pour commencer, il nous faut une définition pratique. Personnellement, nous aimons celle que donne Gartner :

« Le DevOps représente une évolution de la culture informatique, centrée sur une livraison rapide des services informatiques grâce à l’adoption de pratiques agiles et lean dans le cadre d’une approche axée sur les systèmes. Le DevOps prend les personnes (et la culture) en compte et tente d’accroître la collaboration entre les équipes des opérations et de développement. Les implémentations DevOps s’appuient sur la technologie, en particulier, les outils d’automatisation capables d’exploiter une infrastructure de plus en plus programmable et dynamique du point de vue du cycle de vie. »

Dans une large mesure, la signification du terme DevOps s’est élargie pour inclure les processus, la culture et l’état d’esprit utilisés pour raccourcir les cycles de développement, en s’appuyant sur des boucles de commentaires pour livrer fonctionnalités, correctifs et mises à jour plus souvent.

Chapitre 2 : D’où vient le DevOps ?

Malgré l’aspect presque mythique de certains des récits portant sur ses origines, le DevOps n’est pas apparu comme par magie. En fait, l’idée du DevOps est née il y a longtemps et a été cultivée par des experts informatiques visionnaires dans de nombreuses disciplines différentes. Les deux principaux antécédents du DevOps sont :

  • L’ESM (Enterprise Systems Management) ou gestion des systèmes d’entreprise. Beaucoup des personnes impliquées dans la définition initiale du DevOps étaient des administrateurs système. Ces experts des opérations ont apporté au DevOps des meilleures pratiques ESM clés, comme la gestion des configurations, la surveillance des systèmes, le provisionnement automatisé et l’approche de chaîne d’outils.
  • Le développement agile. Un observateur a remarqué : « Le DevOps peut être interprété comme une ramification de l’approche agile... le développement logiciel agile recommande une collaboration étroite entre les clients, les responsables produits, les développeurs et (parfois) l’AQ afin de combler les fossés et permettre des itérations rapides pour un produit meilleur... [Le DevOps reconnaît] lui aussi l’importance cruciale de la livraison des services et des interactions entre les applications et les systèmes, et l’équipe produits doit faire de ces préoccupations une priorité. De ce point de vue, le DevOps ne fait qu’élargir les principes agiles, au-delà du code pour inclure l’ensemble du service livré. »

Chapitre 3 : Quels problèmes ont débouché sur la naissance du DevOps ?

Les développeurs et les administrateurs système ne sont pas toujours d’accord, mais ils s’accordent tous sur le fait que leurs clients du côté commercial les entraînent souvent dans des directions différentes. Par contre, les utilisateurs professionnels exigent des changements (nouvelles fonctionnalités, nouveaux services, nouvelles sources de revenus) dans les plus brefs délais. Mais ils veulent aussi un système stable, sans panne ni interruption. C’est problématique pour les entreprises qui se sentent obligées de choisir entre apporter des changements le plus vite possible et gérer un environnement de production instable, ou maintenir un environnement stable mais obsolète.

Bien évidemment, ni l’une ni l’autre de ces options n’est acceptable pour les cadres de direction. Et plus important encore, ni l’une ni l’autre ne permet à une entreprise de fournir les meilleures solutions possibles à ses clients.

Les développeurs sont prêts à déployer les logiciels de plus en plus vite... après tout, c’est leur travail. Mais les opérations savent que des modifications rapides sans mécanismes de sécurité risquent de déstabiliser le système, ce qui va à l’encontre de leur mission.

Le DevOps a été créé pour résoudre ce dilemme en intégrant toutes les personnes associées au développement et au déploiement logiciels (utilisateurs commerciaux, développeurs, ingénieurs de tests, ingénieurs de sécurité, administrateurs système et autres) au sein d’un seul et unique workflow extrêmement automatisé avec un objectif commun : la livraison rapide de logiciels de qualité supérieure satisfaisant toutes les exigences des clients sans compromettre l’intégrité et la stabilité du système.

Comment ces groupes disparates parviennent-ils à travailler ensemble ? En adhérant à des a principes communs qui transcendent les frontières traditionnelles entre les différentes disciplines et les différents rôles, par exemple :

  • Définition des attentes et des priorités, ainsi que des convictions fondamentales qui en sont la base
  • Collaboration au sein des équipes et entre les différentes équipes afin de résoudre les problèmes
  • Automatisation des processus courants et répétitifs pour avoir plus de temps à consacrer aux tâches plus complexes
  • Intégration des commentaires au travail pour mesurer tout ce qui est déployé dans l’environnement de production
  • Partage des données avec toutes les parties concernées pour promouvoir une culture du travail d’équipe plus efficace, avec des connaissances spécialisées et des compétences différentes

Chapitre 4 : DevOps, Agile et SRE - Explications

Les entreprises parlent souvent de passer au DevOps, d’embaucher des équipes SRE et de devenir plus agiles, mais quel est le lien entre ces termes ?

Agile et lean s’appliquent à la façon dont les équipes gèrent les itérations, avec des cycles de développement courts et des commentaires rapides. L’approche agile est axée sur la culture et ne se préoccupe pas des outils utilisés.

Le DevOps est la façon dont les organisations d’ingénierie collaborent en utilisant des équipes pluridisciplinaires. Le DevOps commence avec la culture avant de s’orienter vers les outils.

L’ingénierie de la fiabilité des systèmes (SRE, System Reliability Engineering) est la façon dont les organisations d’ingénierie gèrent l’automatisation, en confiant les opérations complexes à des personnes ayant un état d’esprit embrassant l’ingénierie logicielle. La SRE commence avec les outils avant de s’orienter vers la culture.

Les variantes DevOps (comme SecDevOps) impliquent l’insertion ou l’ajout d’une autre organisation/pratique plus tôt dans le cycle de développement logiciel, et la présence importante de ces différents types de DevOps atteste de l’intégration croissante des fonctions dans les organisations modernes.   

human systems versus technical systems diagram

Chapitre 5 : Comment fonctionne le DevOps ?

Comme pour toute culture, il existe de nombreuses variantes du DevOps. Cependant, la plupart des observateurs s’accorderaient sur le fait que quasiment toutes les cultures DevOps partagent les capacités suivantes : collaboration, automatisation, intégration continue, livraison continue, tests continus, surveillance continue et correction rapide.

Collaboration

Au lieu de se montrer du doigt et se rejeter la faute, les équipes de développement et des opérations informatiques collaborent (si, si...). Si le fossé qui séparait ces deux groupes a été l’impulsion pour son développement, le DevOps va bien au-delà de l’organisation informatique car le besoin de collaboration concerne tous ceux pour qui la livraison des logiciels représente un enjeu (pas seulement le développement et les opérations mais toutes les équipes, notamment de test, de gestion des produits et de direction).

« La base du succès DevOps est une collaboration réussie entre les équipes et les individus dans toute l’entreprise afin de faire les choses plus vite et plus efficacement. »

— Tony Bradley, Scaling Collaboration in DevOps, DevOps.com

Automatisation

Le DevOps dépend fortement de l’automatisation et cela veut dire qu’il vous faut des outils. Des outils que vous créez. Des outils que vous achetez. Des outils en open source. Des outils propriétaires. Et ces outils ne doivent pas être dispersés n’importe où : le DevOps dépend de chaîne d’outils pour automatiser une grande part du processus de développement et de déploiement logiciels.

Mise en garde : comme les outils DevOps sont extraordinaires, certains ont tendance à considérer le DevOps comme une simple panoplie d’outils. Pourtant, même s’il est vrai que le DevOps dépend des outils, il est loin de s’y limiter.

Intégration continue

On trouve généralement l’intégration continue dans les cultures DevOps, car le DevOps provient de la culture agile et l’intégration continue est un principe fondamental de l’approche agile :

« L’un des fondements du DevOps est le développement continu, une technique conçue et baptisée par Grady Booch qui fusionne continuellement les mises à jour du code source de tous les développeurs d’une équipe au sein d’un référentiel partagé. Cette fusion continue évite que la copie locale d’un projet logiciel d’un développeur ne devienne complètement obsolète au fur et à mesure que les autres développeurs ajoutent du code nouveau, qui permet d’empêcher des conflits de fusion catastrophiques. »

— Aaron Cois, « Continuous Integration in DevOps », blog sur le DevOps, institut d’ingénierie logicielle, Carnegie Mellon

Le principe d’intégration continue du développement agile a des implications culturelles pour le groupe de développement. En forçant les développeurs à intégrer leur travail au travail des autres développeurs fréquemment (au moins une fois par jour), ce principe met à jour les conflits et les problèmes d’intégration beaucoup plus tôt qu’un développement en cascade. Cependant, pour profiter de cet avantage, les développeurs doivent communiquer beaucoup plus régulièrement, un processus qui va à l’encontre de l’image du génie du code solitaire travaillant pendant des semaines ou des mois sur un module avant d’être prêt à le révéler aux yeux du monde. Ce type de communications transparentes et fréquentes s’épanouit dans un environnement DevOps.

Tests continus

Il est tentant d’ignorer le côté test du DevOps... jusqu’à ce que vous vous brûliez les doigts. Comme le dit Gartner, « vu l’impact et les coûts croissants des défaillances logicielles, personne ne peut se permettre de lancer une version qui risquerait de perturber l’expérience utilisateur existante ni d’introduire des fonctionnalités qui exposeraient l’organisation à de nouveaux risques de sécurité, de fiabilité ou de conformité ». On parle énormément de l’intégration et de la livraison continues, mais les tests continus commencent à devenir un élément DevOps essentiel.

Les tests continus ne se limitent pas à l’AQ. En fait, ils commencent dans l’environnement de développement. L’époque où les développeurs envoyaient le code à l’équipe d’AQ pour qu’elle s’en débrouille est révolue. Dans un environnement DevOps, la qualité est la responsabilité de tous. Les développeurs produisent du code de qualité et fournissent des jeux de données de test. Les ingénieurs de l’AQ configurent les scénarios de test d’automatisation et l’environnement de test.

Côté AQ, c’est la rapidité qui prime. En effet, si le cycle d’AQ prend des jours ou des semaines, vous vous retrouvez face à un calendrier en cascade qui n’en finit pas. Les ingénieurs chargés des tests gèrent ces délais serrés en automatisant une grande partie du processus de test, mais aussi en redéfinissant les méthodologies de test :

« Les tests continus créent un système décisionnaire central qui vous aide à évaluer le risque commercial que chaque application fait encourir à votre organisation. Appliqués systématiquement, ces tests aident les équipes de développement à satisfaire aux attentes de l’entreprise et fournissent aux responsables la visibilité dont ils ont besoin pour faire des choix afin d’optimiser la valeur commerciale d’une version avant son lancement. »

— Continuous Testing for IT Leaders, Parasoft

Même si cela peut paraître surprenant, les opérations ont un important rôle à jouer dans les tests et l’AQ. L’équipe des opérations peut s’assurer que des outils de surveillance sont disponibles et que les environnements de test sont bien configurés. Elle peut participer aux tests fonctionnels, de charge, de stress et de perte, et partager une analyse fondée sur son expérience d’applications semblables exécutées dans l’environnement de production.

Les avantages des tests continus justifient les efforts qu’ils demandent. La fonction de test d’un environnement DevOps aide les développeurs à trouver le bon équilibre entre qualité et rapidité. L’utilisation d’outils automatisés réduit les coûts des tests et permet aux ingénieurs qui s’en chargent d’utiliser leur temps plus efficacement. Plus important encore, les tests continus raccourcissent les cycles de test en permettant d’intégrer les tests plus tôt dans le processus.

Les tests continus éliminent également les goulets d’étranglement au niveau des tests grâce à des services dépendants virtualisés. Ils simplifient aussi la création d’environnements de test virtualisés, faciles à déployer, partager et mettre à jour au fil de l’évolution des systèmes. Tout cela permet de réduire les coûts de création et de maintenance des environnements de test, ainsi que de raccourcir les cycles de test en permettant de réaliser les tests d’intégration plus tôt.

Livraison continue

L’équipe d’Amazon Web Services définit la livraison continue comme une méthode de développement de logiciels dans le cadre de laquelle les modifications de code sont automatiquement préparées en vue de leur publication dans un environnement de production. La livraison continue étend le principe de l’intégration continue en déployant tous les changements de code dans un environnement de test et/ou de production après l’étape de création. Lorsque la livraison continue est correctement implémentée, les développeurs disposent en permanence d’un artefact de génération prêt pour le déploiement qui a été soumis avec succès à un processus de test normalisé.

La fréquence de sortie des versions peut varier considérablement en fonction de l’histoire et des objectifs de l’entreprise. Les organisations ultra-performantes qui utilisent le DevOps peuvent réaliser plusieurs déploiements par jour alors que les entreprises moyennement performantes se limitent à un déploiement par semaine ou par mois.

Le contenu des versions varie également. Dans certaines organisations, les équipes d’AQ et des opérations font un tri : beaucoup de versions vont directement aux utilisateurs, d’autres retournent en développement et d’autres ne sont tout simplement jamais déployées. D’autres entreprises mettent toutes les versions produites par les développeurs à la disposition des utilisateurs et comptent sur la surveillance en temps réel et la correction rapide pour minimiser l’impact des rares pannes qui surviennent. Il est d’ailleurs important de noter que, comme chaque mise à jour est plus petite, le risque de problème est considérablement réduit.

Surveillance continue

Dans un modèle de livraison continue, le nombre de versions est énorme et et il impossible d’implémenter les tests rigoureux avant la sortie généralement nécessaires dans les approches de développement en cascade. Dans un environnement DevOps, les problèmes doivent être repérés et résolus en temps réel. Comment y parvenir ? En grande partie grâce à la surveillance continue.

Avec la surveillance continue, les équipes mesurent les performances et la disponibilité des logiciels afin d’en améliorer la stabilité. La surveillance continue contribue à une identification précoce des causes des problèmes afin d’éviter les pannes et de minimiser les problèmes rencontrés par les utilisateurs. Certains experts de la surveillance vont même jusqu’à conseiller d’inclure la surveillance à la définition d’un service car pour eux, elle fait partie intégrante de la livraison de services.

Comme les tests, la surveillance commence au stade du développement. Vous pouvez utiliser les mêmes outils que pour la surveillance de l’environnement de production afin de repérer les problèmes de performances avant la production.

Deux types de surveillance sont nécessaires pour le DevOps : la surveillance des serveurs et la surveillance des performances applicatives. Les discussions sur la surveillance se transforment vite en discussions sur les outils, car il ne peut y avoir de surveillance efficace sans les outils adéquats. Pour une liste d’outils DevOps (et d’autre contenu lié au DevOps), rendez-vous dans le centre DevOps de New Relic.

Chapitre 6 : Qui adopte le DevOps ?

Des start-ups aux entreprises centenaires, le DevOps s’impose dans toutes les organisations informatiques. Une enquête montre que 74 % des entreprises ont mis en œuvre une initiative DevOps d’une façon ou d’une autre.

Quels types d’entreprises adoptent le DevOps ? Les « licornes » Web comme Etsy, Facebook, Amazon et Netflix sont souvent citées comme exemple de leaders DevOps, mais aujourd’hui tous les types d’entreprises embrassent le DevOps. L’entreprise de divertissements traditionnelle Sony Pictures, le géant des services financiers Barclays Bank et le fabricant de matériaux de construction USG sont quelques exemples d’entreprises qui font la une pour leur réussite DevOps.

De façon peut-être un peu surprenante, ce sont les grandes entreprises qui sont en tête et 81 % déclarent être en train d’adopter le DevOps. Les PME exploitent aussi les avantages DevOps, avec 70 % déclarant l’utiliser. Il y a de nombreuses preuves que la taille de l’entreprise seule ne suffit pas à prévoir la réussite DevOps.

Même les organismes gouvernementaux ou quasi gouvernementaux se mettent au DevOps. Prenons Fannie Mae, par exemple, qui utilise le DevOps pour transformer son activité et d’une organisation qui change très lentement est en train de devenir une organisation qui change très rapidement.

Le bureau des brevets et des marques américain a adopté le DevOps et voit désormais 1 000 versions automatisées par semaine en moyenne. Aux services généraux américains (General Services Administration ou GSA), les conteneurs de production, les workflows automatisés et les microservices ne sont que quelques exemples de la façon dont l’organisme gouvernemental modernise ses opérations pour livrer des projets de meilleure qualité plus rapidement.

Mais alors que l’avènement du cloud et des technologies de conteneurs contribuent à l’adoption DevOps dans le monde entier, Gene Kim, auteur et expert DevOps, souligne que le DevOps a encore une large marge de développement. On le voit souvent dans les organisations où une présence DevOps s’est déjà mise en place et sert de moteur à de nouveaux efforts de développement.

« Nous disposons maintenant des preuves nécessaires que le DevOps n’est pas réservé aux licornes de Google, Amazon, Facebook et Netflix, mais qu’il est vraiment adapté à toutes les organisations technologiques, surtout dans les grandes entreprises complexes. Mais ce qui est vraiment génial, c’est que ces entreprises voient le même genre de résultats que seules les licornes enregistraient jusqu’alors. »

— Gene Kim, expert DevOps

Chapitre 7 : Pourquoi vos pairs adoptent-ils le DevOps ?

Le DevOps a quelque chose à offrir à chaque acteur de la chaîne logicielle : développement, opérations et tests. En outre, le DevOps touche même le côté commercial d’une organisation : les responsables qui monétisent les logiciels et les cadres qui se préoccupent du chiffre d’affaires. Voici certains des avantages cités par chaque groupe.

Développeurs

Le provisionnement automatisé est un vrai plus pour les programmeurs car ils peuvent déployer eux-mêmes un environnement de développement, sans paperasserie, sans cycles d’approbation interminable, sans avoir à attendre que le service informatique fournisse un serveur... plus de pertes de temps. Quand les développeurs peuvent provisionner un environnement de travail en quelques minutes, avec toutes les ressources nécessaires (puissance de calcul, stockage, réseau, applications), leur façon de travailler en est transformée. Ils peuvent donner libre cours à leur esprit créatif et novateur. Il devient beaucoup plus facile d’essayer plusieurs options, d’exécuter des scénarios différents et de tester leur code de façon plus approfondie.

Quand les développeurs font leurs premiers pas dans l’univers DevOps, une véritable révélation pour beaucoup d’entre eux est de voir ce qui se passe dans cette boîte noire appelée « opérations ». Cette découverte les aide à travailler efficacement avec le service des opérations pour résoudre les problèmes ensemble. Les problèmes sont résolus plus rapidement et causent moins de distractions. Mieux encore, les appels désespérés de l’équipe des opérations en pleine nuit suite à la panne d’un site appartiennent désormais au passé. Le résultat ? Une satisfaction professionnelle accrue et une meilleure qualité de vie pour les développeurs.

Opérations

Selon une croyance répandue, les administrateurs système sont obsédés par la stabilité de leurs systèmes... et c’est vrai. Leur pire cauchemar est une version logicielle qui cause la panne du système dans les secondes suivant son déploiement dans l’environnement de production, des développeurs qui se lavent des mains du problème (« C’est votre code maintenant ! »), des utilisateurs mécontents et aucune résolution rapide et efficace en vue.

Les premiers utilisateurs des méthodes DevOps ont découvert que l’implication accrue des développeurs améliore la stabilité des systèmes. En fait, des versions moins importantes et plus fréquentes introduisent moins de variances dans le système et réduisent ainsi le risque d’une catastrophe. Mieux encore, ces versions plus limitées peuvent être introduites pendant la journée au lieu du milieu de la nuit ou du week-end, alors que tout le monde est au travail et disponible pour résoudre les problèmes.

L’automatisation est également très utile car elle élimine les erreurs humaines qui peuvent survenir dans les opérations manuelles et réduit le temps consacré aux tâches routinières. Cela a aussi un impact sur la qualité de vie des administrateurs système : nouvelles compétences, opportunités professionnelles et beaucoup plus de sommeil et de temps libre. Dans un environnement DevOps, les opérations s’appuient beaucoup plus sur les outils que dans un environnement traditionnel. Il n’est pas rare qu’elles développent leurs propres outils et rédigent des scripts conçus pour automatiser certaines parties du processus de déploiement.

En repensant à tout cela, il n’est donc guère surprenant que le titre de « directeur des opérations » ou « directeur de l’exploitation » ait été le plus courant parmi les participants au sommet des entreprises DevOps.

Ingénieurs de tests

Le DevOps a eu un impact considérable sur les tests. Comme l’a déclaré un observateur :

« C’est un univers avec plusieurs versions itératives, quasi continues, sortant dans les jours, voire les minutes, qui suivent la précédente, toutes déployées dans l’environnement de production final et mises entre les mains de clients exigeants. Tant de versions, si peu de temps pour les tester et tant de pression pour fournir de la qualité... Y a-t-il jamais eu un cas plus parfait, théoriquement au moins, auquel appliquer l’automatisation des tests ? »

Le DevOps nécessite de nouvelles approches des tests logiciels et les ingénieurs de tests se retrouvent donc dans l’obligation d’innover. Avec le provisionnement automatisé, ils peuvent fournir un environnement de test quasiment identique à l’environnement de production, ce qui débouche sur des tests plus précis et de meilleures prévisions des performances des nouvelles versions. Comme pour les autres groupes, l’automatisation et la collaboration boostent la productivité des ingénieurs de tests.

Responsables produits

Techniquement, le DevOps ne concerne que la fonction informatique d’une entreprise. Cependant, les responsables produits, ainsi que les responsables du marketing et les responsables commerciaux, peuvent en tirer des avantages énormes :

  • Commentaires plus rapides : dès qu’un nouveau produit ou une nouvelle fonctionnalité est fourni aux clients, les responsables produits commencent à recevoir des commentaires.
  • Réactivité accrue : grâce à la livraison continue, le DevOps réduit considérablement la mise sur le marché des nouvelles fonctionnalités répondant aux besoins des clients.
  • Réduction des pertes et des risques : les ressources de développement peuvent résoudre les problèmes ou travailler sur de nouvelles fonctionnalités sans attendre la version suivante.

Regardons tout ça de façon un peu plus détaillée. Dans un environnement DevOps, les acteurs commerciaux ont plus d’influence sur le processus de développement. Grâce à l’esprit collaboratif du DevOps, les développeurs se soucient des besoins commerciaux et entretiennent des relations avec les responsables produits. Avec le DevOps, les responsables produits bénéficient aussi de retours immédiats sur l’impact des nouveaux tarifs, des fonctionnalités et des packs de produits, ce qui leur permet de tester différentes variantes et d’évaluer leur efficacité.

Les responsables des unités commerciales raffolent du DevOps car il permet une mise sur le marché accélérée des produits, ce qui leur confère un avantage concurrentiel. Comme le DevOps améliore la stabilité des systèmes, les clients subissent moins de défaillances et sont donc plus fidèles, le parfait antidote aux taux de pertes de clients élevés.

Cadres

Quand Patrick Debois et autres experts informatiques ont lancé le mouvement DevOps, ils ne se sont pas posé la question de sa réception par les conseils d’administration des entreprises. Et pourtant, aujourd’hui, le DevOps est un sujet brûlant pour ces conseils d’administration.

Qu’est-ce qui plaît aux cadres dans le DevOps ? D’abord, le DevOps aide l’organisation à fournir des produits de qualité supérieure et à les mettre sur le marché plus vite que les concurrents qui utilisent des méthodes de développement logiciel traditionnelles... tout cela a un impact positif sur les résultats de l’entreprise. Ensuite, le DevOps permet d’attirer et de conserver les meilleurs professionnels : les développeurs, administrateurs système et ingénieurs de tests de talent veulent travailler de la façon la plus moderne et la plus efficace possible. Enfin, quand les développeurs, les opérations et l’AQ collaborent, les cadres de direction se retrouvent rarement au cœur de conflits entre ces services, ce qui leur donne plus de temps pour élaborer les objectifs commerciaux pointus que tout le monde essaie d’accomplir.

« Les employés travaillant au sein d’équipes (DevOps) ultra-performantes étaient 2,2 fois plus susceptibles de recommander leur organisation comme excellent lieu de travail et 1,8 fois susceptibles de recommander leur équipe comme excellent environnement de travail. Cela est très important car les études montrent que les entreprises avec des employés très impliqués voient une augmentation de leurs revenus 2,5 fois supérieure à celle des entreprises avec des employés peu impliqués.

— Rapport sur l’état du DevOps 2016, Puppet Inc. et DORA

Chapitre 8 : Quels avantages le DevOps m’apportera-t-il ?

Des sources dignes de confiance signalent des avantages liés au DevOps tout à fait remarquable, mais la prudence est de mise. Imaginez que vous entendiez quelqu’un dire que son véhicule consomme 8 litres/100 km. S’il s’agit d’un camion F-150 conduit hors route, vous n’y croiriez pas, mais dans le cas d’une nouvelle Prius exclusivement conduite sur autoroute, ce chiffre serait assez décevant. Le contexte est important, alors quand quelqu’un vante les améliorations obtenues grâce au DevOps, n’oubliez pas que les résultats peuvent varier.

Ceci dit le rapport sur l’état du DevOps en 2018 réalisé par DevOps Research and Assessment (DORA) a montré que les entreprises les plus performantes en matière de DevOps sortaient des logiciels 46 fois plus souvent que les entreprises les moins performantes, avec des délais 2 555 fois plus rapides. La qualité des produits logiciels est également plus élevée, comme le prouve un taux d’échec des changements sept fois plus bas. Enfin, l’effet sur la stabilité des systèmes est extrêmement positif : en cas de panne de la plateforme, les entreprises les plus performantes rétablissent le service 2 604 fois plus vite que les entreprises les moins performantes. 

Une chose est sûre : les professionnels de l’informatique qui ont adopté le DevOps avec succès en sont fous. Et c’est compréhensible quand on voit les améliorations citées dans une enquête réalisée par Puppet Labs :

  • Stabilité : les organisations performantes perdent 22 % de temps en moins sur le travail et les changements imprévus. Cela leur permet de consacrer 29 % de temps en plus aux tâches nouvelles, comme le développement de nouvelles fonctionnalités ou de nouveau code.
  • Sécurité : les organisations les plus performantes passent 50 % moins de temps à résoudre des problèmes de sécurité que les organisations moins performantes.
  • Vitesse de déploiement des applications : les organisations les plus performantes effectuent des déploiements plusieurs fois par jour, à la demande, alors que les organisations les moins performantes le font entre une fois par mois et une fois tous les 6 mois.

Conclusion

« Le DevOps n’est pas une fin en soi, mais un processus infini d’amélioration continuelle. »

— Jez Humble, fondateur et directeur technique, DevOps Research and Assessment

Voici dix ans que la grande aventure du DevOps a commencé et les résultats ne laissent aucun doute : le DevOps est là pour durer, et pour d’excellentes raisons. Beaucoup pensaient que c’était impossible, mais le DevOps a réussi à intégrer les utilisateurs commerciaux, les développeurs, les ingénieurs de tests, les ingénieurs de sécurité et les administrateurs système au sein d’un seul et unique workflow, axé sur la satisfaction des exigences des clients. Pourquoi sont-ils tous prêts à participer ? Car tout le monde y gagne. Les développeurs et les administrateurs système arrêtent de se quereller et commencent à s’entraider, ce qui est bon pour la tension de tout le monde. Les responsables commerciaux sont ravis parce qu’ils disposent des produits logiciels dont ils ont besoin pour vendre produits et services. Les cadres voient leurs chers indicateurs (revenus, satisfaction client, fiabilité des systèmes) s’envoler. Et tous peuvent fournir les meilleurs résultats et la meilleure expérience globale qui soient aux clients.

Mais de tels gains ne tombent pas du ciel. Pour déployer du code plus souvent tout en assurant le fonctionnement ininterrompu des systèmes, vous devez pouvoir surveiller de près tous les changements qui se produisent dans votre environnement. Avec la plateforme New Relic, les équipes de développement et des opérations bénéficient d’une visibilité sur l’ensemble de la pile : de l’expérience client numérique aux applications et à l’infrastructure dynamique, en passant par les alertes et les tableaux de bord intégrés. Tout cela peut aider chaque membre d’une organisation à mieux comprendre comment le déploiement des logiciels et leurs performances en temps réel.