Tutoriel DevOps : Docker, Kubernetes et Azure DevOps

Dans cet article, nous allons apprendre sur le DevOps et comment il diffère de la méthodologie Agile. Nous couvrirons également quelques outils DevOps populaires et leurs rôles dans le cycle de vie DevOps.

Vous apprendrez

  • Qu’est-ce que Docker, Kubernetes et Azure DevOps
  • Qu’est-ce que le DevOps et pourquoi en avons-nous besoin ?
  • En quoi le DevOps diffère-t-il de l’Agile ?
  • Quels sont quelques outils DevOps importants ?
  • Comment Docker aide-t-il le DevOps ?
  • Comment Kubernetes aide-t-il le DevOps ?
  • Comment Azure DevOps aide-t-il le DevOps ?
  • Qu’est-ce que l’Intégration Continue et la Livraison Continue (CI/CD) ?
  • Qu’est-ce que l’Infrastructure en tant que Code ?
  • Comment Terraform et Ansible aident-ils le DevOps ?

Docker

Docker est un outil logiciel open-source utilisé pour construire, tester et déployer des applications conteneurisées. Qu’est-ce que la Conteneurisation, au fait ? La Conteneurisation est le concept de regrouper toutes les bibliothèques et fichiers avec le code de l’application dans une seule unité appelée « Conteneur » afin qu’elle puisse s’exécuter sur n’importe quelle infrastructure.

Kubernetes

Kubernetes est un système d’orchestration de conteneurs qui gère les applications et services conteneurisés. Il s’occupe des tâches effectuées dans l’environnement conteneurisé telles que le dimensionnement, le déploiement, l’équilibrage de charge, etc. Kubernetes est portable, efficace et rentable, et offre des fonctionnalités telles que des intégrations système, un support basé sur API, etc.

Azure DevOps

Azure DevOps est un produit Microsoft qui propose une large gamme d’outils et de fonctionnalités qui rendent le processus de développement et de déploiement de logiciels plus rapide et plus organisé. Il offre un ensemble de processus qui permet aux développeurs de logiciels, aux chefs de projet et aux autres contributeurs de travailler ensemble pour développer des logiciels. Il peut être ajouté aux éditeurs ou environnements de développement intégrés existants pour permettre à l’équipe de travailler efficacement sur des projets de toutes tailles.

Commençons par un cas d’utilisation simple.

Cours Gratuits — Apprenez en 10 Étapes

Qu’est-ce que DevOps?

Comme pour la plupart des mots à la mode dans le développement logiciel, il n’existe pas de définition acceptée pour DevOps.

Les définitions varient du simple, comme celle ci-dessous, au complexe, qui peut s’étendre sur toute une page de livre.

DevOps est la combinaison de philosophies culturelles, de pratiques et d’outils qui augmentent la capacité d’une organisation à livrer des applications et des services à haute vélocité — Amazon Web Services (AWS)

Au lieu d’essayer de définir DevOps, comprenons comment le développement logiciel a évolué vers DevOps.

Modèle en cascade

Le modèle en cascade est une méthodologie qui suit une approche structurée. Il se compose de six phases : Exigences, Conception, Implémentation, Test, Déploiement et Maintenance. Chaque phase s’appuie sur la réalisation de la précédente. Il progresse à travers ces étapes sans revenir sur les processus antérieurs, en faisant un processus linéaire.

Les premières décennies du développement logiciel étaient centrées autour du modèle en cascade, et il abordait le développement logiciel de la même manière que vous aborderiez la construction d’un projet immobilier — par exemple, construire un pont.

Vous développerez un logiciel en plusieurs phases pouvant durer de quelques semaines à quelques mois.

Dans la plupart des projets en cascade, il faudrait des mois avant que l’entreprise ne voie une version fonctionnelle d’une application.

Éléments clés pour construire un excellent logiciel

En travaillant dans le modèle en cascade depuis quelques décennies, nous comprenons quelques éléments clés autour du développement de logiciels de qualité :

  • Communication
  • Feedback
  • Automatisation

Importance de la communication

La communication entre les personnes est essentielle pour le succès d’un projet logiciel.

Dans le modèle en cascade, nous avons essayé d’améliorer la communication en préparant des documents de 1000 pages sur les exigences, la conception, l’architecture et le déploiement.

Mais, au fil du temps, nous avons découvert que :

  • La meilleure façon d’améliorer la communication au sein d’une équipe est de les réunir. Et d’avoir une variété de compétences au sein de la même équipe.
  • Les équipes pluridisciplinaires – avec une large gamme de compétences – fonctionnent très bien.

Importance des retours précoces

Obtenir rapidement des retours est important. Construire un logiciel de qualité implique d’obtenir des retours rapides.

  • Est-ce que nous développons une application qui répond aux attentes de l’entreprise ?
  • Votre application rencontrera-t-elle des problèmes si elle est déployée en production ?

Vous ne voulez pas le découvrir après quelques mois. Vous voulez le découvrir le plus tôt possible car plus tôt nous détectons un problème, plus il est facile de le corriger.

Nous avons constaté que les meilleures équipes logicielles sont structurées pour permettre des retours rapides.

Importance de l’automatisation

L’automatisation est cruciale. Le développement logiciel implique une large gamme d’activités. Faire les choses manuellement est lent et sujet aux erreurs. Nous comprenons qu’il est essentiel de toujours rechercher des opportunités pour introduire l’automatisation.

Ayant compris les éléments clés pour développer un excellent logiciel, regardons comment nous sommes passés à l’Agile et au DevOps.

Évolution vers l’Agile

L’Agile est une approche qui met l’accent sur les progrès incrémentiels, les retours fréquents et la capacité de répondre aux exigences changeantes tout au long du cycle de développement. L’Agile favorise les équipes pluridisciplinaires pour travailler dans de courts cycles de développement, ce qui favorise l’amélioration continue et fournit de la valeur aux utilisateurs finaux rapidement. C’était la première étape dans l’évolution vers la mise en œuvre de nos apprentissages avec une communication améliorée entre les équipes, l’obtention de retours et l’introduction de l’automatisation. 

L’Agile a réuni les équipes commerciales et de développement au sein d’une même équipe, qui travaille pour construire un excellent logiciel en petites itérations appelées Sprints.

Au lieu de passer des semaines ou des mois sur chaque phase de développement, l’Agile se concentre sur la prise en charge de petites exigences appelées user stories tout au long du cycle de développement en quelques jours, parfois dans la même journée.

Comment l’Agile a-t-il amélioré la communication entre les équipes?

L’Agile a réuni les équipes commerciales et de développement.

  • Les entreprises sont responsables de définir ce qu’il faut construire. Quelles sont les exigences?
  • Le développement est responsable de construire un produit qui répond aux exigences. Le développement inclut tout le monde impliqué dans la conception, la programmation, les tests et l’emballage de votre logiciel.

En Agile, un représentant de l’entreprise, appelé Product Owner, est toujours présent avec l’équipe, et l’équipe comprend clairement les objectifs de l’entreprise.

Lorsque l’équipe de développement ne comprend pas les exigences et prend une mauvaise direction, le Product Owner les aide à corriger le tir et à rester sur la bonne voie.

Résultat : Le produit final construit par l’équipe est ce que l’entreprise veut.

Un autre facteur important est que les équipes agiles possèdent des compétences transversales : compétences en codage (frontend, API et bases de données), compétences en test et compétences métier. Cela améliore la communication entre les personnes qui doivent travailler ensemble pour construire un logiciel de qualité.

Agile et Automatisation

Sur quels domaines d’automatisation les équipes agiles se concentrent-elles ?

Les produits logiciels peuvent présenter divers défauts :

  • Les défauts fonctionnels signifient que le produit ne fonctionne pas comme prévu.
  • Les défauts techniques rendent la maintenance du logiciel difficile. Par exemple, des problèmes de qualité de code.

En général, les équipes agiles sont focalisées sur l’utilisation de l’automatisation pour détecter le plus tôt possible les défauts techniques et fonctionnels.

Les équipes agiles accordent également une grande importance à la qualité du code. Des outils comme SONAR sont utilisés pour évaluer la qualité du code des applications.

Est-il suffisant d’avoir de grands tests d’automatisation et de grands contrôles de qualité de code? La clé est d’exécuter ces processus fréquemment. Les équipes agiles mettent l’accent sur l’Intégration Continue, où les commits dans le contrôle de version déclenchent une série d’actions. Cela inclut l’exécution de tests unitaires, de tests d’automatisation et de contrôles de qualité de code, tous intégrés de manière transparente dans un Pipeline d’Intégration Continue. Jenkins, un outil CI/CD largement adopté pendant l’ère Agile précoce, a joué un rôle crucial dans l’orchestration de ces processus automatisés.

Comment Agile a-t-il favorisé un retour immédiat?

Le facteur le plus important est qu’une entreprise n’a pas besoin d’attendre des mois pour voir le produit final. À la fin de chaque sprint, le produit est présenté à tous les parties prenantes, y compris les équipes d’architecture et de business. Tous les retours sont pris en compte en priorisant les user stories pour le sprint suivant. Résultat : le produit final construit par l’équipe est ce que l’entreprise veut.

Un autre facteur important qui permet un retour immédiat est l’intégration continue. Disons que je commets du code dans le contrôle de version. Dans les 30 minutes, je reçois un retour si mon code provoque un échec de test unitaire ou un échec de test d’intégration. Je recevrai un retour si mon code ne respecte pas les normes de qualité de code ou n’a pas suffisamment de couverture de code dans les tests unitaires.

L’Agile a-t-il été un succès? Oui. Certainement. En se concentrant sur l’amélioration de la communication entre les équipes business et de développement, et en se concentrant sur la détection précoce d’une variété de défauts, l’Agile a amené le développement logiciel à un niveau supérieur.

J’ai eu une expérience merveilleuse en travaillant avec des équipes incroyables utilisant la méthode Agile. L’ingénierie logicielle, qui pour moi représente tous les efforts déployés pour construire des logiciels, des exigences à la mise en production des applications, a été aussi agréable que la programmation pour la première fois.

Mais l’évolution s’arrête-t-elle ? Non.

De nouveaux défis sont apparus.

Évolution des architectures de microservices

Nous avons commencé à nous orienter vers une architecture de microservices, et nous avons commencé à construire plusieurs petites API au lieu de créer de grandes applications monolithiques.

Quel était le nouveau défi ?

Les opérations sont devenues plus importantes. Au lieu de faire une mise en production monolithique par mois, vous réalisez des centaines de petites mises en production de microservices chaque semaine. Le débogage des problèmes à travers les microservices et l’obtention de visibilité sur ce qui se passe avec les microservices sont devenus importants.

Il était temps pour un nouveau mot à la mode dans le développement logiciel. DevOps.

Émergence de DevOps

Quel était le focus de DevOps ?

Le focus de DevOps était d’améliorer la communication entre les équipes de développement et d’opérations.

  • Comment rendons-nous les déploiements plus faciles ?
  • Comment rendons-nous le travail de l’équipe d’opérations plus visible pour l’équipe de développement ?

Comment DevOps a-t-il amélioré la communication entre les équipes ?

DevOps a rapproché les équipes d’opérations des équipes de développement.

  • Dans les entreprises plus matures, les équipes de développement et d’exploitation travaillaient ensemble. Ils ont commencé à partager des objectifs communs et les deux équipes ont commencé à comprendre les défis auxquels l’autre équipe était confrontée.
  • Dans les entreprises, au stade initial de l’évolution de DevOps, un représentant de l’équipe des opérations peut être impliqué dans les sprints – les réunions debout et les rétrospectives.

Sur quels domaines d’automatisation les équipes DevOps se concentrent-elles?

En plus des domaines de focus de l’Agile – Intégration Continue et automatisation des tests – les équipes DevOps se sont concentrées sur l’aide à l’automatisation de plusieurs activités de l’équipe des opérations comme la provision de serveurs, la configuration des logiciels sur les serveurs, le déploiement des applications et la surveillance des environnements de production. Quelques termes clés sont le déploiement continu, la livraison continue et l’infrastructure en tant que code.

Le déploiement continu consiste à déployer continuellement une nouvelle version du logiciel sur les environnements de test. Dans des organisations encore plus matures comme Google et Facebook, la livraison continue aide à déployer continuellement des logiciels en production – peut-être des centaines de déploiements en production par jour.

L’infrastructure en tant que code consiste à traiter votre infrastructure comme vous traitez votre code d’application. Vous créez votre infrastructure – serveurs, équilibreurs de charge et base de données – de manière automatisée en utilisant une configuration. Vous versionnez votre infrastructure – afin de pouvoir suivre les changements de votre infrastructure sur une certaine période.

Comment DevOps a-t-il favorisé la rétroaction immédiate?

DevOps rapproche les équipes d’opérations et de développement. Parce que les opérations et le développement font partie de la même équipe, toute l’équipe comprend les défis associés aux opérations et au développement.

  • Tout problème opérationnel reçoit rapidement l’attention des développeurs.
  • Tous les défis liés à la mise en production de logiciels attirent rapidement l’attention de l’équipe des opérations.

DevOps encourage l’intégration continue, la livraison continue et l’infrastructure en tant que code.

  • Grâce à la livraison continue, si je fais un changement de code ou un changement de configuration qui pourrait casser un test ou un environnement de staging, je le saurais dans quelques heures.
  • Grâce à l’infrastructure en tant que code, les développeurs peuvent auto-provisionner des environnements, déployer du code et trouver des problèmes par eux-mêmes sans l’aide de l’équipe des opérations.

Je vois Agile et DevOps comme deux phases qui nous aident à améliorer la manière dont nous construisons de grands logiciels. Ils ne s’opposent pas, mais ensemble, ils nous aident à créer des produits logiciels incroyables.

Pour ce qui me concerne, l’objectif d’Agile et de DevOps ensemble est de faire des choses qui :

  • Favorisent la communication et les retours d’expérience entre les équipes commerciales, de développement et d’opérations.
  • Atténuent les points de douleur grâce à l’automatisation.

Une histoire DevOps

Voici un exemple d’histoire :

  • Vous êtes le développeur vedette d’une équipe, et vous devez effectuer un correctif rapide.
  • Vous allez dans un dépôt GitHub.
  • Vous vérifiez rapidement le projet.
  • Vous créez rapidement votre environnement local.
  • Vous apportez une modification. Vous la testez. Vous mettez à jour les tests unitaires et d’automatisation.
  • Vous l’engagez.
  • Vous recevez un email indiquant qu’elle est déployée en QA.
  • Quelques tests d’intégration sont exécutés automatiquement.
  • Votre équipe QA reçoit un email demandant une approbation. Ils effectuent un test manuel et approuvent.
  • Votre code est en production en quelques minutes.
  • Vous pourriez penser que c’est un scénario idéal. Mais, savez-vous que c’est ce qui se passe dans des entreprises innovantes comme Netflix, Amazon et Google jour après jour ?

C’est l’histoire de DevOps.

DevOps = Développement + Opérations

DevOps est une évolution naturelle du développement logiciel. DevOps n’est PAS JUSTE un outil, un cadre ou juste de l’automatisation. C’est une combinaison de tout cela.

DevOps se concentre sur les personnes, les processus et les produits. La partie humaine de DevOps concerne la culture et la création d’un bon état d’esprit — une culture qui promeut la communication ouverte et valorise les retours rapides, une culture qui valorise un logiciel de haute qualité.

Agile a aidé à combler le fossé entre les équipes commerciales et de développement. Les équipes de développement ont compris les priorités de l’entreprise et ont travaillé avec elle pour délivrer les histoires apportant le plus de valeur en premier ; cependant, les équipes dev et ops n’étaient pas alignées.

Elles avaient des objectifs différents.

  • L’objectif de l’équipe de développement est de mettre en production autant de nouvelles fonctionnalités que possible.
  • L’objectif de l’équipe des opérations était de maintenir l’environnement de production aussi stable que possible.

Comme vous pouvez le constater, s’il est difficile de passer à la production, le développement et les opérations ne sont pas alignés.

DevOps vise à aligner les équipes de développement et d’opérations avec des objectifs communs.

L’équipe de développement travaille avec l’équipe des opérations pour comprendre et résoudre les défis opérationnels. L’équipe des opérations fait partie de l’équipe Scrum et comprend les fonctionnalités en cours de développement.

Comment pouvons-nous rendre cela possible ? Abattez le mur entre le développement et les opérations !

Rapprocher le développement et les opérations

Option 1

Dans les entreprises DevOps matures, le développement et les opérations travaillent au sein de la même équipe Scrum et partagent les responsabilités de chacun.

Option 2

Cependant, si vous êtes aux premiers stades de l’évolution DevOps, comment pouvez-vous amener le développement et les opérations à avoir des objectifs communs et travailler ensemble ?

Voici quelques actions que vous pouvez entreprendre :

  • Amener l’équipe de développement à partager certaines des responsabilités de l’équipe opérationnelle. Par exemple, l’équipe de développement peut prendre en charge les nouvelles versions la première semaine après le déploiement en production. Cela aide l’équipe de développement à comprendre les défis auxquels sont confrontées les opérations pour mettre en service de nouvelles versions et les aide à travailler ensemble pour trouver de meilleures solutions.
  • Une autre action que vous pouvez entreprendre est d’impliquer un représentant de l’équipe des opérations dans les activités Scrum. Impliquez-les dans les réunions debout et les rétrospectives.
  • La prochaine chose que vous pouvez faire est de rendre les défis auxquels l’équipe des opérations est confrontée plus visibles pour l’équipe de développement. Lorsque vous rencontrez des défis dans les opérations, faites en sorte que les équipes de développement fassent partie des équipes travaillant sur des solutions.

Quel que soit le chemin que vous empruntez, trouvez des moyens de briser le mur et de rassembler l’équipe de développement et l’équipe des opérations.

Une autre option intéressante émerge grâce à l’automatisation. En utilisant l’infrastructure en tant que code et en permettant l’auto-provisionnement pour les développeurs, vous pouvez créer un langage commun que les équipes des opérations et de développement comprennent — le code.

Un cas d’utilisation DevOps

Considérez l’image ci-dessous :

Cette image montre deux flux de travail simples

  1. Infrastructure en tant que code utilisant Terraform et Azure DevOps pour provisionner des clusters Kubernetes.
  2. Déploiement continu de microservices utilisant Azure DevOps pour construire et déployer des images Docker pour des microservices dans des clusters Kubernetes.

Cela semble-t-il complexe ?

Décomposons cela et essayons de les comprendre.

Commençons par #2 — Déploiement continu d’abord.

#2 : Déploiement continu DevOps avec Azure DevOps et Jenkins

À quoi bon avoir de bons tests et des contrôles de qualité de code si vous ne les exécutez pas souvent ?

À quoi bon l’automatisation du déploiement si vous ne déployez pas le logiciel assez souvent ?

Dès qu’un développeur commet du code dans le système de contrôle de version, les étapes suivantes sont exécutées :

  • Tests unitaires
  • Contrôles de qualité du code
  • Tests d’intégration
  • Emballage d’application — Construction d’une version déployable de l’application. Outils — Maven, Gradle, Docker
  • Déploiement d’application — Mise en ligne de nouvelles applications ou de nouvelles versions de l’application
  • Un e-mail à l’équipe de test pour tester l’application

Dès qu’il y a l’approbation de l’équipe de test, l’application est immédiatement déployée dans l’environnement suivant.

Ceci s’appelle le déploiement continu. Si vous déployez continuellement jusqu’en production, cela s’appelle la livraison continue.

Les outils CI/CD les plus populaires sont Azure DevOps et Jenkins.

#1 : Infrastructure DevOps en tant que code avec Terraform

Auparavant, nous avions l’habitude de créer des environnements et de déployer des applications manuellement.

Chaque fois que vous créez un serveur, cela doit être fait manuellement.

  • La version du logiciel doit être mise à jour
  • Les correctifs de sécurité doivent être installés manuellement

Vous le faites manuellement, et voici les résultats :

  • Fortes chances d’erreurs
  • Les environnements de réplication sont difficiles

Infrastructure en tant que code

Infrastructure en tant que code — traiter l’infrastructure de la même manière que le code d’application.

Voici certaines choses importantes à comprendre avec l’infrastructure en tant que code :

  • L’équipe d’infrastructure se concentre sur le travail à valeur ajoutée (au lieu du travail routinier)
  • Moins d’erreurs et récupération rapide des failles
  • Les serveurs sont cohérents (évite la dérive de configuration)

Les outils les plus populaires d’IaC sont Ansible et Terraform.

Typiquement, voici les étapes de l’IaC :

  • Provisionnement des serveurs (activé par le Cloud) à partir d’un modèle
  • Installer des logiciels
  • Configurer des logiciels

Provisionnement de serveurs

Typiquement, des outils de provisionnement sont utilisés pour provisionner des serveurs et préparer le nouveau serveur avec des capacités réseau. Les outils de provisionnement les plus populaires sont Cloud Formation et Terraform.

Avec Terraform, vous pouvez provisionner des serveurs et le reste de votre infrastructure, comme des équilibreurs de charge, des bases de données, des configurations réseau, etc. Vous pouvez créer des serveurs en utilisant des images pré-créées réalisées avec des outils comme Packer et AMI (Image de Machine Amazon).

Gestion de configuration

Les outils de gestion de configuration sont utilisés pour :

  • Installer des logiciels
  • Configurer des logiciels

Les outils de gestion de configuration populaires sont Chef, Puppet, Ansible et SaltStack. Ceux-ci sont conçus pour installer et gérer des logiciels sur des serveurs existants.

Rôle de Docker et Kubernetes dans DevOps

Dans le monde des microservices, quelques microservices peuvent être construits avec Java, quelques-uns avec Python, et quelques-uns avec JavaScript.

Différents microservices auront différentes manières de construire des applications et de les déployer sur des serveurs. Cela rend le travail de l’équipe des opérations difficile. Comment pouvons-nous avoir une méthode similaire pour déployer plusieurs types d’applications ? Entrez les conteneurs et Docker.

Avec Docker, vous pouvez créer des images de microservices — indépendamment de leur langage. Vous pouvez exécuter ces images de la même manière sur n’importe quelle infrastructure. Cela simplifie les opérations.

Kubernetes ajoute à cela en aidant à orchestrer différents types de conteneurs et en les déployant dans des clusters.

Kubernetes fournit également :

  • Découverte de services
  • Équilibrage de charge
  • Configuration centralisée

Docker et Kubernetes facilitent DevOps.

Métriques DevOps importantes

Voici quelques-unes des métriques DevOps importantes que vous pouvez suivre et améliorer au fil du temps.

  • Fréquence de déploiement — À quelle fréquence les applications sont-elles déployées en production ?
  • Temps de mise sur le marché — Combien de temps avez-vous besoin pour passer d’une fonctionnalité de la phase de codage à la production ?
  • Taux d’échec des nouvelles versions — Combien de vos versions échouent ?
  • Délai de correction — Combien de temps avez-vous besoin pour effectuer une correction en production et la déployer ?
  • Temps moyen de récupération — Combien de temps prenez-vous pour récupérer votre environnement de production après un problème majeur ?

Meilleures pratiques DevOps

Gestion de projet Agile

La gestion de projet Agile est une approche itérative pour le développement d’applications logicielles. Grâce à cette pratique, les équipes peuvent améliorer la vitesse de développement et répondre efficacement aux besoins variés des clients. La méthodologie Agile est différente de la méthode traditionnelle en cascade, où il y avait de longs cycles de publication. Agile utilise les cadres Scrum et Kanban pour livrer le logiciel selon les besoins du client.

Utilisation du bon ensemble d’outils

Les développeurs de logiciels et les administrateurs système doivent choisir et utiliser le bon ensemble d’outils DevOps à chaque étape du cycle de vie DevOps pour construire des applications à forte valeur ajoutée.

Voici quelques exemples d’outils que les ingénieurs DevOps, les administrateurs système et d’autres parties prenantes peuvent utiliser :

  1. Des outils comme Jira peuvent aider l’équipe à diviser les tâches en morceaux plus petits et plus gérables, ce qui contribue à augmenter la productivité de l’équipe.
  2. Des outils comme Jenkins et Bitbucket peuvent vous aider à automatiser les flux de code, de la phase de test à la phase de déploiement.
  3. Des outils comme Slack, GetFeedback, etc. peuvent aider les équipes DevOps à intégrer des outils de discussion avec des plateformes d’enquête pour collecter et examiner des retours en temps réel.

Intégration continue/Livraison continue

L’intégration continue (CI) et la livraison continue (CD) sont des pratiques modernes de développement logiciel qui aident les organisations à livrer rapidement et efficacement des logiciels. Avec la CI, les développeurs commettent continuellement le code de l’application dans un référentiel partagé plusieurs fois. Avec la CD, le code est livré rapidement et sans heurts en production. La CD garantit également que l’intégration se fait sans retards ni problèmes.

Intégration de la sécurité

La sécurité est une partie importante du processus de développement logiciel. Dans le monde actuel, où les cybercrimes et les incidents de violations de données sont en hausse, les organisations réalisent l’importance d’intégrer la sécurité dans leurs systèmes. Dans le passé, la sécurité était généralement considérée lors des dernières phases du cycle de vie du développement logiciel, mais avec l’avènement de DevSecOps, la sécurité est envisagée et intégrée dès le premier jour du développement de l’application.

Observabilité

L’observabilité est importante lors du développement d’applications complexes utilisant des architectures de microservices et de cloud. L’observabilité aide les équipes DevOps à comprendre la structure complexe des différentes applications (microservices, applications cloud, etc.) et aide à répondre aux besoins futurs de l’environnement. L’observabilité Kubernetes et Splunk sont quelques-unes des meilleures plateformes d’observabilité.

Signaux de maturité DevOps

Comment mesurez-vous la maturité de vos implémentations DevOps ?

  • Le temps pris depuis le processus de développement jusqu’au déploiement devrait être globalement satisfaisant
  • Déterminer la fréquence des nouveaux déploiements de code
  • Le temps moyen de récupération (MTTR) après un incident ou un événement inattendu devrait être aussi bas que possible
  • Les déploiements réussis devraient surpasser les déploiements échoués.
  • Des versions plus rapides et fiables devraient générer un retour sur investissement élevé (ROI).

Meilleures pratiques de transformation DevOps

  • L’adhésion de la direction est cruciale
  • Implique des coûts initiaux
  • Configurer des centres d’excellence pour aider les équipes
  • Choisir la bonne application et l’équipe
  • Commencer petit
  • Partager les apprentissages (bulletins d’information, communication, COEs)
  • Encourager les personnes ayant une mentalité d’exploration et d’automatisation
  • Reconnaître les équipes DevOps

Source:
https://dzone.com/articles/devops-tutorial-devops-with-docker-kubernetes-and