Jusqu'à peu avant l'année 2000, la plupart des logiciels étaient développés et mis à jour selon la méthode de la cascade, une approche linéaire des projets de développement à grande échelle. Les équipes de développement  de logiciels passaient des mois à développer de grands corps de nouveau code qui avaient un impact sur la plupart ou la totalité de l'application. Les changements étant très importants, ils passaient plusieurs mois supplémentaires à intégrer ce nouveau code dans le codebase. 

Ensuite, les équipes chargées de l'assurance qualité (QA), de la sécurité et des opérations passeront 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 distribution de fonctions était souvent caractérisée par des plans de déploiement complexes et risqués, des blocages difficiles à programmer avec les systèmes en amont et en aval, et le « grand espoir » de l'informatique que les exigences métier n'avaient 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 Agile de développement de logiciels, 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 codebase 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 compartimenter les risques.

Plus ces pratiques de développement Agile accéléraient le développement et la distribution des logiciels, plus elles faisaient des opérations informatiques encore isolées, approvisionnement du système, configuration, tests d'acceptation, gestion, surveillance, le nouveau goulot d'étranglement dans le cycle de vie de la distribution des logiciels. 

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. Et il a mis en place 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 métier du produit en produisant un backlog (reste-à-faire) de fonctions qui, une fois distribuées, produisent un résultat souhaité ayant de la 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, sur la base des récits des 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 leur poste de travail local pour exécuter la « boucle interne » d'écriture et de test du code avant de l'envoyer dans le pipeline de distribution continue.
• Intégration (ou création ou intégration continue et distribution continue (CI/CD). Comme indiqué ci-dessus, dans ce flux, le nouveau code est intégré dans le codebase existant, puis testé et empaqueté dans un exécutable pour le 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 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 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 à déployer d'abord vers sous-ensemble d'utilisateurs finaux, puis éventuellement 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 »,  une fois que les fonctions exécutées 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. Les opérations garantissent le bon fonctionnement des fonctions et l'absence d'interruptions de service, en s'assurant que le réseau, le stockage, la plateforme, l'informatique et la sécurité sont tous sains ! Si quelque chose ne va pas, l'équipe des opérations garantissent que les incidents sont identifiés, que le personnel approprié est alerté, que les problèmes sont déterminés et que les corrections sont appliquées.
• Apprentissage (parfois appelé commentaire 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 à la phase de planification et que l'on « s'améliore continuellement ! »

Trois autres flux continus importants se produisent entre ces flux :

Tests continus :  les cycles de vie DevOps classiques 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 constituent une forme puissante d'identification des risques et des vulnérabilités et offrent 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 Agile « ajoutent » des flux de sécurité après la distribution ou le déploiement, 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 appelée shift left (tests précoces) (qui est plus facile à comprendre dans la figure 1). Certaines organisations ont eu moins de succès que d'autres dans le left shift, ce qui a conduit à l'émergence de DevSecOps (voir ci-dessous).

Compliance. Il est également préférable d'aborder la question de la conformité auxréglementations  (gouvernance et risque) dès le début 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érifiabilité 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 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, DevOps exige une communication, une collaboration et un partage des responsabilités permanents entre toutes les parties prenantes à 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épart.

Dans la plupart des cas, la meilleure façon d'y parvenir est de démanteler ces silos et de les réorganiser en équipes DevOps transversales et autonomes qui peuvent travailler sur des projets de code du début à la fin, de la planification au retour d'information, 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 les fondements d'une focalisation commune sur le produit qui a un résultat valable.

Sur le plan technique, DevOps exige un engagement en faveur de l'automatisation, qui permet de faire avancer les projets au sein des flux et entre eux, 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.

Les exigences du DevOps et de la culture DevOps exigent des outils qui prennent en charge la collaboration asynchrone, intègrent de manière transparente les flux DevOps et automatisent autant que possible l'ensemble du cycle de vie DevOps. Les catégories d'outils DevOps incluent :

• Outils de gestion de projet : outils qui permettent aux équipes de constituer un backlog de récits 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 :  environnements de codage à contrôle de version qui permettent à plusieurs développeurs de travailler sur le même codebase. 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 qui automatisent la vérification, la création, les tests et le déploiement du code. Jenkins est l'outil open source le plus populaire dans cette catégorie ; de nombreuses alternatives auparavant open source, telles que CircleCI, sont désormais disponibles uniquement 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 un autre choix open source très utilisé pour le CI/CD Kubernetes natif.
• Fremaworks d'automatisation des tests  : il s'agit d'outils logiciels, de bibliothèques et de meilleures pratiques 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 frameworks 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 as 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 remplit la même fonction pour les applications conteneurisées (voir « DevOps et développement cloud natif », ci-dessous).
• Outils de surveillance  : ils aident les équipes DevOps à identifier et à résoudre les problèmes de système ; ils recueillent et analysent également les données en temps réel pour révéler l'impact des changements de code sur les performances des applications. Les outils de surveillance open source comprennent Datadog, Nagios, Prometheus et Splunk.
• Outils de retour d'information continu  : outils permettant 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.

Cloud natif est une approche de la création d'applications qui exploitent les technologies fondamentales du cloud computing. L'objectif de l'approche cloud natif 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 : des 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).
• Exploité (à l'é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 d'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 codebase, sont parfaitement adaptés aux cycles de gestion et de publication rapides de DevOps. Et 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 a révélé que 78 % des utilisateurs actuels de microservices prévoient d'augmenter le temps, l'argent 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. Et 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 computing, dont AWS, Google, Microsoft Azure et IBM Cloud, proposent une solution de pipeline DevOps géré.

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.

En d'autres termes, DevSecOps est ce que 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.

DevSecOps est apparu comme un effort spécifique pour intégrer et automatiser la sécurité comme prévu à l'origine. Dans le cadre de 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.

Visionnez « Qu'est-ce que DevSecOps ? » pour en savoir plus sur les principes, les avantages et les cas d'utilisation, avantages et cas d' utilisation  DevSecOps