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 :

• 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 la phase de planification est de maximiser la valeur commerciale du produit en produisant un backlog de fonctionnalités qui, une fois livrées, produisent le résultat et la valeur souhaités.
  
  
• 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. Il est courant de combiner des pratiques telles que le développement piloté par les tests (TDD), la programmation par paire et l'examen du code par les pairs, entre autres. Les développeurs utilisent généralement 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 modifications du 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 de l'empaquetage dans un exécutable. Il est recommandé de stocker les résultats de la phase de CI dans un référentiel binaire, pour 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 voient. Généralement, il existe des environnements pour le développement, les tests et la production, chaque environnement exigeant des critères de qualité toujours plus stricts. Pour déployer dans un environnement de production, il est généralement recommandé d'effectuer d'abord un déploiement pour un sous-ensemble d'utilisateurs finaux, puis 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. En surveillant les performances, le comportement et la disponibilité des fonctionnalités, on s'assure que celles-ci sont en mesure d'apporter 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, elle identifie les incidents, avertit le personnel concerné, détermine les problèmes et applique les correctifs.
  
  
• Apprentissage (parfois appelé retour d'information continu). Il s'agit de recueillir les commentaires des utilisateurs finaux et des clients sur les fonctions, la fonctionnalité, les performances et la valeur commerciale afin de les intégrer dans la planification des améliorations et les fonctions de la version suivante. Il s'agit également de tout élément d'apprentissage et de backlog issu des activités opérationnelles, qui pourrait permettre aux développeurs d'éviter de manière proactive tout incident passé qui pourrait 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. 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 :

• 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 les pratiques de gestion de projet agiles telles que Scrum, Lean et Kanban, que les développeurs apportent au DevOps. 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. GiHub et GitLab sont des référentiels de code open source.
  
  
• 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 se situe entre les couches d'application et d'infrastructure en tant que 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. L'étendue des outils et des infrastructures de test est très vaste. Les cadres d'automatisation des tests open source les plus utilisés 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. Datadog, Nagios, Prometheus et Splunk sont des outils de surveillance open source.
  
  
• 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 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. 

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