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 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. 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 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é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 continue et l'automatisation 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 :

• Planification (ou idéation). Dans ce flux, les équipes définissent les nouvelles fonctions et fonctionnalités de la prochaine version, en s'appuyant sur les commentaires des utilisateurs finaux et les études de cas prioritaires, 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 construisent des fonctionnalités nouvelles et améliorées, sur la base des histoires d'utilisateurs 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.
  
  
• Intégration (ou création ou CI/CD). Comme indiqué ci-dessus, dans ce flux de travail, le nouveau code est intégré dans le code base existant, puis testé et packagé en un exécutable pour être déployé. 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.
  
  
• Déploiement (généralement appelé déploiement continu). Le résultat de l'intégration est ici déployé dans un environnement d'exécution, généralement un environnement de développement où des tests d'exécution sont exécutés pour assurer 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. Si la distribution des fonctions vers un environnement de production est considérée comme le « jour 1 », alors une fois que les fonctionnalités sont en production, les opérations du « jour 2 » se produisent. La surveillance des performances, du comportement et de la disponibilité des fonctions garantit que les fonctions apportent une valeur ajoutée aux utilisateurs finaux. L'équipe des opérations s'assure que les fonctionnalités s'exécutent sans problème et qu'il n'y a pas d'interruption de service en veillant à ce que le réseau, le stockage, la plateforme, la capacité de calcul et la posture de sécurité soient tous en ordre. 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.
  
  
• Apprentissage (parfois appelé retour d'information continu). 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 moment-là que l'on passe de la phase de planification à la phase d'amélioration continue.

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. 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 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 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. 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 comprennent :

• Outils de gestion de projet : Des outils qui permettent aux équipes de constituer un backlog d'histoires d'utilisateurs (exigences) qui forment des projets de codage, de les décomposer en tâches plus petites et de suivre ces 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 : Des environnements de codage à contrôle de version qui permettent à plusieurs développeurs de travailler sur le même code base. 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  : Des outils qui automatisent la vérification, la création, les tests et le déploiement du code. Jenkins est l'outil open source le plus utilisé dans cette catégorie. Beaucoup d'alternatives auparavant open source, telles que CircleCI, sont désormais uniquement disponibles en version commerciale. 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.
  
  
• Cadres d'automatisation des tests  : Il s'agit d'outils logiciels, de bibliothèques et de recommandations pour automatiser les tests unitaires, contractuels, fonctionnels, de performance, d'utilisabilité, de pénétration et 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 fonction des modifications du 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 en tant que code)  : Ils permettent aux ingénieurs DevOps de configurer et de fournir une infrastructure versionnée et documentée en exécutant un script. Les options open source sont Ansible (Red Hat), Chef, Puppet et Terraform. Kubernetes exécute la même fonction pour les applications conteneurisées (voir « DevOps et le développement cloud natif » ci-dessous).
  
  
• Outils de surveillance : Ils aident les équipes DevOps à identifier et à résoudre les problèmes du système. Ils regroupent et analysent également les données en temps réel pour révéler l'impact des modifications sur les performances des applications. Les outils de surveillance open source sont Datadog, Nagios, Prometheus et Splunk.
  
  
• Outils de retour d'information continu  : Des outils qui permettent de recueillir les commentaires des utilisateurs, que ce soit par le biais de cartes de densité (enregistrement des actions des utilisateurs à l'écran), d'enquêtes ou de tickets en libre-service.

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 :

• créées à l'aide de microservices : composants faiblement couplés, déployables indépendamment, qui disposent de leur propre pile autonome et communiquent entre eux via des API REST, des flux d'événements ou des courtiers de messages.
  
  
• déployées dans des conteneurs : unités de code exécutables qui contiennent tout le code, les moteurs d'exécution et les dépendances du système d'exploitation nécessaires pour exécuter l'application. (Pour la plupart des organisations, le terme « conteneurs » est synonyme de conteneurs Docker, mais d'autres types de conteneurs existent).
  
  
• utilisées (à grande échelle) à l'aide de Kubernetes, une plateforme d'orchestration de conteneurs open source permettant de planifier et d'automatiser le déploiement, la gestion et la mise à l'échelle des applications conteneurisées.

À 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 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 é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. 

En savoir plus sur l'ingénierie de la fiabilité des sites