DevOps

menu icon

DevOps

DevOps accélère la livraison de logiciels de qualité optimale en combinant et en automatisant le travail des équipes de développement de logiciels et de celles des opérations IT.

Qu’est-ce que DevOps ?

Par définition, DevOps correspond à un processus de développement de logiciels et à un changement de culture organisationnelle qui accélère la livraison de logiciels de meilleure qualité, en automatisant et en intégrant les travaux des équipes du développement et ceux des opérations IT. Jusqu'à présent, ces équipes travaillaient séparément, ou restaient cloisonnées dans des silos.

Dans la pratique, les meilleurs processus et cultures DevOps vont au-delà du développement et des opérations pour intégrer au cycle de vie de développement de logiciels les apports de toutes les parties prenantes concernées par les applications, notamment l'ingénierie de plateforme et d'infrastructures, la sécurité, la conformité, la gouvernance, la gestion des risques, les secteurs d'activité, les utilisateurs finaux et les clients.

DevOps représente l'état actuel de l'évolution des cycles de livraison de logiciels depuis plus de 20 ans. À l'époque où des versions de code gigantesques, à l'échelle de toute l'application, étaient publiées tous les mois ou même avec plusieurs années d'écart, a succédé celles de fonctionnalités itératives plus modestes, ou celle des mises à jour fonctionnelles publiées tous les jours ou plusieurs fois par jour.

En définitive, DevOps consiste à satisfaire les utilisateurs de logiciels, de plus en plus demandeurs de fonctionnalités innovantes et fréquentes, ainsi que de performances et de disponibilité ininterrompues.

Comment est né DevOps

Un peu avant 2000, la plupart des logiciels étaient développés et mis à jour à l'aide de la méthodologie de la cascade, une approche linéaire des projets de développement à grande échelle. Les équipes de développement de logiciels passaient des mois entiers à développer de grandes quantités de nouveau code qui se répercutaient sur la quasi-totalité de l'application. Comme les changements étaient très importants, les équipes consacraient plusieurs mois à intégrer ce nouveau code dans la base de code.

Ensuite, les équipes d'assurance qualité, de sécurité et des opérations avaient besoin de plusieurs mois supplémentaires pour tester le code. Il en résultait des mois, voire des années, entre les versions des logiciels, et souvent plusieurs correctifs importants ou des corrections de bogues intervenaient entre les versions. En outre, cette approche de type "big bang" de la livraison de fonctionnalités se caractérisait souvent par des plans de déploiement complexes et risqués, par des interconnexions difficiles à programmer avec des systèmes en amont et en aval, tandis que l'IT croisait les doigts pour que les besoins de l'entreprise n'aient pas changé radicalement dans les mois précédant le lancement en production.

Pour accélérer le développement et améliorer la qualité, les équipes de développement ont alors commencé à adopter des méthodologies agiles de développement logiciel. Ces méthodologies sont itératives et non linéaires, et mettent l'accent sur des mises à jour plus modestes et plus fréquentes de la base de code des applications. Les principales méthodologies sont l'intégration continue et la distribution continue, désignées par l'acronyme CI/CD. Avec la méthodologie CI/CD, des blocs plus petits de nouveau code sont fusionnés avec la base de code toutes les semaines ou tous les quinze jours, puis sont automatiquement intégrés, testés et préparés en vue du déploiement dans l'environnement de production. La méthodologie Agile a fait évoluer l'approche de type « big bang » en une série de « petites explosions » qui ont aussi permis de compartimenter les risques.

En démontrant leur efficacité pour accélérer le développement et la livraison de logiciels, ces pratiques de développement agile ont révélé que les opérations IT restées prisonnières de silos (application des accès système, configuration, test d'acceptation, gestion, surveillance) constituaient le nouveau goulot d'étranglement dans le cycle de vie de la distribution de logiciels.

DevOps tire ses origines des méthodes agiles. Il a apporté de nouveaux processus et outils qui étendent l'itération continue et l'automatisation CI/CD au reste du cycle de vie de la distribution de logiciels. Il a mis en œuvre une collaboration étroite entre le développement et les opérations à chaque étape du processus.

Comment fonctionne DevOps : Cycle de vie DevOps

Graphique représentant le cycle de vie DevOps

Figure 1 : Le cycle de vie DevOps

Le cycle de vie DevOps (parfois appelé pipeline de distribution continue lorsqu'il est représenté de manière linéaire) est une série de processus de développement itératifs et automatisés, ou de flux de travaux, exécutés au sein d'un cycle de vie de plus grande ampleur, automatisé et itératif, conçu pour optimiser la livraison rapide de logiciels haute qualité. Le nom et le nombre des flux de travaux peuvent varier, mais ils se résument en général aux six flux suivants :

  • Planification (ou idéation). Dans ce flux de travaux, les équipes définissent la portée et les fonctionnalités de l'édition suivante, en s'appuyant sur des commentaires d'utilisateurs finaux et sur des études de cas priorisés, ainsi que sur les contributions de toutes les parties prenantes internes. L'objectif de l'étape de planification est d'optimiser la valeur métier du produit en générant un backlog (journal) des fonctions en attente qui, une fois livrées, permettent d'obtenir le résultat recherché, générateur de valeur.
  • Développement. Il s'agit de l'étape de programmation au cours de laquelle les développeurs testent, codent et créent des fonctions nouvelles et améliorées, basées sur des témoignages d'utilisateur et des éléments de travail du backlog. Une combinaison de pratiques telles que le développement piloté par test (TDD), la programmation par paires et les évaluations de code par des homologues, entre autres, est courante. Les développeurs utilisent souvent leurs postes de travail locaux pour exécuter la « boucle interne » de l'écriture et du test du code avant de l'envoyer au pipeline de distribution continue.
  • L'intégration (ou génération, ou encore intégration continue et distribution continue (CI/CD). Comme indiqué précédemment, dans ce flux de travaux le nouveau code est intégré à la base de code existante, puis testé et intégré dans un exécutable en vue du déploiement. Les activités d'automatisation courantes incluent la fusion des changements de code dans une copie « maître », la vérification de ce code à partir d'un référentiel de code source, puis l'automatisation de la compilation, du test unitaire et du conditionnement dans un exécutable. La meilleure pratique consiste à stocker le résultat de la phase CI (intégration continue) dans un référentiel binaire, en vue de la phase suivante.
  • Le déploiement (souvent appelé déploiement continu). Ici, la sortie de la génération d'exécution (à partir de l'intégration) est déployée dans un environnement d'exécution, en général un environnement de développement dans lequel les tests d'exécution sont exécutés afin de vérifier la qualité, la conformité et la sécurité. Si des erreurs ou des défauts sont trouvés, les développeurs ont la possibilité d'intercepter et de résoudre tous les problèmes avant que les utilisateurs finaux ne les remarquent. Il existe en général des environnements pour le développement, le test et la production, chaque environnement nécessitant progressivement des seuils de qualité plus stricts. Une bonne pratique pour le déploiement dans un environnement de production consiste généralement à effectuer d'abord un déploiement concernant un sous-ensemble d'utilisateurs finaux, avant de l'étendre à tous les utilisateurs une fois la stabilité établie.
  • Opérations. La livraison des fonctions à un environnement de production est une étape appelée « Jour 1 ». Lorsque les fonctions s'exécutent en production, les opérations dite du « Jour 2 » commencent. La surveillance des performances, du comportement et de la disponibilité des fonctions garantit que les fonctions apportent une valeur ajoutée aux utilisateurs finaux. Les opérations permettent aux fonctions d'opérer de façon fluide et d'éviter les interruptions de service, en s'assurant que le réseau, le stockage, la plateforme, le traitement et la stratégie de sécurité sont tous en bon état. En cas d'anomalie, l'équipe de opérations identifie les incidents, avertit le personnel approprié, détermine les problèmes et fait appliquer les correctifs.
  • L'apprentissage (parfois appelé rétroaction continue). Il s'agit de la collecte des commentaires des utilisateurs finaux et des clients concernant les fonctions, la fonctionnalité, les performances et la valeur métier, commentaires qui sont ensuite intégrés à la phase de planification en vue d'apporter des améliorations à l'édition suivante et de créer de nouvelles fonctionnalités. Sont également inclus les éléments de l'apprentissage et du backlog des activités des opérations pouvant permettre aux développeurs d'éviter proactivement tout incident antérieur susceptible de se reproduire à l'avenir. C'est à ce stade que se produit le renvoi à la phase de planification et que l'amélioration continue se poursuit.

Trois autres flux de travaux continus importants interviennent entre ces flux de travaux :

Test continu : Les cycles de vie DevOps classiques incluent une phase de test discrète qui se produit entre l'intégration et le déploiement. Toutefois, DevOps a progressé de manière à ce que certains éléments de test puissent intervenir au cours de la planification (BDD - programmation pilotée par le comportement), du développement (test unitaire, test de contrat), de l'intégration (analyses de code statique, analyses CVE, linting), du déploiement (test de fumée, test de pénétration, test de configuration), des opérations (test du chaos, test de conformité) et de l'apprentissage (test A/B). Les tests constituent une puissante forme d'identification des risques et de la vulnérabilité et permettent à l'équipe IT d'accepter, d'atténuer ou de corriger les risques.

Sécurité : Alors que les méthodologies en cascade et les implémentations ajoutent les flux de travaux de sécurité après la livraison ou le déploiement, DevOps s'efforce d'intégrer la sécurité dès le départ (Planification) lorsque les problèmes de sécurité sont plus simples et moins coûteux à traiter, et ce, de façon continue tout au long du cycle de développement. Cette approche de la sécurité est appelée approche « shift left » (littéralement, déplacement vers la gauche), ce que montre bien la Figure 1. Certaines enteprises ont eu moins de succès que d'autres avec cette approche, ce qui a conduit à l'essor de DevSecOps (voir ci-dessous).

La conformité. Il est préférable de prendre en compte la conformité aux réglementations (gouvernance et risque) assez tôt et tout au long du cycle de développement. Les industries réglementées ont souvent l'obligation de fournir un certain niveau d'observabilité, de traçabilité et d'accès à la façon dont les fonctions sont livrées et gérées dans leur environnement opérationnel d'exécution. Cela nécessite la planification, le développement, le test et l'application des règles dans le pipeline de distribution continue et dans l'environnement d'exécution. La vérification des mesures de conformité est extrêmement importante pour prouver la conformité aux exigences d'auditeurs tiers.

Culture DevOps

Il est généralement admis que les méthodes DevOps ne peuvent pas fonctionner sans une volonté d'adopter la culture DevOps, qui peut être résumée comme une approche organisationnelle et technique différente du développement de logiciels.

Au niveau organisationnel, DevOps exige une communication continue, une collaboration et une responsabilité partagée entre tous les intervenants de la livraison de logiciels : équipes du développement logiciel et des opérations IT bien évidemment, mais aussi équipes de sécurité, de conformité, de gouvernance, de risque et de secteur d’activité. Toutes ces équipes doivent innover rapidement et continuellement, et intégrer le facteur qualité dans les logiciels dès le début.

Dans la plupart des cas, la meilleure façon d'y arriver est de supprimer ces silos et de les réorganiser en équipes DevOps autonomes et pluridisciplinaires capables de travailler sur des projets de code de A à Z, de la planification jusqu'à la rétroaction, sans transferts de tâches à d'autres équipes ou sans attendre leurs approbations. Replacées dans un contexte de développement agile, la responsabilité partagée et la collaboration sont les bases permettant de se focaliser en commun sur le produit, avec à la clé une résultat porteur de valeur.

Au niveau technique, DevOps nécessite de faire le choix de l'automatisation, qui permet de faire progresser les projets à l'intérieur et entre les flux de travaux. Il implique aussi d’accorder une grande importance à la rétroaction et aux mesures qui permettent aux équipes d'accélérer continuellement les cycles et d'améliorer la qualité et les performances des logiciels.

Outils DevOps : Création d'une chaîne d'outils DevOps

Les exigences de DevOps et de la culture DevOps donnent toute leur importance aux outils capables de prendre en charge la collaboration asynchrone, d’intégrer harmonieusement les flux de travaux DevOps et d'automatiser le cycle de vie de DevOps dans la mesure du possible. Les catégories d'outils DevOps incluent :

  • Outils de gestion de projet - Outils permettant aux équipes de générer un backlog de témoignages d'utilisateur (exigences) formant des projets de codage, de les décomposer en tâches plus petites et d'effectuer le suivi des tâches jusqu'à leur achèvement. Beaucoup prennent en charge des pratiques agiles de gestion de projet telles que Scrum, Lean et Kanban, apportées à DevOps par les développeurs. Les options open source les plus répandues sont GitHub Issues et Jira.
  • Référentiels de code source collaboratif - Environnements de codage contrôlés par la version, qui permettent à plusieurs développeurs de travailler sur la même base de code. Les référentiels de codes doivent s'intégrer aux outils CI/CD, ainsi qu'aux outils de test et de sécurité. De cette façon, une fois validé dans le référentiel, le code peut passer automatiquement à l'étape suivante. Les référentiels de code open source sont GiHub et GitLab.
  • Pipelines CI/CD - Outils permettant d'automatiser l'extraction de code, la génération, le test et le déploiement. Jenkins est l'outil open source le plus populaire de cette catégorie. De nombreuses alternatives auparavant open source, telles que CircleCI, ne sont désormais disponibles qu'en versions commerciales. En ce qui concerne les outils de déploiement continu (CD), Spinnaker est à mi-chemin entre l'application et l'infrastructure sous forme de couches de code. ArgoCD est une autre solution open source répandue pour le CI/CD natif Kubernetes.
  • Structures d'automatisation de test - Il s'agit d'outils logiciels, de bibliothèques et de meilleures pratiques d'automatisation des test unitaires, des tests de contrats, des tests fonctionnels, des tests de performances, des tests de facilité d'utilisation, des tests de pénétration et des tests de sécurité. Les meilleurs de ces outils prennent en charge plusieurs langages. Certains utilisent l'intelligence artificielle (IA) pour reconfigurer automatiquement les tests en réponse aux changements de code. La portée des outils et des structures de test est très étendue. Les structures d'automatisation des tests open source populaires sont Selenium, Appium, Katalon, Robot Framework et Serenity (anciennement Thucydides).
  • Outils de gestion de la configuration (infrastructure sous forme de code) - Ces éléments permettent aux ingénieurs DevOps, en exécutant un script, de configurer et mettre à disposition une infrastructure entièrement versionnée et documentée. Les options open source sont Ansible (Red Hat), Chef, Puppet et Terraform. Kubernetes assure la même fonction pour les applications conteneurisées (voir« DevOps et le développement natif cloud » ci-après).
  • Outils de surveillance - Ils aident les équipes DevOps à identifier et résoudre les problèmes du système. Ils se chargent aussi de collecter et d'analyser les données en temps réel pour révéler l'impact des changements du code sur les performances de l'application. Les outils de surveillance open source sont Datadog, Nagios, Prometheus et Splunk.
  • Outils de rétroaction continue - Ces outils permettent de recueillir les commentaires des utilisateurs, par le biais de la cartographie d'activité (enregistrement des actions des utilisateurs à l'écran), d'enquêtes, ou de l'émission de tickets d'incidents en libre-service.

DevOps et le développement natif cloud

Le développement natif cloud est une approche de création des applications qui tire parti des technologies de base du cloud computing. Le but du « natif cloud » est de permettre un développement, un déploiement, une gestion et une performance d'applications cohérents et optimaux dans les environnements publics, privés et multicloud.

Aujourd'hui, les applications natives cloud sont généralement :

  • créées à l'aide de microservices, des composants à couplage lâche et déployables de manière indépendante, qui disposent de leur propre pile autonome et qui communiquent les uns avec les autres via les API REST, les flux d'événements ou les courtiers de messages.
  • déployées dans des conteneurs, unités de code exécutables contenant la totalité du code, les environnements d'exécution et les dépendances de système d'exploitation requis pour exécuter l'application. Pour la plupart des entreprises, les conteneurs sont synonymes de conteneurs Docker. Néanmoins, il existe d'autres types de conteneur.
  • exploitées à grande échelle à l'aide de Kubernetes, plateforme d'orchestration de conteneurs open source utilisée pour la planification et l'automatisation du déploiement, de la gestion et de la mise à l'échelle des applications conteneurisées.

À bien des égards, le développement natif cloud et DevOps forment un tandem parfait.

Par exemple, le développement et la mise à jour de microservices, c'est-à-dire la livraison itérative de petites unités de code à un code de base de petite taille, conviennent parfaitement aux cycles rapides de publication et de gestion de DevOps. Par ailleurs, il serait difficile de faire face à la complexité d'une architecture de microservices sans un déploiement et une exploitation DevOps. Une récente enquête réalisée par IBM auprès de développeurs et de responsables informatiques a révélé que 78 % des utilisateurs actuels de microservices s'attendent à voir augmenter le temps, l'argent et les efforts qu'ils ont investis dans l'architecture, et que 56 % des non-utilisateurs sont susceptibles d'adopter des microservices au cours des deux prochaines années. Pour explorer certains des avantages et des défis des microservices cités, utilisez l'outil interactif ci-dessous :

(Source : « Microservices in the enterprise 2021: Real benefits, worth the challenges »)

En conditionnant et en résolvant de façon permanente toutes les dépendances de système d'exploitation, les conteneurs permettent des cycles CI/CD et de déploiement rapides, car toutes les fonctions d'intégration, de test et de déploiement se produisent dans le même environnement. L'orchestration Kubernetes effectue les mêmes tâches de configuration continue pour les applications conteneurisées que celles effectuées par Ansible, Puppet et Chef pour les applications non conteneurisées.

Les principaux fournisseurs de cloud computing, notamment AWS, Google, Microsoft Azure et IBM Cloud, proposent une forme ou une autre de solution de pipeline DevOps gérée.

Qu'est-ce que DevSecOps ?

DevSecOps est une forme de DevOps qui intègre et automatise en continu la sécurité tout au long du cycle de vie DevOps, du début jusqu'à la fin, de la planification à la rétroaction puis pour revenir à la planification.

En d'autres termes, DevSecOps est DevOps tel qu'il était censé être dès le départ. Toutefois, deux des premiers défis importants (et qui sont restés pendant un certain temps insurmontables) liés à l'adoption de DevOps étaient l'intégration de l'expertise en sécurité aux équipes pluridisciplinaires (problème culturel), et l'implémentation de l'automatisation de la sécurité dans le cycle de vie DevOps (problème technique). La sécurité a fini par recevoir le sobriquet de « l'Équipe qui dit non à tout », et aussi par être perçue comme un goulet d'étranglement coûteux pour de nombreuses pratiques DevOps.

DevSecOps est apparu comme une initiative spécifique visant à intégrer et à automatiser la sécurité comme prévu à l'origine. Dans DevSecOps, la sécurité est considérée comme élément de même importance que le développement et les opérations. Son rôle est de sécuriser le processus de développement en se focalisant sur le produit.

Regardez « What is DevSecOps? » pour en savoir plus sur les principes, les avantages et les cas d'utilisation DevSecOps :

DevOps et l'ingénierie de la fiabilité du site (SRE)

L'ingénierie de la fiabilité du site (SRE) utilise des techniques d'ingénierie logicielle pour automatiser les tâches d'opérations IT, telles que la gestion du système de production, la gestion des changements, la réponse aux incidents, voire l'intervention en cas de situation d'urgence, qui pourraient sinon être exécutées manuellement par les administrateurs système. L'ingénierie de la fiabilité du site cherche à transformer l'administrateur système en ingénieur.

Son objectif ultime est semblable à celui de DevOps, mais il est plus spécifique : elle cherche à établir un équilibre entre, d'une part, l'objectif d'un développement rapide d'application, et d'autre part, l'obligation pour l'entreprise de respecter les spécifications de performance et de disponibilité des accords sur les niveaux de service (SLA) conclus avec les clients et les utilisateurs finaux.

Les ingénieurs en fiabilité du site atteignent cet équilibre en déterminant un niveau acceptable de risque opérationnel causé par les applications, appelé « budget d'erreur », et en automatisant les opérations pour atteindre ce niveau.

Dans une équipe DevOps pluridisciplinaire, l'ingénierie de la fiabilité du site peut servir de passerelle entre le développement et les opérations, en fournissant les métriques et l'automatisation dont l'équipe a besoin pour propager le plus rapidement possible les changements de code et les nouvelles fonctionnalités via le pipeline DevOps, sans enfreindre les conditions des SLA.

En savoir plus sur l'ingénierie de la fiabilité du site (SRE)

DevOps et IBM Cloud

DevOps exige une collaboration entre les différentes parties prenantes de l'entreprise, du développement et des intervenants pour livrer et exécuter rapidement des logiciels fiables. Les entreprises qui utilisent les outils et pratiques DevOps tout en transformant leur culture créent une puissante base de départ pour leur transformation numérique et pour la modernisation de leurs applications, alors même que l'automatisation devient de plus en plus nécessaire dans les opérations métier et IT.

Une transition vers une automatisation accrue doit commencer par des projets de petite taille, quantifiables et réussis, que vous pourrez ensuite mettre à l'échelle et optimiser pour d'autres processus et dans d'autres secteurs de votre entreprise.

En collaborant avec IBM, vous avez accès à des fonctions d'automatisation de l'IA, notamment des flux de travaux préconfigurés qui rendent plus intelligents tous les processus de services IT et permettent aux équipes de se consacrer aux problèmes IT les plus importants et d'accélérer l'innovation.

Pour aller plus loin :

Démarrez en créant un Compte IBM Cloud dès aujourd'hui.

IBM Cloud Pak for Watson AIOps utilise l'apprentissage automatique et la compréhension du langage naturel pour corréler en temps réel des données structurées et non structurées dans votre chaîne d'outils des opérations, découvrir les connaissances cachées et aider à identifier plus rapidement les causes premières. En supprimant le recours à de multiples tableaux de bord, Watson AIOps envoie les informations et les recommandations directement dans les flux de travaux de votre équipe pour accélérer la résolution des incidents.

À propos de l'auteur

Andrea C. Crawford est ingénieur émérite IBM, spécialiste du DevOps classique et moderne. Sa passion est d'aider les clients à transformer la livraison d'applications en apportant la modernisation aux personnes, aux processus et aux outils. Andrea aime, pour des raisons tactiques, s'adonner à des hobbies qui n'ont rien à voir avec son domaine, tels que le jardinage et la moto.

https://twitter.com/acmthinks (lien externe à IBM)

https://medium.com/@acmThinks (lien externe à IBM)