Published Date: August 1, 2019
Par définition, le DevOps représente une approche de la livraison IT qui conjugue des personnes, des pratiques et des outils pour supprimer les silos qui isolent les équipes de développement et d’exploitation. Les équipes de DevOps ont la charge d’accélérer le développement des applications et des services et, grâce à une approche plus réactive de la gestion de l’infrastructure IT, elles peuvent déployer et mettre à jour des produits à la vitesse des marchés d’aujourd’hui.
L’approche DevOps crée un pont entre le « dev » et les « ops » : en d’autres termes, le développement logiciel, qui produit le code des applications, et les opérations IT, qui se chargent de mettre ces applications en production à la disposition des utilisateurs, et de les maintenir. La méthode DevOps a émergé de deux tendances antérieures : le mouvement du développement agile et les principes du lean manufacturing. Le premier, le DevOps Agile, met l’accent sur des cycles de travail courts et des itérations rapides pour créer une organisation de développement IT plus réactive, tandis que le second, le lean manufacturing, minimise le gaspillage et maximise la productivité dans les usines.
La méthode DevOps représente l’intégration efficace du développement logiciel, de l’assurance qualité et des opérations informatiques, jusqu’ici confiés à des équipes isolées.
L'approche DevOps résout le goulet d’étranglement associé au développement agile. Si les développeurs agiles produisent de nouveaux logiciels ou des mises à jour de code à une fréquence plus élevée, les équipes d’exploitation traditionnelles ne parviendront pas à tester le logiciel et le mettre en production en temps voulu, et la valeur réelle d’un développement rapide sera donc perdue. Au final, si le mouvement agile a rendu la conception et le développement logiciels plus itératifs et flexibles, cette approche ne s’est pas étendue à tout le cycle de vie du développement (SDLC) et n’a pas atteint le déploiement.
En tant que culture ou approche philosophique, par définition, le DevOps est dédié à l’amélioration permanente, à la collaboration et à la transparence. L’approche DevOps consiste à voir les opérations IT de façon holistique en termes de valeur. Son objectif n’est pas de se concentrer sur des silos individuels, mais sur tout le flux, de l’idée d’origine à la disponibilité du produit ou de la fonctionnalité, afin d’en optimiser toutes les étapes dans le but de produire une valeur commerciale accrue à un rythme plus soutenu. Les équipes DevOps hautement performantes n’observent pas seulement une accélération des itérations et du déploiement du code, mais aussi une réduction globale du délai de mise sur le marché des nouvelles idées, une baisse du nombre de bugs et une infrastructure plus stable.
Nous allons ici passer en revue les concepts clés de la méthode DevOps afin d’en comprendre la définition et identifier les points d’entrée vous permettant d’adopter une culture DevOps performante dans votre propre organisation.
Développement et opérations : qu’est-ce que le DevOps ?
Souhaitant faire disparaître la rivalité entre développement et opération, le concept du DevOps est né d’une volonté de rendre les entreprises plus réactives. Pour ce faire, les départements IT doivent améliorer la communication entre leurs équipes, tout en optimisant leurs processus et leurs approches. La finalité étant d’augmenter leur valeur ajoutée auprès du client.
Le développement logiciel agile a commencé par le « Manifeste du développement agile », un court document publié en 2001 par 17 développeurs, qui promulguait quatre principes essentiels :
- Les individus et les interactions priment sur les processus et les outils.
- Un logiciel fonctionnel prime sur une documentation complète.
- La collaboration avec le client prime sur la négociation des contrats.
- La réactivité au changement prime sur le respect du plan.
Ces principes remettaient en question le développement traditionnel en cascade, strictement séquentiel et documenté de façon exhaustive, et organisé selon les rôles, les outils et des processus rigoureusement définis. Mais quand les équipes de développement agile ont commencé à livrer des itérations plus rapidement, répondant prestement aux changements de spécifications et autres circonstances, les équipes des opérations n’étaient pas nécessairement prêtes à adopter ce nouveau rythme. C’est dans ce contexte qu’a vu le jour l’approche DevOps.
En effet, en 2008, le Belge Patrick Debois et l’Américain Andrew Clay Shafer ont commencé à discuter des défis de l’agilité dans l’infrastructure IT. Un an plus tard, Debois organisait le premier événement « devopsdays » à Gand, en Belgique. C’est à partir de ce jour que le terme DevOps est entré dans le vocabulaire courant de l’informatique
Trois principes essentiels de la méthode DevOps, d’abord exposés par Gene Kim, auteur et promoteur du DevOps, sont les suivants
- Pensée systémique : une approche plus holistique de l’IT qui englobe les développeurs, les testeurs, les responsables des infrastructures et les consommateurs de code ou de logiciels, et qui « donne la priorité à la performance du système dans son ensemble plutôt à qu’à celle d’un silo ou d’un service spécifique ».
- Amplification des boucles de rétroaction : Kim observe que « l’objectif de presque toutes les initiatives d’amélioration des processus consiste à raccourcir et amplifier les boucles de rétroaction afin qu’on puisse apporter les corrections requises en continu ».
- Expérimentation et apprentissage en continu : si le Manifeste agile valorise la réactivité et la collaboration, la méthode DevOps promeut la poursuite de l’amélioration permanente, pour trouver des nouvelles méthodes de travail plus efficaces. Kim parle de la nécessité de créer « une culture qui encourage deux choses : d’une part, l’expérimentation en continu, la prise de risques et les échecs comme source d’enseignement ; d’autre part, comprendre que la répétition et la pratique sont les fondements de la maîtrise ».
Une culture DevOps repose sur des équipes multidisciplinaires qui élaborent et déploient en continu de nouvelles fonctionnalités et de nouveaux services. Dans la méthode DevOps, les développeurs sont chargés de maintenir le code qu’ils écrivent : ils résolvent ainsi plus efficacement les incidents et se soucient davantage d’intégrer de la fiabilité dans tout ce qu’ils produisent. De plus, une équipe DevOps se concentre sur le cycle de vie de tout le produit plutôt que sur des projets affectés séparément, comme la création d’une nouvelle fonctionnalité ou la conception d’un nouveau composant web. Par définition, l’état d’esprit DevOps axé sur le produit (parfois résumé par la formule « penser produits, pas projets ») aide l’IT à mieux s’aligner sur la valeur commerciale de son travail, et à donner la priorité à ce qui sert l’entreprise et l’utilisateur final, améliorant ainsi l’adoption et l’utilisation des services, et donc la fidélité des clients et les revenus de l’entreprise.
Quelle est la différence entre l’approche DevOps et la méthode agile ?
L’approche DevOps est un élargissement des principes agiles du développement au déploiement logiciel. Si l’évolution déclenchée par le Manifeste agile a proposé des manières plus efficaces de créer des logiciels, la méthode DevOps, quant à elle, applique des principes et des philosophies similaires à tout le cycle de vie de développement, jusqu’à la publication du code.
Qu’est-ce que le développement continu de l’approche DevOps ?
Le développement continu englobe plusieurs concepts du modèle DevOps : intégration et livraison continue (CI/CD), et déploiement continu. En produisant, en publiant et en mesurant constamment de petites améliorations plutôt qu’en se limitant à de gros lancements annuels (ou même moins fréquents), les équipes IT peuvent améliorer leur offre en permanence. Que cette offre soit le produit principal d’une entreprise logicielle comme Netflix ou Instagram, ou une amélioration apportée à un site web ou un service IT, la mise en place de processus DevOps permet à l’entreprise de rester compétitive dans un marché où les jeunes sociétés innovantes viennent régulièrement perturber les leaders du marché, voire des marchés entiers.
Qu’est-ce que l’intégration continue en DevOps ?
L’intégration continue de l’approche DevOps consiste à incorporer régulièrement du nouveau code dans le code source principal à chaque fois que des tâches isolées sont achevées. Le nouveau code est incorporé dans un dépôt central commun où un service automatisé teste et valide les modifications. Cette méthode spécifique de DevOps permet de mettre rapidement les problèmes au jour, de fournir un feedback immédiat aux développeurs et d’apporter les modifications nécessaires sans délai.
Qu’est-ce que la livraison continue en DevOps ?
Par définition, la livraison continue en DevOps consiste à tester le nouveau code au fur et à mesure de son intégration afin de prolonger la vélocité de l’intégration continue. La livraison continue automatise le test et la préparation du code au déploiement.
Ce processus DevOps peut inclure des tests unitaires, d’intégration, fonctionnels et de régression. Une fois le code approuvé, il est automatiquement préparé pour déploiement. Toutefois, la livraison continue du logiciel ne déploie pas automatiquement le code validé. C’est l’apanage du déploiement continu..
Qu’est-ce que le déploiement continu en DevOps ?
Le déploiement continu basé sur l’approche DevOps consiste à automatiser la publication de nouveau code au fil de son intégration et de son approbation via l’intégration et la livraison continues. Le code testé avec succès via les processus de livraison automatisés est préparé et publié dans l’environnement de production, de façon à mettre la nouvelle fonctionnalité à la disposition des utilisateurs finaux.
Dans le cadre de cette approche DevOps, comme le code passe du développeur à l’utilisateur final sans intervention manuelle, le déploiement continu présente des risques. En règle générale, le déploiement continu est adapté aux produits et fonctionnalités présentant un faible niveau de risque. Lorsque des données sensibles, un risque de sécurité élevé, des obligations réglementaires ou un risque financier important sont en jeu, les équipes DevOps sont moins enclines à utiliser le déploiement continu. En dehors de ces considérations, le déploiement continu est généralement considéré comme un objectif clé de la culture DevOps, car il offre un maximum de vélocité et de rentabilité.
Le déploiement continu et la livraison continue sont souvent confondus, d’autant qu’ils partagent le même acronyme en anglais, « CD ». Mais si la livraison continue fournit un logiciel prêt à être publié, seul le déploiement continu (ou le déploiement manuel) met concrètement les mises à jour en production pour les utilisateurs finaux.
Qu’est-ce que l’architecture DevOps ?
L’architecture DevOps désigne généralement l’infrastructure qui facilite la mise en œuvre des objectifs de votre culture DevOps ; il n’existe pas d’architecture unique et formelle pour le DevOps, et les organisations IT n’ont pas nécessairement besoin d’abandonner leur architecture existante pour adopter cette approche. Il existe toutefois des principes clés et des bonnes pratiques qui peuvent permettre d’orienter l’architecture d’une organisation DevOps.
L’ascension de la culture DevOps au sein des entreprises coïncide avec celle des plateformes cloud, et le cloud et autres technologies de virtualisation contribuent considérablement au succès du DevOps. Plusieurs technologies courantes soutiennent ou facilitent les organisations DevOps, dont les plateformes cloud, la virtualisation et les microservices.
- Cloud: les plateformes cloud permettent à l’IT de provisionner des ressources dans des environnements virtuels (le cloud) plutôt qu’en local. Grâce à ces plateformes, les utilisateurs accèdent à des ressources rapidement et avec une grande flexibilité. (Pour en savoir plus, consultez la section : « Quel est le rôle du cloud dans le DevOps ».)
- Virtualisation : avant la virtualisation, un serveur était une machine physique, et s’il vous fallait un deuxième serveur, vous deviez aller en acheter un. La virtualisation permet de créer des serveurs virtuels (ou des postes de travail, etc.) : au lieu d’acquérir une nouvelle machine, les équipes de développement peuvent créer des environnements virtuels sur des serveurs locaux ou cloud. Cette approche supprime un goulet d’étranglement très important pour les équipes qui travaillent selon les méthodes agiles, et le provisionnement automatisé accélère encore la vitesse au point où les développeurs peuvent obtenir les ressources nécessaires en quelques minutes.
- Microservices: une architecture en microservices se compose d’unités aux liens souples et à la fonctionnalité finie, qui forment ensemble un système complet. Les systèmes et les applications de grande envergure sont plus faciles à développer et modifier lorsqu’ils sont composés de ces modules réutilisables à une seule fonction. Cette approche en composants indépendants permet aux différentes équipes DevOps de déployer des mises à jour avec moins de dépendances : elles peuvent ainsi agir plus rapidement, en réduisant le risque qu’une modification ne crée un problème. Dans leur ouvrage « DevOps: A Software Architect’s Perspective » (DevOps : la perspective d’un architecte logiciel), les auteurs Len Bass, Ingo Weber et Liming Zhu observent que « les architectures en microservices sont conçues pour résoudre une grande partie des problèmes qui ont motivé l’apparition du DevOps ».
L’architecture d’une organisation DevOps va employer le cloud, la virtualisation et les microservices. Elle cherche également à optimiser l’automatisation des tests, la supervision et les pratiques de sécurité pour appuyer les workflows DevOps. De façon générale, l’automatisation est un élément clé dans la mise en place d’un processus DevOps et, tout comme on constate un biais « priorité au cloud », on peut aussi parler de biais « automatisez tout ». Ces biais, qui sont aussi des bonnes pratiques, vont permettre de façonner l’architecture ’d’un processus DevOps.
Quel est le rôle du cloud dans l'approche DevOps ?
Le cloud computing est un moteur essentiel de la culture DevOps. La vitesse, l’échelle et l’efficacité du cloud permettent aux équipes agiles et DevOps d’accroître la rapidité et la qualité de leur travail. Les outils SaaS (logiciel en tant que service) apportent à la fois efficacité et économie aux équipes logicielles, et le logiciel en tant que service est en lui-même un exemple d’itération constante nécessitant impérativement une approche DevOps.
Vous ne mettrez sans doute pas toutes les applications dans le cloud, mais une bonne pratique de mise en œuvre de l’automatisation DevOps consiste à penser au cloud en priorité pour chaque nouvelle application. La question à poser lors de la planification d’une nouvelle application ou d’un nouveau service n’est pas « Devrions-nous le baser dans le cloud ? » mais « Avons-nous une raison de ne pas le mettre dans le cloud ? ». Il y aura parfois de bonnes raisons, pour des questions de sécurité et de réglementation, ou à cause de votre infrastructure globale, mais le cloud doit être pensé comme l’option par défaut d’un processus DevOps, pas un ajout après coup.
C'est quoi le DevSecOps ?
Le DevSecOps intègre les pratiques de sécurité dans le processus DevOps afin que chacun assume une part de la responsabilité de la sécurité au lieu de se contenter de transmettre le code à une équipe de sécurité distincte en fin de processus. Le DevSecOps cherche à livrer plus rapidement les logiciels en réduisant les défauts en fin de cycle ainsi que les corrections.
De façon générale, l'approche DevSecOps repose sur trois principes fondamentaux :
- Introduire la réflexion sur la sécurité au plus tôt dans le processus de développement.
- Faire de la réflexion sur la sécurité une responsabilité centrale du développement, et non la seule préoccupation d’une équipe distincte.
- Automatiser les processus de sécurité pour maintenir l’efficacité du flow DevOps.
Un Manifeste des DevSecOps, publié en 2012, définit en détail les principes de cette approche.
Quels exemples de bonnes pratiques du DevOps
Les bonnes pratiques du DevOps reposent sur la culture et décrivent une approche à la fois collaborative, flexible et axée sur l’efficacité, l’agilité et la création d’une valeur finale. Toutefois, il n’existe pas de recueil définitif de règles ou de bonnes pratiques pour mettre cette large philosophie en action. Les bonnes pratiques du DevOps et leur valeur varient selon le secteur, et les besoins d’un développeur de logiciel ne sont pas ceux de ses homologues de la distribution, de la fabrication, de la santé, des services financiers, etc.
Damon Edwards et John Willis, qui ont très tôt défendu la méthode DevOps, ont créé l’acronyme CAMS pour résumer les principes clés de développement. CAMS signifie culture, automatisation, mesure et partage (sharing).
D’autre part, l’Association des compétences agiles en DevOps met en avant six principes résumés ci-après :
- Action centrée sur le client : des boucles de rétroaction courtes pour comprendre et incorporer la perspective des clients.
- Créer en pensant au résultat final : ce principe encourage les entreprises à penser non pas en fonction de rôles individuels strictement définis, mais plutôt à envisager la façon dont l’organisation, dans son ensemble, crée des produits informatiques pour des clients internes ou externes.
- Responsabilité de bout en bout : au lieu de limiter la responsabilité de chaque membre de l’équipe à son propre rôle (en dédouanant les développeurs de toute responsabilité dans les problèmes d’infrastructure et les équipes d’exploitation, de toute influence sur la qualité du code), l'approche DevOps cherche à éliminer les silos et à faire de la réussite finale l’objectif et la responsabilité de toute l’équipe.
- Équipes autonomes interfonctionnelles : pour chaque « produit » IT, l’équipe doit disposer de toutes les compétences et assumer la responsabilité de l’aboutissement du produit, de l’idée à la disponibilité, ainsi que celle des cycles d’amélioration jusqu’au retrait du produit.
- Amélioration permanente : les équipes DevOps cherchent sans cesse à améliorer la vitesse et la qualité et à éliminer les pertes.
- Automatisez tout ce que vous pouvez : pour travailler plus rapidement, de façon plus efficace et productive, il est indispensable de s’appuyer autant que possible sur l’automatisation DevOps des équipes IT, afin de donner aux membres de l’équipe le temps de se consacrer à des tâches plus rentables et de réduire les opportunités d’erreur humaine.
Quels sont les outils du DevOps ?
Les outils DevOps aident les entreprises à mettre en œuvre les principes du DevOps en facilitant la gestion du développement du code, des tests et de l’infrastructure. L’approche DevOps concerne avant tout la culture de création et de livraison des produits logiciels (voir la section « Pour bien démarrer » plus bas), mais les outils d’automatisation et autres produits sont indispensables pour donner vie à cette évolution culturelle.
Il existe de nombreux outils spécialement conçus pour faciliter la mise en pratique de la culture DevOps. Ces outils font du contrôle de code source, de la gestion des configurations et des publications, de la supervision et bien d’autres choses encore.
Quel est le meilleur outil DevOps ?
Les meilleurs outils DevOps sont ceux qui servent les processus et les personnes qui forment votre culture DevOps. Le DevOps n'est pas un produit que l’on peut acheter et implémenter avant d’annoncer : « C’est bon, nous avons du DevOps ». Alex Honor, technologue DevOps, a publié un article aux premiers temps du DevOps, intitulé « D’abord les personnes, puis les processus, et enfin les outils », cristallisant l’accent mis par le mouvement sur la culture, qui prime sur l’équipement.
Comment prendre un bon départ avec la méthode DevOps ?
Pour bien démarrer avec la mise en place d’un processus DevOps, commencez par analyser votre culture actuelle. Identifiez les silos et les goulets d’étranglement qui ralentissent le développement, le déploiement et la rétroaction, et empêchent ainsi les itérations constantes, afin de repérer les domaines d’amélioration.
Andi Mann, auteur et ambassadeur technologique en chef chez Splunk, recommande aux infrastructures débutantes en DevOps de « déterminer votre parcours DevOps en fonction des spécificités de votre organisation, en veillant à franchir des étapes cruciales qui sont des indicateurs clés de votre réussite ». Quelques principes directeurs : supprimez les frictions et éliminez les goulets d’étranglement. Acceptez l’échec (et tirez-en des enseignements). Mesurez. Évoluez continuellement.
Le rapport État du DevOps 2018 publié par Puppet, leader des logiciels DevOps, et Splunk, divise l’évolution de la mise en pratique de l’approche DevOps en cinq grandes étapes. Il mesure les progrès accomplis selon le modèle CAMS (culture, automatisation, mesure et partage). Le rapport a identifié cinq pratiques fondamentales, essentielles pour l’adoption et le succès du DevOps :
- la supervision et les alertes sont configurables par l’équipe qui gère le service ;
- les motifs de déploiement sont réutilisés pour élaborer des applications et des services ;
- Les motifs de test sont réutilisés pour élaborer des applications et des services ;
- Les équipes apportent des améliorations aux outils fournis par d’autres équipes ;
Quels sont les KPI de la méthode DevOps ?
Plusieurs KPI revêtent une importance stratégique :
- Fréquence des déploiements : en visant des déploiements plus petits et plus fréquents.
- Fréquence des échecs de déploiement : en visant une réduction.
- Fonctionnalités publiées par trimestre : l’indicateur n’est pas nécessairement trimestriel, mais c’est l’échéance la plus souvent utilisée par les décideurs métier.
- Temps moyen de découverte (MTTD) : quand un problème survient, combien de temps faut-il pour le détecter ?
- Temps moyen de rétablissement (MTTR) : quand un problème survient, combien de temps faut-il pour le corriger ?
- Délai moyen de production (MLT) : combien de temps faut-il, en moyenne, pour que du code soit implémenté, à partir du moment où il a été demandé ?
- Disponibilité : suivez la disponibilité, en tenant compte à la fois des interruptions de maintenance planifiées et des coupures imprévues.
- Taux de défauts non détectés : combien de défauts parviennent jusqu’en production par rapport au nombre de défauts détectés par les équipes QA ?
- Performance des applications : quelles sont les performances de l’application après une modification, par comparaison à avant ?
Une fois que vous avez identifié vos points d’achoppement et que vous savez comment mesurer vos progrès, vous pouvez commencer à refaçonner votre culture et la diriger vers une approche DevOps. Commencez par supprimer les silos qui isolent les développeurs, les testeurs, les équipes d’exploitation et les analystes de sécurité. Invitez les analystes métier dans les discussions. Commencez à expliquer à toutes les personnes concernées que l’objectif n’est pas seulement de vider leur liste de tâches, mais aussi de partager la responsabilité de la vitesse et de la qualité de la création et de la publication des logiciels. Combinez des opportunités de formation informelles à des modifications dans les processus et l’infrastructure.
Enfin, il est crucial de garder à l’esprit que l’approche DevOps n’atteint pas la perfection en six mois, ni même un an. Pour reprendre les termes de Jez Humble, grand promoteur de la méthode DevOps, « le DevOps n’est pas un but mais un processus sans fin d’amélioration permanente ».
Quel avenir pour le DevOps ?
La méthode DevOps n’est pas un effet de mode et elle devient de moins en moins facultative. L’idée « d’aligner l’IT sur le métier » circule depuis plus de dix ans dans les conseils de direction et se répand dans toute la pyramide hiérarchique. La culture DevOps et ses pratiques constituent une approche établie pour délivrer une IT de meilleure qualité, plus rapidement. Si les grandes entreprises « licornes » comme Netflix, LinkedIn, Facebook, Amazon et Google ont connu un succès spectaculaire avec le DevOps, cette approche se banalise également dans les entreprises plus traditionnelles./p>
Il n’y a pas aujourd’hui d’entreprise qui ne s’efforce de devenir plus réactive face aux marchés. Pas un organisme de service public qui n’essaie d’améliorer ses services. Face aux attentes toujours plus grandes des clients et à la prolifération des données, l’IT ne peut rester immobile. Et à l’heure actuelle, il n’existe rien de plus dynamique que la mise en place d’une culture DevOps durable.
