DevOps

Pourquoi DevOps est-il important ?

Au fond, il est démontré que le DevOps et les pratiques DevOps améliorent la qualité des logiciels et les résultats des projets de développement pour l'entreprise. Ces améliorations prennent plusieurs formes, notamment les suivantes :

• Collaboration et communication. DevOps élimine de nombreux silos organisationnels traditionnels qui peuvent inhiber la créativité et les flux de travail. Les pratiques DevOps rassemblent les développeurs, les opérations informatiques, les chefs d'entreprise et les parties prenantes des applications afin de garantir que le logiciel en cours de construction est conçu, développé, testé, déployé et géré de la meilleure façon possible pour l'entreprise et les utilisateurs.
• Résultats du développement. DevOps adopte un processus cyclique de développement continu et itératif. Les méthodologies de développement traditionnelles, telles que le développement en cascade, codifient les exigences et les résultats des mois ou des années avant le processus de développement proprement dit. Les projets DevOps commencent généralement par des fonctionnalités minimales, puis s'affinent et s'enrichissent systématiquement tout au long du cycle de vie du projet. Cela permet à l'entreprise d'être plus réactive face à l'évolution des marchés, aux demandes des utilisateurs et à la pression de la concurrence.
• Qualité du produit. La nature cyclique et itérative de DevOps garantit que les produits sont testés en permanence à mesure que les défauts existants sont corrigés et que de nouveaux problèmes sont identifiés. Une grande partie de ces tâches est effectuée avant chaque version, ce qui se traduit par des versions fréquentes qui permettent à DevOps de fournir des logiciels avec moins de bogues et une meilleure disponibilité par rapport aux logiciels créés avec des paradigmes traditionnels.
• Gestion du déploiement. DevOps intègre les tâches de développement de logiciels et d'exploitation informatique, ce qui permet souvent aux développeurs d'approvisionner, de déployer et de gérer chaque version de logiciel avec peu, voire aucune, intervention de la part du service informatique. Le personnel informatique peut ainsi se consacrer à des tâches plus stratégiques. Le déploiement peut avoir lieu dans l'infrastructure locale ou dans les ressources du cloud public, en fonction des objectifs spécifiques du projet.

Un environnement DevOps bien exécuté permet à une entreprise de mettre sur le marché des produits logiciels plus compétitifs et de meilleure qualité plus rapidement, avec des demandes de support et de maintenance moindres, que les paradigmes de développement traditionnels.

Comment fonctionne DevOps ?

DevOps est une méthodologie destinée à améliorer le travail tout au long du cycle de vie du développement logiciel. On peut visualiser le processus DevOps comme une boucle infinie, comprenant les étapes suivantes : planifier, coder, construire, tester, libérer, déployer, exploiter, surveiller et, grâce au retour d'information, planifier, ce qui réinitialise la boucle.

Idéalement, la boucle cyclique qui comprend chaque itération DevOps permet de réduire considérablement le stress lié aux résultats du développement. Le développement traditionnel en cascade utilisait une approche "tout ou rien" dans laquelle les exigences étaient rassemblées dès le départ, puis le code était écrit, testé et publié au fur et à mesure des événements ; tout résultat, problème de performance ou de fiabilité était traité après coup. DevOps donne aux organisations beaucoup plus de flexibilité dans le développement et la diffusion de logiciels qui mûrissent systématiquement au fil du temps, permettant à l'équipe de s'adapter, de changer, d'apprendre et d'essayer de nouvelles approches innovantes et de prendre des risques que les paradigmes de développement traditionnels n'auraient jamais pu permettre. Les organisations utilisent une combinaison de culture et de technologie pour poursuivre cet objectif.

Pour aligner le logiciel sur les attentes, les développeurs et les parties prenantes communiquent sur le projet, et les développeurs travaillent sur de petites mises à jour qui sont mises en ligne indépendamment les unes des autres.

Pour éviter les temps d'attente, les équipes informatiques utilisent des pipelines CI/CD et d'autres méthodes d'automatisation pour faire passer le code d'une étape de développement et de déploiement à une autre. Les équipes examinent les changements immédiatement et peuvent s'appuyer sur des politiques et des outils pour appliquer des politiques et s'assurer que les versions respectent les normes.

Il est facile d'écrire des logiciels rapidement ; écrire des logiciels qui fonctionnent est une autre histoire. Pour déployer un bon code en production, les adeptes de DevOps utilisent des conteneurs ou d'autres méthodes pour que le logiciel se comporte de la même manière du développement à la production, en passant par les tests. Ils déploient les changements individuellement afin que les problèmes soient traçables. Les équipes s'appuient sur l'automatisation et la gestion de la configuration pour assurer la cohérence des environnements de déploiement et d'hébergement. Les problèmes qu'ils découvrent dans les opérations en direct conduisent à des améliorations du code, souvent par le biais d'une enquête post-mortem irréprochable et de canaux de retour d'information continus.

Les développeurs peuvent prendre en charge le logiciel en cours d'exécution, ce qui les oblige à tenir compte des considérations relatives à la durée d'exécution. Les administrateurs des opérations informatiques peuvent être impliqués dans les réunions de conception du logiciel, offrant des conseils sur la manière d'utiliser les ressources de manière efficace et sécurisée. Tout le monde peut contribuer à des analyses rétrospectives irréprochables. Plus ces spécialistes collaborent et partagent leurs compétences, plus ils peuvent favoriser une culture DevOps.

Quels problèmes DevOps résout-il ?

Chaque entreprise est confrontée à ses propres défis, mais les problèmes les plus courants sont les suivants : des versions qui prennent trop de temps, des logiciels qui ne répondent pas aux attentes et des technologies de l'information qui limitent la croissance de l'entreprise.

Sans temps d'attente, sans processus manuels et sans longues révisions, un projet DevOps passe plus rapidement des exigences à un logiciel opérationnel. Des cycles plus courts permettent d'éviter que les exigences ne changent afin que le produit réponde aux attentes des clients. Lorsque les exigences doivent être modifiées pour répondre aux attentes changeantes des utilisateurs et aux demandes du marché, des temps de cycle courts peuvent aider à mettre en œuvre ces changements et à commercialiser les mises à jour plus rapidement.

DevOps résout les problèmes de communication et de priorité entre les spécialisations informatiques. Pour créer des logiciels viables, les équipes de développement doivent comprendre l'environnement de production et tester leur code dans des conditions réalistes. Une structure traditionnelle place les équipes de développement et d'exploitation dans des silos. Cela signifie que les développeurs sont satisfaits lorsque leur code fournit des fonctionnalités - et si la version ne fonctionne pas bien ou échoue en production, c'est à l'équipe des opérations de résoudre les problèmes.

Avec une culture DevOps, les développeurs n'ont pas recours à la réponse "Ça fonctionnait sur ma machine" lorsqu'un problème survient. Les modifications apportées à la production sont mineures et réversibles. De plus, toute l'équipe comprend les changements, ce qui simplifie la gestion des incidents.

Avec un processus plus rapide de l'idée au logiciel vivant, les entreprises peuvent capitaliser sur les opportunités du marché. Ainsi, DevOps offre un avantage concurrentiel aux entreprises.

L'évolution de DevOps

C'est à Patrick Debois, consultant en développement logiciel, que l'on doit la création du terme DevOps en 2009, à l'occasion d'une conférence intitulée DevOps Days. DevOps répondait à une lacune de la méthodologie Agile de développement de logiciels : Le développement itératif et rapide du code ne conduisait pas nécessairement à un déploiement itératif et rapide du code.

Parallèlement à la poussée de l'Agile dans les opérations, les administrateurs informatiques se sont heurtés à des étapes de gestion du changement parfois laborieuses et trop complexes dans le cadre de l'ITIL. L'ITIL prône une informatique stable, fiable et prévisible, tandis que l'Agile prône la collaboration et le changement. DevOps a touché une corde sensible dans les deux camps. En fait, les organisations peuvent faire à la fois de l'ITIL et du DevOps, surtout si elles adoptent le cloud.

Le concept de DevOps a ensuite été popularisé par le livre The Phoenix Project en 2013. Le Projet Phoenix utilise un récit fictif pour illustrer des problèmes endémiques et aider les responsables informatiques à comprendre les concepts et les avantages de la collaboration et des technologies partagées.

Parmi les premiers partisans de DevOps, on trouve ces acteurs clés :

• Debois et son collaborateur Andrew Clay Shafer.
• Gene Kim, Kevin Behr et George Spafford, auteurs du projet Phoenix.
• Paul Hammond et John Allspaw, pionniers influents de Flickr.
• Jez Humble et Dave Farley, pionniers de la livraison continue.
• John Willis, défenseur de la conteneurisation.
• Les organisateurs du rapport sur l'état de DevOps, dont Alanna Brown et Nicole Forsgren.

Au fur et à mesure que DevOps devenait populaire, les organisations ont formalisé les approches DevOps. Le détaillant Target est à l'origine de la méthode de formation DevOps Dojo, par exemple. Les fournisseurs ont vanté les capacités des outils permettant le DevOps, depuis les chatbots de collaboration jusqu'aux suites CI/CD intégrées aux services cloud. Des technologies telles que les conteneurs virtuels, les services de cloud public et les architectures d'applications microservices s'adaptaient naturellement à la nature rapide et flexible des approches DevOps. L'appellation "ingénieur DevOps" est rapidement apparue comme un titre de poste.

Le DevOps continue d'évoluer, alors que l'intelligence artificielle fait surface pour aider à tout, de la création de code à la gestion des incidents. L'IA pour DevOps (ou AIOps) signifie une automatisation plus intelligente et des temps d'attente encore plus courts, voire des traductions transparentes entre les besoins de l'entreprise et l'offre technologique - mais il reste de nombreux obstacles à franchir avant que l'AIOps ne devienne réalité.

Bien que DevOps ait atteint le statut de courant dominant, tous ceux qui l'ont adopté n'en sont pas pour autant des convertis. Beaucoup s'appuient sur une approche DevOps pour des projets informatiques générateurs de revenus, où ils voient un retour sur investissement dans les outils et les compétences de pointe. Pour de nombreux services informatiques internes stables et matures, tels que les applications traditionnelles bien établies, DevOps n'offre pas d'avantages significatifs.

Méthodologies, principes et stratégies DevOps

DevOps est associé au développement logiciel Agile car les praticiens Agile ont promu DevOps comme un moyen d'étendre la méthodologie à la production. L'approche a même été qualifiée de contre-culture par rapport aux pratiques de gestion des services informatiques défendues par l'ITIL. DevOps n'a pas de cadre officiel.

Pour affiner leurs stratégies, les organisations doivent comprendre les contextes liés au DevOps, au développement Agile et Waterfall, à l'ingénierie de fiabilité des sites (SRE) et au SysOps, et même les variations au sein du DevOps.

DevOps vs. développement en cascade

Le développement en cascade comprend une série d'étapes et de portes dans une progression linéaire vers la production. Ses phases sont les suivantes : exigences, analyse, conception, codage et mise en œuvre, tests, exploitation, déploiement et maintenance. Dans les équipes en cascade, le développement teste le nouveau code dans un environnement isolé pour l'assurance qualité (QA) et, si les exigences sont satisfaites, transmet le code à l'exploitation pour qu'il soit utilisé en production. Les opérations informatiques déploient plusieurs versions à la fois, avec des contrôles étendus. L'assistance relève de la responsabilité des opérations. Les approches en cascade engendrent de longues attentes entre les versions des logiciels. Comme les équipes de développement et d'exploitation travaillent séparément, les développeurs ne sont pas toujours au courant des obstacles opérationnels qui empêchent le code de fonctionner comme prévu.

Le modèle DevOps aligne les efforts de développement, d'assurance qualité et d'exploitation informatique avec moins de barrières et un flux de travail plus continu. Par exemple, certaines des responsabilités de l'équipe des opérations se déplacent vers la gauche dans le pipeline de livraison d'applications vers l'équipe de développement. L'équipe des opérations informatiques fournit un retour d'information pour l'amélioration du code. Plutôt que sur des étapes délimitées, DevOps s'appuie sur des processus de CI/CD et de surveillance continue.

DevOps vs. développement agile

L'approche agile est une approche de développement de logiciels définie dans le Manifeste Agile. Les équipes agiles se concentrent sur des cycles incrémentaux et rapides de création et de livraison de code, appelés sprints. Chaque sprint s'inspire du précédent, ce qui rend le logiciel flexible et adaptable à l'évolution des besoins. Il est possible de perdre la vision originale d'un projet au cours de ce cycle.

Le DevOps est né du succès de l'Agile dans l'amélioration de la vitesse de développement et de la prise de conscience que les déconnexions entre les équipes de développement et d'exploitation - ainsi qu'entre l'informatique et l'aspect commercial de l'organisation - entravaient considérablement la livraison des logiciels de l'Agile aux utilisateurs.

Dans un flux de travail uniquement Agile, les équipes de développement et d'exploitation ont des objectifs et un leadership distincts. Lorsqu'une organisation utilise à la fois DevOps et Agile, les équipes de développement et d'exploitation gèrent le code tout au long du cycle de vie du développement logiciel. Bien que le travail agile soit souvent formalisé par un cadre, tel que Scrum, DevOps n'a pas de cadre.

DevOps vs. CD

Les méthodologies CD impliquent un schéma cyclique fréquent de construction et de validation des modifications du code dans un référentiel central. Le code peut ensuite être testé et validé à l'aide de technologies de test automatisées et manuelles. Si les tests sont concluants, on peut envisager de mettre le code en production.

DevOps suit le même modèle cyclique de développement et de test. Cependant, le CD s'arrête généralement aux aspects mécaniques de la création de code. Il n'offre pas les principes et l'accent mis sur la communication et la collaboration au sein de l'organisation que DevOps cherche à améliorer.

DevOps vs. SRE

La SRE est apparue en même temps qu'Agile et DevOps. Lancé au début des années 2000 chez Google, il s'agit d'une approche du cycle de vie du développement logiciel axée sur la programmation et l'automatisation. La SRE met l'accent sur la fiabilité et l'évolutivité des logiciels afin de prévoir et d'atténuer les problèmes susceptibles de compromettre la stabilité et la santé d'une application. Les problèmes doivent être résolus de manière à éviter qu'ils ne se reproduisent. Les tâches répétitives doivent être réduites au minimum.

La boîte à outils de la SRE correspond étroitement à celle de DevOps. Les deux disciplines visent l'amélioration continue. Les ingénieurs SRE et DevOps cherchent à abolir les silos entre le développement et les opérations. Bien que DevOps puisse également s'étendre aux parties prenantes de l'entreprise, SRE reste généralement dans les limites des processus informatiques.

DevOps vs. SysOps

SysOps signifie généralement qu'un administrateur informatique ou une équipe informatique gère le déploiement de la production et le support d'une grande application distribuée, telle qu'un produit SaaS. Comme les adeptes de DevOps, les équipes SysOps doivent connaître le cloud et l'automatisation, ainsi que d'autres technologies qui permettent aux applications de fonctionner correctement à grande échelle. Les équipes SysOps dépannent les pannes et les incidents informatiques, surveillent les problèmes de performance, appliquent les règles de sécurité et optimisent les opérations.

Ils se concentrent également sur la haute disponibilité, la tolérance aux pannes, la sécurité et les performances, tout comme les autres administrateurs informatiques. Bien que les professionnels SysOps soient susceptibles d'utiliser certains outils de développement et de comprendre les processus de développement, leur travail n'est pas aussi lié au développement que dans un poste DevOps. Cependant, les rôles SysOps peuvent exister au sein des organisations DevOps et SRE.

DevSecOps vs BizDevOps vs GitOps

Certaines organisations élargissent la portée de DevOps pour inclure d'autres rôles, tels que les équipes de sécurité ou les départements. Dans DevSecOps, la planification de la sécurité et de la conformité, les analyses, les tests et les examens se déroulent en continu tout au long de la boucle DevOps. BizDevOps se concentre sur la connexion des cadres, des propriétaires d'applications et d'autres parties prenantes de l'entreprise à l'équipe technique, qui développe, teste et soutient le logiciel. Bien qu'il soit préférable de collaborer davantage que moins, ces collaborateurs doivent partager des informations efficaces, opportunes et précises.

Une autre variante de DevOps, ou une faction différente du même mouvement, est GitOps. Nommé ainsi parce qu'il met l'accent sur le référentiel éponyme et la technologie de contrôle des versions, GitOps préconise un contrôle déclaratif des sources pour le code des applications et de l'infrastructure. Tout ce qui concerne le logiciel - des exigences en matière de fonctionnalités à l'environnement de déploiement - provient d'une seule source de vérité. GitOps est souvent associé à des techniques de gestion du changement et de déploiement telles que l'infrastructure immuable, qui impose de remplacer ou de rétablir - plutôt que de mettre à niveau ou de modifier - le code déployé à chaque fois qu'une modification est apportée.

Quels sont les avantages de DevOps ?

DevOps a été largement adopté par les développeurs et les organisations en raison des nombreuses améliorations qu'il apporte par rapport aux paradigmes de développement traditionnels. Les avantages de DevOps sont notamment les suivants :

• Moins de cloisonnements et une meilleure communication entre les groupes informatiques.
• Mise sur le marché plus rapide des logiciels, ce qui accroît les revenus et les possibilités concurrentielles de l'entreprise.
• Amélioration rapide basée sur le retour d'information des utilisateurs et des parties prenantes.
• Plus de tests se traduisent par une meilleure qualité des logiciels, de meilleures pratiques de déploiement et moins de temps d'arrêt.
• Amélioration de l'ensemble du processus de livraison de logiciels par le biais de la construction, de l'utilisation du référentiel, de la validation et du déploiement.
• Moins de tâches subalternes dans le pipeline DevOps, grâce à l'automatisation.
• Rationalisation des processus de développement grâce à une responsabilité accrue et à l'appropriation du code dans le développement.
• Des rôles et des compétences plus larges.

Quels sont les défis de DevOps ?

Cependant, les défis DevOps ne manquent pas. Le paradigme DevOps pose ses propres complexités et changements qui peuvent être difficiles à mettre en œuvre et à gérer au sein d'une organisation très occupée. Les défis DevOps les plus courants sont les suivants :

• Les changements dans l'organisation et les services informatiques, y compris les nouvelles compétences et les nouveaux rôles, qui peuvent perturber les équipes de développement et l'entreprise.
• Des outils et des plateformes coûteux, y compris la formation et l'assistance nécessaires pour les utiliser efficacement.
• Développement et prolifération des outils informatiques.
• Automatisation inutile, fragile, mal mise en œuvre et mal entretenue, ou dangereuse.
• Difficultés liées à la logistique et à la charge de travail pour faire évoluer DevOps dans le cadre de plusieurs projets et équipes.
• Déploiement plus risqué en raison d'une mentalité d'échec rapide et d'une généralisation des tâches par rapport à une spécialisation où l'accès aux systèmes de production est géré par un personnel moins averti en matière de technologies de l'information.
• Conformité réglementaire, en particulier lorsque la séparation des rôles est nécessaire.
• Nouveaux goulets d'étranglement tels que les tests automatisés ou l'utilisation du référentiel.

En bref, DevOps ne résout pas tous les problèmes des entreprises et ne profite pas de la même manière à tous les projets de développement de logiciels.

Meilleures pratiques pour l'adoption de DevOps

L'adoption de DevOps ou d'autres paradigmes de CD peut perturber les logiciels et les équipes de gestion. Il y a des changements inévitables dans les flux de travail, les processus, les ensembles d'outils et même le personnel, ce qui entraînera un besoin de formation supplémentaire. Il est facile pour l'adoption de DevOps de s'écarter de la bonne voie et de tomber dans l'oubli. Voici quelques conseils qui peuvent faciliter l'adoption de DevOps et maximiser les chances de succès de l'entreprise.

Commencer modestement

Les transformations DevOps ne se font pas du jour au lendemain. De nombreuses entreprises commencent par un projet pilote - une application simple qui leur permet de se familiariser avec les nouvelles pratiques et les nouveaux outils. Les équipes DevOps recherchent des gains rapides et faciles pour affiner les flux de travail, apprendre les outils et prouver la valeur des principes DevOps. Pour une adoption à grande échelle de DevOps, essayez de procéder par étapes.

Tenir compte des flux de travail

Au départ, DevOps peut signifier un engagement de la part des équipes de développement et d'exploitation informatique à comprendre les préoccupations et les limites technologiques qui existent à chaque étape du projet logiciel. Se mettre d'accord sur les indicateurs de performance clés à améliorer, tels que des temps de cycle plus courts ou moins de bogues dans la production. Comprendre comment les pratiques DevOps s'articulent avec les pratiques actuelles de développement et de déploiement, et planifier des changements appropriés au flux de travail tout en améliorant la qualité, la sécurité et la conformité des logiciels. Posez les bases de processus continus en communiquant entre les différentes fonctions.

Choisir les outils appropriés

Évaluer les outils existants pour le développement de logiciels et les opérations informatiques. Des outils supplémentaires ou différents peuvent être nécessaires. Identifiez les lacunes du processus, comme une étape qui est toujours traitée manuellement - passer d'une validation de code à des tests, par exemple - ou un outil sans API pour se connecter à d'autres outils. Envisagez de normaliser un pipeline DevOps pour l'ensemble de l'entreprise. Avec un pipeline unique, les membres de l'équipe peuvent passer d'un projet à l'autre sans avoir à se reconvertir. Les spécialistes de la sécurité peuvent renforcer le pipeline et la gestion des licences est facilitée. La contrepartie de cette approche est que les équipes DevOps renoncent à la liberté d'utiliser ce qui leur convient le mieux.

Utiliser des indicateurs significatifs

Il ne suffit pas d'adopter DevOps pour garantir le succès. Il faut d'abord comprendre la nécessité de DevOps - quels sont les problèmes qu'il est censé résoudre ou quels sont les avantages qu'il est censé apporter. Sélectionnez les indicateurs de performance et les indicateurs clés de performance qui montreront ces résultats, puis prévoyez de mesurer et de rendre compte de ces indicateurs en tant que jauge objective de la réussite de DevOps. Par exemple, une mesure telle que les défauts trouvés ou la vitesse de validation du code peut aider à gérer les résultats DevOps.

L'organisation dispose désormais d'un état d'esprit DevOps, d'indicateurs de suivi de la réussite et d'outils performants. Concentrez-vous sur les meilleures pratiques, le partage des connaissances et le développement des compétences pour continuer à vous améliorer. Optimisez l'outillage et les technologies, en identifiant les blocages et les lacunes qui affectent vos indicateurs clés de performance.

Utiliser le modèle de maturité DevOps

Le modèle de maturité DevOps illustre cinq phases principales d'adoption, allant de novice à bien établi. Les organisations peuvent utiliser le modèle de maturité DevOps comme guide d'adoption en identifiant leur place dans le modèle :

• Initial. Les équipes sont cloisonnées ; le travail est réactif et effectué à l'aide d'outils et de processus ad hoc.
• Défini. Un projet pilote définit une approche DevOps, des processus et des outils de base. Il s'agit d'une preuve de concept.
• Géré. L'organisation augmente l'adoption de DevOps en s'appuyant sur les enseignements tirés du projet pilote. Les résultats du projet pilote sont reproductibles avec différents membres du personnel et types de projets.
• Mesuré. Avec des processus et des outils en place, les équipes partagent leurs connaissances et affinent leurs pratiques. L'automatisation et la connectivité des outils augmentent, et les normes sont appliquées par le biais de politiques.
• Optimisé. Une amélioration continue se produit. DevOps peut évoluer vers différents ensembles d'outils ou de processus pour s'adapter aux cas d'utilisation. Par exemple, les applications destinées aux clients ont une fréquence de publication plus élevée, et les applications de gestion financière suivent des pratiques DevSecOps.

Outils DevOps

DevOps est un état d'esprit, pas un ensemble d'outils. Mais il est difficile de faire quoi que ce soit au sein d'une équipe informatique sans outils adaptés et bien intégrés. En général, les praticiens du DevOps s'appuient sur un pipeline CI/CD, des conteneurs et l'hébergement dans le cloud. Les outils peuvent être open source, propriétaires ou des distributions prises en charge de technologies open source.

Dépôts de code. Les dépôts de code source à version contrôlée permettent à plusieurs développeurs de travailler sur le code. Les développeurs vérifient le code à l'entrée et à la sortie, et peuvent revenir à une version antérieure du code si nécessaire. Ces outils conservent une trace des modifications apportées au code source, y compris l'identité de l'auteur des modifications et la date à laquelle elles ont été effectuées. Sans ce suivi, les développeurs peuvent avoir du mal à savoir quelles sont les modifications récentes et quelles versions du code sont disponibles pour les utilisateurs finaux.

Dans un pipeline CI/CD, une modification du code introduite dans le référentiel de contrôle de version déclenche automatiquement les étapes suivantes, telles qu'une analyse statique du code ou des tests de construction et d'unité. Les outils de gestion du code source comprennent Git et GitHub, ainsi que Bitbucket, Mercurial, Subversion et d'autres.

Dépôts d'artefacts. Le code source est compilé dans un artefact pour être testé. Les référentiels d'artefacts permettent d'obtenir des résultats basés sur des objets et contrôlés par version. La gestion des artefacts est une bonne pratique pour les mêmes raisons que la gestion du code source contrôlé par version. Parmi les exemples de référentiels d'artefacts, citons JFrog Artifactory et Nexus Repository, Azure Artifacts, Amazon Elastic Container Registry, Cloudsmith, Dist, ProGet et Yarn.

Moteurs de pipeline CI/CD. CI/CD permet aux équipes DevOps de valider et de livrer fréquemment des applications à l'utilisateur final grâce à l'automatisation au cours du cycle de développement. L'outil d'intégration continue initialise les processus afin que les développeurs puissent créer, tester et valider le code dans un référentiel partagé aussi souvent que nécessaire sans travail manuel. La livraison continue prolonge ces étapes automatiques par des tests au niveau de la production et des configurations pour la gestion des versions. Le déploiement continu va plus loin, en faisant appel à des tests, à la configuration et à l'approvisionnement, ainsi qu'à des capacités de surveillance et de retour en arrière éventuel. Les outils courants pour le CI, le CD ou les deux comprennent Jenkins, GitLab, Travis CI, Atlassian Bamboo, Concourse et CircleCI.

Conteneurs. Les conteneurs sont des environnements d'exécution isolés pour les logiciels sur un système d'exploitation partagé. Les conteneurs fournissent une abstraction qui permet au code de fonctionner de la même manière sur différentes infrastructures sous-jacentes, du développement aux tests et à la mise en scène, puis à la production. Docker et Apache Mesos comptent parmi les logiciels de conteneurisation les plus connus, tandis que Microsoft propose des options de conteneur Windows spécifiques. Les orchestrateurs de conteneurs, tels que Kubernetes et les distributions commerciales de Kubernetes, Red Hat OpenShift et Amazon Elastic Kubernetes Service, déploient, mettent à l'échelle et maintiennent les conteneurs automatiquement.

Gestion de la configuration. Les systèmes de gestion de la configuration permettent à l'équipe informatique d'approvisionner et de configurer les logiciels, les intergiciels et l'infrastructure sur la base d'un script ou d'un modèle. L'équipe DevOps peut mettre en place des environnements de déploiement pour les versions de code logiciel et appliquer des politiques sur les serveurs, les conteneurs et les machines virtuelles par le biais d'un outil de gestion de la configuration. Les modifications apportées à l'environnement de déploiement peuvent être contrôlées par version et testées, ce qui permet aux équipes DevOps de gérer l'infrastructure en tant que code (IaC). Les outils de gestion de la configuration comprennent Ansible, Terraform, SaltStack, Puppet et Chef.

Environnements cloud. Les organisations DevOps adoptent souvent en même temps une infrastructure cloud car elles peuvent automatiser son déploiement, sa mise à l'échelle et d'autres tâches de gestion. AWS, Google Cloud et Microsoft Azure sont parmi les fournisseurs de cloud les plus utilisés. De nombreux fournisseurs de cloud proposent également des services CI/CD.

Surveillance. En outre, les outils de surveillance permettent aux professionnels du DevOps d'observer les performances et la sécurité des versions de code sur les systèmes, les réseaux et l'infrastructure. Ils peuvent combiner la surveillance avec des outils d'analyse qui fournissent des informations opérationnelles. Les équipes DevOps utilisent ces outils ensemble pour analyser la manière dont les modifications apportées au code affectent l'environnement global. Les choix sont vastes, mais incluent New Relic One, Dynatrace, Prometheus, Datadog et Splunk.

Pipelines DevOps basés sur le cloud. Les fournisseurs de cloud public proposent des outils DevOps natifs à utiliser avec les charges de travail sur leurs plateformes. Une liste incomplète comprend AWS CodePipeline et CloudFormation, Azure DevOps et Pipelines et Google Cloud Deployment Manager. Les adeptes du cloud ont la possibilité d'utiliser ces services pré-intégrés ou d'utiliser des outils tiers. Par exemple, une organisation peut utiliser HashiCorp Terraform ou CloudFormation pour créer des modèles IaC pour ses charges de travail AWS.

Modèles "as-a-service". Enfin, DevOps en tant que service est un modèle de livraison d'un ensemble d'outils qui facilite la collaboration entre l'équipe de développement de logiciels d'une organisation et l'équipe d'exploitation informatique. Dans ce modèle de livraison, le fournisseur assemble une suite d'outils et s'occupe des intégrations pour couvrir de manière transparente le processus global de création, de livraison et de maintenance du code.

Dans d'autres cas, les fournisseurs de services DevOps-as-a-service agissent comme des consultants qui peuvent aider les entreprises avec des projets DevOps, ou compléter l'expertise qui pourrait manquer à n'importe quel endroit du processus DevOps. Tout fournisseur de services doit être évalué en fonction de facteurs tels que l'ancienneté de l'entreprise, l'expérience avérée - en particulier dans les secteurs verticaux du marché - et la compatibilité avec les outils et les pratiques DevOps existants.

Compétences et rôles professionnels DevOps

On dit souvent que DevOps est davantage une philosophie ou une culture informatique collaborative, plutôt qu'une description de poste ou un ensemble de compétences strictement défini. Le domaine étant très vaste, les postes DevOps conviennent mieux aux généralistes de l'informatique qu'aux spécialistes.

Le rôle d'ingénieur DevOps ne s'inscrit pas dans une seule voie de carrière. Les professionnels peuvent accéder à ce poste à partir de divers horizons. Par exemple, un développeur de logiciels peut acquérir des compétences en matière d'opérations, telles que la configuration de l'infrastructure d'hébergement, pour devenir ingénieur DevOps. De même, un administrateur système ayant des connaissances en matière de codage, de script et de test peut devenir ingénieur DevOps.

De nombreuses offres d'emploi DevOps requièrent des connaissances en matière de conteneurs, de cloud et de CI/CD, ainsi que des compétences non techniques telles que la communication et la direction d'équipe. Un ingénieur DevOps peut également être amené à modifier des processus et à résoudre des problèmes organisationnels pour atteindre des résultats commerciaux.

Parmi les autres titres que l'on trouve souvent dans les organisations DevOps, on peut citer les suivants :

• Développeur d'infrastructures.
• Consultant en cloud computing.
• Ingénieur en fiabilité des sites.
• Architecte DevOps.
• Ingénieur de construction et de mise en service.
• Développeur full-stack.
• Spécialiste de l'automatisation.
• Ingénieur plateforme CI/CD.

Ne jugez pas le poste par son titre. Les rôles peuvent varier considérablement. Prenez donc le temps d'examiner la formation spécifique, les exigences du poste et l'expérience souhaitée pour chaque type d'opportunité.

La plupart des emplois DevOps de niveau débutant requièrent un diplôme en informatique ou dans un domaine connexe qui couvre le codage, les tests d'assurance qualité et les composants de l'infrastructure informatique. Les postes de niveau supérieur peuvent nécessiter des diplômes avancés en architecture de systèmes et en conception de logiciels. Les personnes qui s'engagent dans cette voie devraient également approfondir leurs connaissances en lisant des ouvrages sur le DevOps et en se mettant en contact avec d'autres membres de la communauté par l'intermédiaire de blogs et de conférences.

Il n'existe pas de certifications DevOps reconnues à l'échelle de l'industrie, comme c'est le cas pour les cadres formalisés tels que l'ITIL. IBM Red Hat propose une certification DevOps, tandis que le DevOps Institute propose des options neutres pour les niveaux allant des connaissances de base à l'expertise.