DevOps

DevOps est une méthodologie utilisée dans le développement de logiciels et dans l'industrie informatique. Utilisé comme un ensemble de pratiques et d'outils, DevOps intègre et automatise le travail de développement de logiciels ( Dev ) et d'opérations informatiques ( Ops ) comme moyen d'améliorer et de raccourcir le cycle de vie du développement des systèmes . DevOps est complémentaire au développement logiciel agile ; plusieurs aspects de DevOps sont issus de l' approche agile .

L'automatisation est un élément important de DevOps. Les programmeurs et les architectes de logiciels doivent utiliser des « fonctions d'adaptation » pour garder leurs logiciels sous contrôle.

Outre le fait qu'il s'agit d'une combinaison interfonctionnelle (et d'un mot-valise ) des termes et concepts de « développement » et d'« opérations », les universitaires et les praticiens n'ont pas développé de définition universelle du terme « DevOps ». Le plus souvent, DevOps se caractérise par des principes clés : la propriété partagée, l'automatisation des flux de travail et un retour d'information rapide. D'un point de vue universitaire, Len Bass , Ingo Weber et Liming Zhu, trois chercheurs en informatique du CSIRO et du Software Engineering Institute, ont suggéré de définir DevOps comme « un ensemble de pratiques destinées à réduire le temps entre la validation d'un changement dans un système et la mise en production normale du changement, tout en garantissant une qualité élevée ». Cependant, le terme est utilisé dans de multiples contextes. Dans ses cas les plus réussis, DevOps est une combinaison de pratiques spécifiques, de changement de culture et d'outils.

Les propositions visant à combiner les méthodologies de développement de logiciels avec les concepts de déploiement et d’exploitation ont commencé à apparaître à la fin des années 80 et au début des années 90.

Vers 2007 et 2008, des inquiétudes ont été soulevées par les membres des communautés de développement de logiciels et de l'informatique selon lesquelles la séparation entre les deux industries, où l'une écrivait et créait des logiciels entièrement distincts de ceux qui déployaient et supportaient les logiciels, créait un niveau fatal de dysfonctionnement au sein de l'industrie.

En 2009, la première conférence intitulée DevOps Days s'est tenue à Gand , en Belgique . La conférence a été fondée par le consultant belge, chef de projet et praticien agile Patrick Debois. La conférence s'est maintenant étendue à d'autres pays.

En 2012, un rapport intitulé « State of DevOps » a été publié pour la première fois par Alanna Brown chez Puppet Labs .

En 2014, le rapport annuel State of DevOps a été publié par Nicole Forsgren , Gene Kim, Jez Humble et d'autres. Ils ont déclaré que l'adoption de DevOps s'accélérait. Également en 2014, Lisa Crispin et Janet Gregory ont écrit le livre More Agile Testing, contenant un chapitre sur les tests et DevOps.

En 2016, les mesures DORA pour le débit (fréquence de déploiement, délai de mise en œuvre des modifications) et la stabilité (temps moyen de récupération, taux d'échec des modifications) ont été publiées dans le rapport State of DevOps. Cependant, la méthodologie de recherche et les mesures ont été critiquées par les experts. En réponse à ces critiques, le rapport State of DevOps 2023 a publié des modifications qui ont mis à jour la mesure de stabilité « temps moyen de récupération » en « temps de récupération après échec de déploiement », reconnaissant la confusion causée par l'ancienne mesure.

Les indicateurs DORA sont un ensemble d'indicateurs clés développés par DevOps Research and Assessment (DORA) qui peuvent aider à mesurer l'efficacité et la fiabilité du développement logiciel. Ces indicateurs comprennent :

• Fréquence de déploiement : temps entre les déploiements de code.
• Délai moyen d'exécution des modifications : temps entre la validation du code et le déploiement.
• Taux d'échec des modifications : pourcentage de déploiements entraînant des problèmes de production.
• Temps moyen de récupération : temps nécessaire pour résoudre les problèmes de production.
• Fiabilité (ajoutée en 2021) : Mesure les performances opérationnelles, en se concentrant sur la disponibilité et le respect des attentes des utilisateurs.

Ces mesures, lorsqu'elles sont appliquées de manière appropriée et dans un contexte pertinent, facilitent la compréhension des performances DevOps, permettant aux équipes d'optimiser la vitesse, la fiabilité et la qualité du déploiement, éclairant ainsi les décisions basées sur les données pour améliorer les processus de développement logiciel.

De nombreuses idées fondamentales des pratiques DevOps s'inspirent ou reflètent d'autres pratiques bien connues telles que le cycle Plan-Do-Check-Act de Lean et Deming , en passant par The Toyota Way et l' approche Agile de décomposition des composants et des tailles de lots. Contrairement à l'approche prescriptive « top-down » et au cadre rigide d' ITIL dans les années 1990, DevOps est « bottom-up » et flexible, ayant été créé par des ingénieurs logiciels pour leurs propres besoins.

Les motivations de ce qui est devenu le DevOps moderne et de plusieurs pratiques DevOps standard telles que la construction et les tests automatisés, l'intégration continue et la livraison continue trouvent leur origine dans le monde Agile, qui remonte (de manière informelle) aux années 1990 et officiellement à 2001. Les équipes de développement agiles utilisant des méthodes telles que la programmation extrême ne pouvaient pas « satisfaire le client par une livraison précoce et continue de logiciels de valeur » à moins d'assumer la responsabilité des opérations et de l'infrastructure de leurs applications, en automatisant une grande partie de ce travail. Étant donné que Scrum est devenu le cadre Agile dominant au début des années 2000 et qu'il a omis les pratiques d'ingénierie qui faisaient partie de nombreuses équipes Agile, le mouvement d'automatisation des opérations et des fonctions d'infrastructure s'est séparé d'Agile et s'est étendu à ce qui est devenu le DevOps moderne. Aujourd'hui, DevOps se concentre sur le déploiement de logiciels développés, qu'ils soient développés à l'aide de méthodologies orientées Agile ou d'autres méthodologies.

ArchOps présente une extension de la pratique DevOps, à partir d' artefacts d'architecture logicielle , au lieu du code source, pour le déploiement des opérations. ArchOps déclare que les modèles architecturaux sont des entités de premier ordre dans le développement, le déploiement et les opérations de logiciels.

L'automatisation est un principe fondamental pour réussir DevOps et le CI/CD est un élément essentiel. De plus, une collaboration et une communication améliorées entre et au sein des équipes permettent d'accélérer la mise sur le marché , avec des risques réduits.

Le DevOps mobile est un ensemble de pratiques qui applique les principes du DevOps spécifiquement au développement d'applications mobiles. Le DevOps traditionnel se concentre sur la rationalisation du processus de développement logiciel en général, mais le développement mobile a ses propres défis uniques qui nécessitent une approche sur mesure. Le DevOps mobile n'est pas simplement une branche du DevOps spécifique au développement d'applications mobiles, mais plutôt une extension et une réinterprétation de la philosophie DevOps en raison des exigences très spécifiques du monde mobile.

En 2003, Google a développé l'ingénierie de fiabilité des sites (SRE), une approche permettant de publier en continu de nouvelles fonctionnalités dans des systèmes à grande échelle et à haute disponibilité tout en maintenant une expérience utilisateur de haute qualité. Bien que SRE soit antérieur au développement de DevOps, ils sont généralement considérés comme étant liés les uns aux autres. Certains des auteurs originaux de la discipline considèrent SRE comme une implémentation de DevOps.

Le système de production Toyota, également connu sous l'acronyme TPS, a inspiré la pensée Lean avec son accent sur l'amélioration continue , le kaizen , le flux et les petits lots. Le principe du cordon andon pour créer un retour d'information rapide, un essaim et résoudre les problèmes découle du TPS.

DevSecOps est une extension de DevOps qui permet d'intégrer les pratiques de sécurité dans l'approche DevOps. Contrairement à un modèle d'équipe de sécurité centralisée traditionnel, chaque équipe de livraison est habilitée à prendre en compte les contrôles de sécurité appropriés dans la livraison de son logiciel. Les pratiques et les tests de sécurité sont effectués plus tôt dans le cycle de vie du développement, d'où le terme « shift left ». La sécurité est testée dans trois domaines principaux : statique, composition logicielle et dynamique.

La vérification statique des logiciels via des tests de sécurité des applications statiques (SAST) est un test en boîte blanche avec une attention particulière portée à la sécurité. Selon le langage de programmation, différents outils sont nécessaires pour effectuer une telle analyse de code statique. La composition du logiciel est analysée, en particulier les bibliothèques, et la version de chaque composant est vérifiée par rapport aux listes de vulnérabilités publiées par le CERT et d'autres groupes d'experts. Lors de la fourniture de logiciels aux clients, les licences des bibliothèques et leur correspondance avec la licence du logiciel distribué sont au centre des attentions, en particulier les licences copyleft .

Dans les tests dynamiques, également appelés tests en boîte noire , les logiciels sont testés sans connaître leurs fonctions internes. Dans DevSecOps, cette pratique peut être appelée test de sécurité dynamique des applications (DAST) ou test de pénétration. L'objectif est la détection précoce des défauts, notamment les vulnérabilités de type cross-site scripting et injection SQL . Les types de menaces sont publiés par le projet de sécurité des applications Web ouvert , par exemple son TOP10, et par d'autres organismes.

DevSecOps a également été décrit comme un changement culturel impliquant une approche holistique de la production de logiciels sécurisés en intégrant l'éducation à la sécurité, la sécurité dès la conception et l'automatisation de la sécurité.

Les initiatives DevOps peuvent créer des changements culturels dans les entreprises en transformant la façon dont les opérations , les développeurs et les testeurs collaborent pendant les processus de développement et de livraison. Faire en sorte que ces groupes travaillent de manière cohérente est un défi crucial dans l'adoption de DevOps en entreprise. DevOps concerne autant la culture que la chaîne d'outils.

Bien qu'il soit en principe possible de pratiquer DevOps avec n'importe quel style architectural, le style architectural des microservices devient la norme pour la construction de systèmes déployés en continu. Un service de petite taille permet à l'architecture d'un service individuel d'émerger grâce à un refactoring continu.

Il favorise également la cohérence, la fiabilité et l'efficacité au sein de l'organisation, et est généralement rendu possible par un référentiel de code partagé ou un contrôle de version. Comme le suggère le chercheur DevOps Ravi Teja Yarlagadda, « grâce à DevOps, on suppose que toutes les fonctions peuvent être exécutées, contrôlées et gérées dans un endroit central à l'aide d'un code simple. »

De nombreuses organisations utilisent le contrôle de version pour alimenter les technologies d'automatisation DevOps telles que les machines virtuelles , la conteneurisation (ou la virtualisation au niveau du système d'exploitation ) et le CI/CD . Le document « DevOps : développement d'une chaîne d'outils dans le domaine bancaire » indique qu'avec des équipes de développeurs travaillant sur le même projet, « tous les développeurs doivent apporter des modifications à la même base de code et parfois même modifier les mêmes fichiers. Pour un travail efficace, il doit y avoir un système qui aide les ingénieurs à éviter les conflits et à conserver l'historique de la base de code », avec le système de contrôle de version Git et la plateforme GitHub référencés comme exemples.

GitOps a évolué à partir de DevOps. L'état spécifique de la configuration du déploiement est le contrôle de version . Étant donné que le contrôle de version le plus populaire est Git , l'approche de GitOps a été nommée d'après Git . Les modifications de configuration peuvent être gérées à l'aide de pratiques de révision de code et peuvent être annulées à l'aide du contrôle de version. Essentiellement, toutes les modifications apportées à un code sont suivies, marquées d'un signet et les mises à jour de l'historique peuvent être facilitées. Comme l'explique Red Hat , « la visibilité des modifications signifie la capacité à tracer et à reproduire rapidement les problèmes, améliorant ainsi la sécurité globale. »

Les pratiques suivantes peuvent améliorer la productivité des pipelines DevOps , en particulier dans les systèmes hébergés dans le cloud :

• Nombre de pipelines : les petites équipes peuvent être plus productives en disposant d'un seul référentiel et d'un seul pipeline. En revanche, les grandes organisations peuvent disposer de référentiels et de pipelines distincts pour chaque équipe, voire de référentiels et de pipelines distincts pour chaque service au sein d'une équipe.
• Autorisations : Dans le contexte des autorisations liées aux pipelines , le respect du principe du moindre privilège peut s'avérer difficile en raison de la nature dynamique de l'architecture . Les administrateurs peuvent opter pour des autorisations plus permissives tout en mettant en œuvre des contrôles de sécurité compensatoires pour minimiser le rayon d'explosion.