Le DevOps accélère la distribution des logiciels de meilleure qualité en combinant et en automatisant le travail des équipes de développement logiciel et des opérations informatiques.
Par définition, le DevOps décrit un processus de développement logiciel et un changement de culture organisationnel qui accélère la distribution de logiciels de meilleure qualité en automatisant et en intégrant le travail des équipes de développement et des opérations informatiques, deux groupes qui, traditionnellement, travaillaient séparément ou de manière isolée.
Dans la pratique, les meilleurs processus et cultures DevOps vont au-delà du développement et des opérations pour intégrer, dans le cycle de vie du développement logiciel, les contributions de toutes les parties prenantes de l'application, notamment l'ingénierie de la plateforme et de l'infrastructure, la sécurité, la conformité, la gouvernance, la gestion des risques, le secteur d'activité, les utilisateurs finaux et les clients.
Le DevOps représente l'état actuel de l'évolution des cycles de distribution des logiciels depuis plus de 20 ans, des publications de code géantes couvrant l'ensemble de l'application tous les mois, voire tous les ans, aux petites mises à jour fonctionnelles itératives publiées tous les jours ou plusieurs fois par jour.
En fin de compte, le DevOps vise à répondre à la demande croissante des utilisateurs de logiciels qui souhaitent bénéficier de nouvelles fonctionnalités toujours plus nombreuses et innovantes, ainsi que de performances et d'une disponibilité ininterrompues.
Peu avant l'année 2000, la plupart des logiciels étaient développés et mis à jour selon la méthodologie de cascade, une approche linéaire des projets de développement à grande échelle. Les équipes de développement logiciel passaient des mois à développer de grands blocs de nouveau code qui avaient un impact sur la plupart ou la totalité de l'application. Les modifications étaient si nombreuses qu'ils passaient encore plusieurs mois à intégrer ce nouveau code dans le code base.
Ensuite, les équipes chargées de l'assurance qualité (QA), de la sécurité et des opérations passaient encore des mois à tester le code. Il s'écoulait donc des mois, voire des années entre les éditions des logiciels, sans parler des correctifs ou des corrections de bogues significatifs entre ces éditions. Cette approche « big bang » de la livraison de fonctionnalités était souvent caractérisée par des plans de déploiement complexes et risqués, des verrouillages difficiles à programmer avec les systèmes en amont et en aval, et le personnel informatique devait prier pour que les exigences commerciales n'aient pas radicalement changé dans les mois précédant la mise en production.
Pour accélérer le développement et améliorer la qualité, les équipes de développement ont commencé à adopter des méthodologies de développement logiciel agiles, qui sont itératives plutôt que linéaires et se concentrent sur la réalisation de mises à jour plus petites et plus fréquentes du code base de l'application. Parmi ces méthodologies, les plus importantes sont l'intégration continue et la distribution continue, ou CI/CD. Avec la méthodologie CI/CD, des petits blocs de nouveau code sont fusionnés avec le code base toutes les semaines ou tous les quinze jours, puis sont automatiquement intégrés, testés et préparés pour être déployés dans l'environnement de production. La méthode agile a fait évoluer l'approche « big bang » en une série de « petits pas » qui ont également permis de fragmenter les risques.
Plus ces pratiques de développement agiles accélèrent le développement et la livraison des logiciels, plus elles exposent les opérations informatiques encore isolées (approvisionnement du système, configuration, tests d'acceptation, gestion, surveillance) comme le prochain goulot d'étranglement dans le cycle de vie de la livraison des logiciels.
Le DevOps est donc né de l'agilité. Il a apporté de nouveaux processus et outils qui étendent l'itération et l'automatisation continues de CI/CD au reste du cycle de vie de la distribution de logiciels. En outre, il a établi une collaboration étroite entre le développement et les opérations à chaque étape du processus.
Le cycle de vie DevOps (parfois appelé « pipeline de distribution continue », lorsqu'il est présenté de manière linéaire) est une série de processus de développement itératifs et automatisés, ou flux, exécutés dans le cadre d'un cycle de développement plus large, automatisé et itératif, visant à optimiser la distribution rapide de logiciels de haute qualité. Le nom et le nombre de flux peuvent varier selon la personne à qui vous demandez, mais ils se résument généralement à ces six éléments :
Trois autres flux de travail continus importants se produisent entre ces flux :
Tests continus : Les cycles de vie classiques du DevOps comprennent une phase de test discrète qui intervient entre l'intégration et le déploiement. Cependant, le DevOps a progressé de telle sorte que certains éléments de test peuvent se produire dans la planification (développement axé sur le comportement), le développement (tests unitaires, tests contractuels), l’intégration (analyses de code statique, analyses CVE, analyse des erreurs), le déploiement (tests de vérification de génération, tests de pénétration, tests de configuration), les opérations (tests de chaos, tests de conformité) et l’apprentissage (tests A/B). Les tests offrent un moyen efficace d'identifier les risques et les vulnérabilités et donnent aux services informatiques la possibilité d'accepter, d'atténuer ou de corriger les risques.
Sécurité : Alors que les méthodologies en cascade et les implémentations agiles « ajoutent » des flux de sécurité après la distribution ou le déploiement, le DevOps s'efforce d'intégrer la sécurité dès le début (planification), lorsque les problèmes de sécurité sont les plus faciles et les moins coûteux à résoudre, et de manière continue pendant le reste du cycle de développement. Cette approche de la sécurité est connue sous le nom de déplacement vers la gauche (ce qui est plus facile à comprendre si vous regardez la figure 1). Certaines organisations ont eu moins de succès que d'autres dans cette démarche, ce qui a donné naissance au DevSecOps (voir ci-dessous).
Conformité. Il est également préférable de traiter la conformité réglementaire (gouvernance et risque) en amont et pendant le cycle de développement. Les secteurs réglementés sont souvent tenus de fournir un certain niveau d'observabilité, de traçabilité et d'accès à la manière dont les fonctionnalités sont fournies et gérées dans leur environnement d'exploitation. Cela nécessite de planifier, de développer, de tester et d'appliquer des politiques dans le pipeline de distribution continue et dans l'environnement d'exécution. L'auditabilité des mesures de conformité est extrêmement importante pour prouver la conformité à des auditeurs tiers.
Il est généralement admis que les méthodes de DevOps ne peuvent fonctionner sans un engagement envers la culture DevOps, qui peut être résumée comme une approche organisationnelle et technique différente du développement logiciel.
Au niveau organisationnel, le DevOps exige une communication, une collaboration et un partage des responsabilités permanents entre toutes les parties prenantes de la distribution des logiciels, les équipes de développement logiciel et des opérations informatiques, mais aussi les équipes chargées de la sécurité, de la conformité, de la gouvernance, des risques et des secteurs d'activité, afin d'innover rapidement et en permanence, et d'intégrer la qualité dans les logiciels dès le début.
Dans la plupart des cas, la meilleure façon d'y parvenir est d'éliminer ces silos et de les réorganiser en équipes DevOps interfonctionnelles et autonomes qui peuvent travailler sur des projets de code du début à la fin, de la planification au commentaire en retour, sans avoir à passer le relais à d'autres équipes ou à attendre leur approbation. Dans le contexte du développement agile, le partage des responsabilités et la collaboration sont la base qui permet de se concentrer sur un produit commun et d'obtenir un résultat de qualité.
Sur le plan technique, le DevOps exige un engagement en faveur de l'automatisation, qui permet de faire avancer les projets au sein des flux et entre les flux, et en faveur du retour d'information et de la mesure qui permettent aux équipes d'accélérer continuellement les cycles et d'améliorer la qualité et les performances des logiciels.
Pour répondre aux exigences du DevOps et de la culture DevOps, il est indispensable de disposer d'outils qui prennent en charge la collaboration asynchrone, intègrent de manière transparente les flux de travail DevOps et automatisent autant que possible l'ensemble du cycle de vie DevOps. Les catégories d'outils DevOps sont les suivantes :
L'approche cloud native consiste à créer des applications qui tirent parti des technologies fondamentales du cloud computing. L'objectif de l'approche cloud native est de permettre un développement, un déploiement, une gestion et une performance cohérents et optimaux des applications dans les environnements publics, privés et multiclouds.
Aujourd'hui, les applications cloud natives sont généralement
À bien des égards, le développement cloud natif et DevOps sont faits l'un pour l'autre.
Par exemple, le développement et la mise à jour de microservices, c'est-à-dire la distribution itérative de petites unités de code dans un code base, sont parfaitement adaptés aux cycles de gestion et de publication rapides du DevOps. En outre, il serait difficile de gérer la complexité d'une architecture de microservices sans déploiement et opération DevOps. Une récente enquête d'IBM auprès de développeurs et de responsables informatiques révèle que 78 % des utilisateurs actuels de microservices prévoient d'augmenter le temps, le budget et les efforts qu'ils ont investis dans cette architecture, et que 56 % des non utilisateurs sont susceptibles d'adopter les microservices dans les deux prochaines années.
En empaquetant et en fixant de manière permanente toutes les dépendances du système d'exploitation, les conteneurs permettent des cycles de CI/CD et de déploiement rapides, car toute l'intégration, les tests et le déploiement ont lieu dans le même environnement. Par ailleurs, l'orchestration Kubernetes exécute les mêmes tâches de configuration continue pour les applications conteneurisées qu'Ansible, Puppet et Chef pour les applications non conteneurisées.
La plupart des grands fournisseurs de cloud, dont AWS, Google, Microsoft Azure et IBM Cloud, proposent une solution de pipeline DevOps géré.
Le DevSecOps est un DevOps qui intègre et automatise en permanence la sécurité tout au long du cycle de vie DevOps, du début à la fin, de la planification au retour d'information, puis de nouveau à la planification.
On peut aussi dire que le DevSecOps est ce que le DevOps é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 du DevOps étaient l'intégration de l'expertise en sécurité aux équipes interfonctionnelles (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 été perçue comme l'équipe du « non » et comme un goulot d'étranglement coûteux dans de nombreuses pratiques DevOps.
Le DevSecOps est apparu comme un effort spécifique pour intégrer et automatiser la sécurité comme prévu à l'origine. Dans le cadre du DevSecOps, la sécurité est un citoyen de « première classe » et une partie prenante au même titre que le développement et les opérations, et intègre la sécurité au processus de développement en mettant l'accent sur le produit.
Regardez « Qu'est-ce que le DevSecOps ? » pour en savoir plus sur les principes, les avantages et les cas d'utilisation du DevSecOps.
L'ingénierie de la fiabilité des sites (SRE) utilise des techniques d'ingénierie logicielle pour automatiser les tâches de l'équipe des opérations informatiques, par exemple, la gestion des systèmes de production, la gestion des modifications, la réponse aux incidents, voire la réponse aux situations d'urgence, qui, autrement, pourraient être effectuées manuellement par les administrateurs du système. Elle vise à transformer l'administrateur système classique en ingénieur.
Son objectif ultime est similaire à celui du DevOps, mais plus spécifique : l'ingénierie de la fiabilité des sites vise à équilibrer le désir d'une organisation de développer rapidement des applications avec la nécessité de respecter les niveaux de performance et de disponibilité spécifiés dans les accords sur les niveaux de service (SLA) avec les clients et les utilisateurs finaux.
Les ingénieurs de la fiabilité des sites parviennent à cet équilibre en déterminant un niveau acceptable de risque opérationnel causé par les applications, appelé « budget d'erreurs », et en automatisant les opérations pour atteindre ce niveau.
Au sein d'une équipe DevOps interfonctionnelle, l'ingénierie de la fiabilité des sites peut servir de pont entre le développement et les opérations, en fournissant les mesures et l'automatisation dont l'équipe a besoin pour faire passer les modifications de code et les nouvelles fonctions dans le pipeline DevOps aussi rapidement que possible, sans « rompre » les conditions des accords sur les niveaux de service de l'organisation.
Explorez le portefeuille complet de fonctionnalités IBM® d’intégration, d’IA et d’automatisation qui génèrent le retour sur investissement dont vous avez besoin.
Découvrez comment réaliser des opérations informatiques prédictives avec IBM Cloud Pak for Watson AIOps.
Un logiciel DevOps puissant pour créer, déployer et gérer des applications cloud natives hautement sécurisées sur plusieurs appareils, environnements et clouds