Guide DevOps pour les débutants !

1. Introduction aux DevOps: Bienvenue dans ce cours Skillshare sur le DevOps pour débutants. Si vous êtes curieux de savoir ce qu'est le DevOps, les outils et les technologies qu'il implique et comment il façonne le secteur des technologies, vous êtes au bon endroit Dans ce cours, nous aborderons les principes fondamentaux du DevOps, ce que c'est et pourquoi il est important, principaux objectifs d'apprentissage tels compréhension de l'automatisation, du CSED et de l'infrastructure en tant que code, une feuille de route claire pour vous guider étape par étape dans votre parcours d'apprentissage du DevOps, une introduction aux outils et technologies qui alimentent le DevOps, tels que Jenkins, Doc Cela vous donne une solide compréhension de ce qui est utilisé dans l'industrie. Ce cours est conçu pour les débutants absolus, que vous soyez un étudiant, un développeur souhaitant se développer ou un débutant en technologie. Ce cours vous permettra, à la fin de ce cours, comprendre les concepts essentiels du DevOps, d' avoir un aperçu des outils et de la technologie disposer de la feuille de route pour continuer à apprendre et à développer des compétences pratiques et d'être à la hauteur du rôle Alors, plongeons-nous dans le vif du sujet et lançons votre parcours DevOps. 2. 0101 La création du moment DevOps: Les développeurs DevOps Dev s'occupent des opérations informatiques. Les développeurs ont tendance à avoir les responsabilités suivantes. Ils codent l' application en fonction des exigences ou des témoignages des utilisateurs pour ce sprint. Ils vont ensuite créer le projet pour créer un artefact ou un exécutable, qui pourra ensuite être déployé sur le serveur ou inscription au développement pour tester leurs modifications Ils sont également chargés de tester l' ensemble de l'application, s' assurer que toutes les fonctionnalités fonctionnent comme prévu et qu'aucune des fonctionnalités n'a été interrompue en raison des modifications récemment introduites. Si vous disposez d'une équipe d'assurance qualité distincte, elle se chargera de tester minutieusement l'application. autre côté, l'équipe des opérations informatiques aurait un ensemble de responsabilités différent. Ils sont chargés de déployer l'application dans l'environnement de préparation ou de production afin que l'application puisse désormais être utilisée par le client ou l'utilisateur final. Ils sont également responsables de la maintenance de l'infrastructure requise pour déployer l'application. Ils vont s' assurer qu'il s'agit serveurs et de ressources adéquats pour permettre à l' application de fonctionner de manière fluide. Ils surveillent également en permanence les performances des applications, état, l'utilisation des ressources, avertissements, les erreurs, etc. Non, le déploiement de l'application n' est pas une tâche facile. Ce n'est pas que vous copiez l'artefact sur votre serveur et cela fonctionne comme par magie Vous devez prendre soin des dépendances, des bibliothèques, des configurations qui aideront à exécuter l'application. Souvent, l'équipe des opérations n'est pas familière avec ces étapes et demande donc l'aide des développeurs Les développeurs fourniraient donc un guide de déploiement contenant des instructions claires étape par étape sur la manière de déployer l'application. Ostam suivrait ces étapes, déploierait l'application, et celle-ci serait parfaitement opérationnelle Jusqu'à une nuit, l'application se bloque ou certaines fonctionnalités tombent en panne Cela mène au célèbre jeu de blâme où l'OpSteam dirait qu'elle a suivi toutes les instructions du guide de déploiement, et si l' application ne fonctionne toujours pas, c'est aux développeurs de décider autre côté, les développeurs vont rejeter la faute sur OpSteam en disant qu'ils ont suivi les étapes exactes du guide de déploiement et que cela a fonctionné pour eux lors de leur inscription au développement Donc, le blâme reviendrait et ferait perdre beaucoup de temps. Mais la vérité est que l' erreur peut être commise par n'importe qui. Il se peut que les développeurs raté une étape du guide de déploiement, l'équipe des opérations n'ait pas bien suivi les instructions, ou que équipe des opérations n'ait pas bien suivi les instructions, cela ait quelque chose à voir avec l'allocation des ressources, ou peut-être que l' OpSteam ait installé une version différente du logiciel qui n' est pas prise en charge, ou en fait, cela peut également être un bogue dans le code Peut-être que les développeurs ont commis une erreur. Par exemple, les développeurs ont peut-être écrit un code incorrect, qui consomme constamment de la mémoire au point que le système en manquerait et que l' application se bloque Cela peut ne pas se produire lors inscription au développement, car ils n'exécutent pas l'application assez longtemps pour qu'elle se bloque, car ils continuent redéployer l'application comme lorsqu'ils introduisent des modifications Toutefois, cela peut se produire lors de l'inscription à la production, lorsque l'application serait constamment exécutée pendant une longue période. En tant que développeur par le passé, c'est en fait très frustrant d'entendre quelque chose comme ça de la part de l'équipe Ops, car d'une manière générale, les développeurs sont déjà occupés implémenter les nouvelles fonctionnalités. Ils ont de nouveaux engagements, ils sont responsables devant leur patron et ils ne veulent pas fouiller dans les vieux journaux qui pourraient avoir une incidence sur leurs engagements actuels dans le cadre vieux journaux qui pourraient avoir une incidence sur leurs engagements actuels dans le de leurs projets Ils essaient donc d'éviter ces problèmes en blâmant simplement l'autre partie Et l'équipe des opérations fait de même. Mais ce jeu du blâme fait perdre beaucoup de temps, et de nombreux problèmes resteraient en suspens pendant une longue période Ainsi, même la sortie serait retardée de plusieurs semaines, voire parfois de plusieurs mois, ce qui provoquerait de la frustration chez les clients, et vous pouvez en deviner les conséquences. Cela signifie une perte de revenus et de réputation pour l'entreprise. C'est le déclencheur et le point de départ du moment Da WoPS 3. 0102 Qu'est-ce que DevOps: Alors, qu'est-ce que le DevOps ? Tout ce que nous pouvons faire pour améliorer l'efficacité de l'équipe, réduire les risques d'erreur pendant la production, améliorer la communication entre les équipes et encourager la communication entre les équipes interfonctionnelles, réduire le délai de publication ou améliorer le processus global, c'est ce qu'est le DevOps Et tout cela peut être accompli combinant l'état d'esprit, philosophies et pratiques culturelles, les outils et l'automatisation Et si vous me demandez, le DevOps a tellement évolué nos jours qu'il est moins lié à l'état d'esprit et aux philosophies culturelles qu'aux outils et Ce qui était initialement un changement de mentalité s'est transformé en outils et en automatisation, dont nous parlerons tout de suite. 4. 0103 Philosophies et pratiques de Mindset: Parlons de l'aspect mental du DevOps. Avant le DevOps, il existait une barrière psychologique entre les développeurs et les opérations informatiques, les développeurs se concentrant davantage sur l'écriture du code et se souciant pas de l'inscription sur laquelle l'application devait s'exécuter L'équipe des opérations, quant à elle, ne se donne jamais la peine de comprendre le fonctionnement de l'application, ses dépendances ou tout ce qui est lié au travail des développeurs Avec DeWops, cette barrière serait levée et les deux équipes comprendraient commun accord qu' elles travaillent réellement ensemble Ils commencent maintenant à croire qu' ils ne forment qu'une seule équipe. S'il y a quelqu'un à blâmer en cas de problème, il n'y a personne d'autre à blâmer qu'eux-mêmes. Ils vont résoudre les problèmes ensemble en tant qu'entité unique. En fait, dans certaines organisations, il n'existe pas d'équipe de développement et d'équipe opérationnelle distincte. Ils peuvent se faire appeler développeurs, mais ils font en fait le travail de développeurs et d'opérations informatiques. Maintenant, c'est l' aspect mental du DevOps. Parlons maintenant de certaines philosophies et pratiques culturelles du DevOps DevOps encourage la communication ouverte et la collaboration entre les équipes, partage des connaissances entre les membres de l'équipe Ainsi, les développeurs peuvent avoir une session de partage de connaissances avec l'équipe Ops et vice versa, OpStem peut avoir une session de partage de connaissances avec l'équipe de développement Réunions régulières avec des équipes interfonctionnelles telles que l'équipe de test, l'équipe de sécurité, etc. En fait, avant DevOps, Optimon n'a jamais pris la peine d' assister aux réunions des Mais aujourd'hui, ils sont réellement impliqués dans l'ensemble du cycle de vie du produit, dès la collecte des besoins. En fait, ils assistent également à la réunion pour discuter des exigences. Élargir leurs compétences. Les développeurs peuvent donc acquérir certaines compétences opérationnelles et vice versa. L'équipe Oups acquiert certaines des compétences des développeurs. Utilisation d'outils collaboratifs, dont nous parlerons dans un instant. Je dois mentionner que le DevOps n'est pas pratiqué de la même manière dans toutes les organisations Selon la portée du projet et le type de technologies qu'ils utilisent, pratiques et les outils DevOp peuvent différer 5. 0104 Environnements et outils DevOps: Les développeurs auraient besoin d'une inscription Dev pour tester leurs modifications ou pour leurs activités quotidiennes. De même, l'équipe de test aurait besoin d' une inscription aux tests pour tester l'application de manière approfondie. De même, IT OpStam aurait également besoin d'une inscription préalable ou d' un enregistrement en production pour déployer l'application Pour obtenir toutes ces inscriptions, nous aurions probablement besoin de serveurs Auparavant, nous avions l'habitude de nous procurer des serveurs et de les entretenir nous-mêmes. Mais aujourd'hui, nous faisons appel à des fournisseurs de services cloud tels qu'AWS Azure GCP Fournir une infrastructure en tant que service, ce qui signifie qu'au lieu de nous occuper de la maintenance des serveurs, ils le feront pour nous, et ils fourniront des ressources sous forme de services tels que la RAM, le processeur, le disque dur, etc. L'avantage de faire appel à un fournisseur de services cloud est qu' il est plus évolutif, plus sécurisé, plus fiable et plus rentable que l' achat de serveurs physiques et leur maintenance par nos propres moyens. La création d'une infrastructure ne se limite pas au lancement d'un ensemble de machines virtuelles. Nous devons également prendre soin de configurer les configurations réseau, volumes de stockage et même configurer d'autres services nécessaires tels que les bases de données, etc. Ainsi, créer l'infrastructure manière cohérente au sein de toutes les équipes sans commettre d'erreur est en fait une tâche très difficile et chronophage. Pour résoudre ce problème, nous avons Terraform. TerraForm propose une infrastructure sous forme de code, ce qui signifie qu'elle vous permettra de créer une infrastructure en écrivant Par exemple, vous pouvez écrire du code indiquant que vous avez besoin d'un nombre N de serveurs avec telle ou telle RAM et tel ou tel disque dur, et c'est exactement ce que vous allez faire. Cela nous permet de créer des inscriptions similaires et cohérentes dans toutes les équipes Vous pouvez même reproduire la même inscription en exécutant à nouveau le script. Une fois que vous avez l' infrastructure ou les serveurs, la prochaine chose que nous voulons faire est d'installer le système d'exploitation. Désormais, tous ces fournisseurs de services cloud nous fournissent une image de machine virtuelle prête à l'emploi fournie avec le système d'exploitation. Ainsi, lors du lancement des machines d'observation à l'aide de Terraform, nous pouvons choisir cette image afin que l'infrastructure ou les serveurs soient créés le système d'exploitation Vous pouvez également utiliser un outil de gestion de configuration tel que NZB pour installer le système d'exploitation sur les serveurs Nous allons parler de l' ansib dans un instant. Nous avons maintenant l'infrastructure et le système d'exploitation. Techniquement, nous pouvons désormais déployer l'application et la rendre opérationnelle. En tant que membre de l'équipe DO, vous pouvez facilement le faire car vous êtes un technicien. Vous connaissez toutes les bibliothèques, dépendances configurations requises pour exécuter l'application. Cependant, si vous parlez de certaines personnes non techniques, comme celles de l'équipe de test ou de l'équipe des opérations informatiques, elles ne savent pas comment déployer l'application et comptent donc sur les développeurs pour obtenir les instructions. Et nous avons déjà évoqué les conséquences de cette approche. Si l'équipe DO fournit un guide de déploiement, il se peut que le guide de déploiement ne contienne pas suffisamment d'instructions. Il se peut également que l' test ou l'équipe des opérations n'aient pas mis en œuvre ces instructions exactement comme elles sont censées l'être. Des instructions exactement comme elles sont censées être. Et cela empêcherait l'application fonctionner comme prévu, et cela finirait par retarder la sortie du jeu, etc. Par conséquent, pour résoudre ce problème, nous avons maintenant Docker Cette fois, au lieu de déployer l'application directement sur le système d'exploitation en installant des logiciels, des configurations, etc., ou de fournir le guide de déploiement aux autres équipes, nous allons maintenant créer ce que l'on appelle une image Docker Un Dockerimage est essentiellement une combinaison de code, de bibliothèques d'exécution et de configurations Il s'agit en fait d'un package autonome qui inclut toutes les dépendances, bibliothèques et fichiers nécessaires pour exécuter l'application. Et en utilisant ces images Docker, nous pouvons créer des conteneurs dans différents environnements Maintenant, pour créer des conteneurs à partir de ces images, nous avons besoin d'une plate-forme qui les supporte, et c' est là que la plate-forme Docker entre en jeu Nous allons installer la plateforme Docker au-dessus du système d'exploitation, et nous pourrons désormais créer des conteneurs ou des images Dockery Un conteneur Docker est essentiellement une instance d'exécution d'une image Docker Si vous connaissez la technologie VMware, Docker Image est l' équivalent de VM Snapshot, et Docker Container est équivalent une version en cours d'exécution de me Mais contrairement à une machine virtuelle, les images Docker sont légères Il n'est pas fourni avec un système d'exploitation. Il utiliserait plutôt le système d'exploitation hôte. Quoi qu'il en soit, ce sera le sujet d'une autre conférence. Maintenant, en général, il se peut que nous n'ayons pas une seule image Dockery contenant l'ensemble de l'application Si vous suivez l'architecture Microsovice dans laquelle votre application serait divisée en plusieurs modules plus petits, vous pourriez vous retrouver avec des centaines d'images Dockery gestion manuelle de ces images Dockery est une tâche difficile, et c'est pourquoi nous avons des solutions de dépôt d' artefacts telles que Nexus Nexus agit comme un référentiel centralisé dans lequel les équipes de développement peuvent stocker, partager ou récupérer les artefacts logiciels tels que Dockery Images Permet essentiellement de faciliter le partage, la collaboration entre les équipes et même le contrôle de version des artefacts au sein des équipes de développement ou au sein de l'organisation. Et les différentes équipes de l'organisation vont sélectionner les images les plus sombres de ces plateformes, et elles vont créer des conteneurs à partir de ces images. Vous pouvez donc finir par avoir des centaines de conteneurs en cours d'exécution, mais lorsque vous en avez autant, il devient vraiment difficile de les gérer manuellement, et c'est là que Kubinidis entre en scène En gros, il fournit une plate-forme pour l'orchestration des conteneurs, ce qui facilite le déploiement, la mise à l'échelle ou la gestion des conteneurs Docker à partir d'un tableau de bord unique Sans Kubintis, il est vraiment impossible de gérer autant de conteneurs Jusqu'à présent, nous avons obtenu un taux d'inscription constant dans toutes les équipes. Nous avons l'infrastructure, système d'exploitation et nous avons même l'application opérationnelle. Maintenant, que se passe-t-il si je souhaite installer un logiciel, le mettre à jour ou modifier une configuration dans le cadre de ces inscriptions ? Eh bien, nous ne pouvons pas nous connecter à tous les systèmes et le faire manuellement. Cela prend beaucoup de temps, est sujet aux erreurs et serait très incohérent. Donc, pour résoudre ce problème, nous avons des outils comme Azb Chef Papet Avec AZB, vous pouvez automatiser diverses tâches telles que le déploiement de l'application, l'installation d'un logiciel, modification d'une configuration , etc. Alors que Docker vous permet de créer un enregistrement d'exécution isolé avec du code d'application, des dépendances , etc., NZB, quant à lui, fonctionne au-dessus du système existant pour effectuer diverses tâches sur le Nous pouvons utiliser NZB pour installer le système d'exploitation et même la plateforme Docker Voici quelques-uns des outils utilisés dans DevOps pour créer l'inscription Nous avons également un tas d' autres outils, et nous en parlerons lorsque nous parlerons des phases du DevOps, qui seront bientôt disponibles. 6. 0105 Phases DevOps et leurs outils: Parlons des différentes phases du DevOps et comprenons également les différents types d'outils utilisés dans chacune de ces phases abord, nous avons la phase de planification, qui consiste essentiellement définir les exigences du projet , à fixer les objectifs, à attribuer les capacités individuelles et à décider qui fera quoi, etc. Et ici, nous pouvons utiliser ces outils. Nous avons besoin d'un outil de suivi de projet comme Jira, par exemple, qui est l'un des outils les plus populaires pour suivre le projet Ici, nous pouvons suivre les témoignages d'utilisateurs, les corrections de bogues, etc. Et puis nous avons des outils collaboratifs tels que Slack, Confluence, Google Docs, Microsoft Teams, etc. pour la messagerie entre les employés ou pour gérer les exigences, partager des connaissances, collaborer avec plusieurs équipes, Confluence est comme un Wikipédia pour une organisation. Ensuite, nous avons la phase de codage, et c'est là que les développeurs doivent évidemment écrire et réviser le code. Ils s'assureront de sa qualité et de son respect des normes de codage. Et ici, ils vont utiliser un système de contrôle de version tel que Git et des référentiels de code tels que GitHub, Bitbucket, GitLab Et ils ont généralement tendance à suivre le développement piloté par les tests en écrivant unités J ou en effectuant analyse de code statique à l'aide d'outils tels que Sonar Cube L'analyse statique du code signifierait que nous analyserions le code source pour en vérifier la qualité, la fiabilité et la sécurité sans avoir à exécuter le code. Et évidemment, sans oublier que pour que les développeurs puissent travailler sur leurs activités quotidiennes, ils auront besoin d'une inscription, et nous pouvons obtenir cette inscription en utilisant toutes les technologies dont nous avons parlé plus tôt. Ensuite, nous avons la phase de construction, et c'est là que nous pourrions utiliser certains outils du CICD Nous allons parler du CICD plus en détail lors d'une prochaine conférence Mais Jenkins est l'un des outils les plus populaires du CICD. Nous avons également d'autres outils comme Circle CI ou Gitlab CICD qui font exactement le même travail Dans le cadre de la phase de construction, Jenkins utiliserait certains outils supplémentaires tels que Maven Gradle pour créer un projet afin d'obtenir un ou un artefact déployable Jenkins créera également une image Docker à l'aide de la CLI Docker cela, nous avons évidemment besoin d' un endroit pour stocker les images, et c'est là que nous avons Nexus et Docker Hub pour héberger et maintenir les artefacts Nous passons ensuite à la phase de test. C'est là que nous procéderions aux tests approfondis de l'application. Nous effectuons donc ici des tests de régression, en nous assurant que les nouvelles fonctionnalités ne cassent aucune des fonctionnalités existantes. Nous effectuons des tests d'acceptation. Nous effectuons également des analyses de sécurité et de vulnérabilité. Nous effectuons des tests de performance, des tests de configuration, etc. Le sélénium est l'un des outils les plus populaires pour automatiser le processus de test de l'application Apache Jometer est l'un des outils les plus populaires pour effectuer des tests de performance Et encore une fois, pour tester des choses, nous avons besoin d'un environnement de test, et c'est là que nous allons une fois de plus voir toutes ces technologies entrer en scène. Nous avons déjà parlé de tout cela plus tôt. Ensuite, nous avons la phase de déploiement, laquelle nous allons utiliser Jenkins pour automatiser le processus de déploiement de l' artefact ou plus précisément de l'image Docker dans l' production Ainsi, une fois que tout a été testé et qu'il s'est assuré que tout fonctionne comme prévu, le Jenkins choisira automatiquement l'artefact dans des affiches artificielles telles que Nexus ou Docker Hub, et le déploiera dans l'environnement de mise en scène Encore une fois, nous allons voir toutes les technologies qui nous aideront à créer l'inscription. Ensuite, il y a la phase d'exploitation. Ainsi, une fois le logiciel déployé, l'équipe des opérations ferait son travail pour gérer l'infrastructure, résoudre les problèmes éventuels et surveiller l'application Leur objectif principal est de maintenir une inscription stable et fiable, en garantissant une disponibilité, des performances et une sécurité élevées . Vient ensuite la phase de surveillance, qui consiste à collecter et analyser les métriques, les journaux, suivre les performances des applications, l'état de santé et l'utilisation des ressources, etc. En gros, l'équipe des opérations surveillera tout et, si elle découvre un problème, elle le signalera aux équipes concernées Nagios et prometios font partie des outils de surveillance les plus populaires, Dynatrace et App Dynamics font partie des outils de surveillance des performances partie des outils de surveillance des Vient ensuite la phase d'apprentissage. Ici, nous collectons essentiellement les commentaires des utilisateurs, parties prenantes et des outils de surveillance pour suggérer des améliorations, des corrections de bogues ou même introduire de nouvelles fonctionnalités le but d'affiner et d' améliorer le logiciel, et le cycle complet se répète désormais dès la phase de planification Il s'agit d'un processus continu et nouvelles versions continueraient de paraître pour toujours, moins jusqu'à ce que le projet soit abandonné. C'est la raison pour laquelle le logo DevOps ressemble à un symbole de l'infini, car ce processus se poursuivrait indéfiniment, et les logiciels évolueront et s'amélioreront à chaque fois Un point important que je tiens à souligner ici, qui est également celui que j'ai mentionné plus tôt, est que le DevOps n'est pas pratiqué de la même manière dans toutes les organisations Les outils et les méthodologies peuvent varier en fonction du projet. Mais ce dont nous avons parlé jusqu'à présent, ce sont les plus populaires. Si vous ne savez pas quoi apprendre, apprenez ces leçons populaires, celles que j'ai mentionnées. Ensuite, nous allons parler du mot le plus souligné dans DevOps En continu. Je te verrai ensuite. 7. 0106 Intégration permanente Livraison permanente: Traditionnellement, les développeurs travaillaient sur la fonctionnalité ou Bfix, puis ils transféraient ces modifications dans ces modifications référentiel de code centralisé tel que GitHub, bitbucket, GitLab bitbucket Je suppose que vous ne connaissez pas ces outils Je n'utiliserai donc aucune des terminologies qui leur sont associées. Mais essentiellement, les développeurs apporteraient leurs modifications, et ce n'est qu'à la fin du cycle de vie du développement que toutes ces modifications de code seraient fusionnées ? En d'autres termes, toutes ces modifications de code seraient fusionnées ou intégrées et intégrées et intégrées à la base de code principale. Une fois cela fait, en supposant qu'il n' y ait aucun conflit, nous passerons à la phase suivante où l'équipe de test testera toutes les modifications, effectuera des tests approfondis de l'application lors de l'inscription aux tests, et en supposant que tout s'est bien passé et que l'équipe de test n'a détecté aucun problème, ce qui est très peu probable, nous allons passer au déploiement de l'application sur la mise en scène ou l'inscription à la production. Cependant, il s'agit du meilleur scénario, mais selon toute probabilité, vous allez rencontrer les problèmes suivants. Vous allez rencontrer des problèmes d'intégration car lorsque vous fusionnez autant de modifications en une seule fois, vous risquez de rencontrer des conflits, ce qui rencontrer des conflits, signifie que plusieurs développeurs ont peut-être travaillé sur le même morceau de code, et que ces conflits doivent être résolus avant de continuer. Il peut également arriver que les modifications apportées par un développeur aient impact négatif sur les modifications apportées par un autre développeur. Il est également très difficile de retracer les problèmes car lorsque vous intégrez autant de modifications ensemble, au cas où vous trouveriez un problème, il est vraiment difficile de savoir quel changement en particulier est réellement à l'origine du problème. donc plus difficile de résoudre les conflits et d'identifier devient donc plus difficile de résoudre les conflits et d'identifier la cause première des problèmes, ce qui peut entraîner des efforts d' intégration potentiellement fastidieux et sujets aux erreurs. W, si l'équipe de test découvre un problème critique, cela peut même retarder la publication, et même le cycle de feedback est plus long, les développeurs ne seront informés de l'existence de conflits ou de bogues qu'à la fin du cycle de développement, ce qui peut entraîner des délais de résolution plus longs et entraver la capacité à résoudre le problème en temps opportun. Développe, cependant, nous allons suivre une approche différente, et voici comment cela se passe. Ainsi, après la phase de planification, les développeurs commenceraient à coder. Chaque développeur apporterait ses modifications au référentiel centralisé, puis nous avons Jenkins, qui est un CSCDtol qui surveillerait en permanence les nouvelles comètes sur au référentiel centralisé, puis nous avons Jenkins, qui est un CSCDtol qui surveillerait en permanence les nouvelles Lors de l'identification d'un nouveau commit, Jenkins lancera un processus génération pour créer les artefacts ou l'image Docker, qui seront ensuite automatiquement déployés dans l'environnement de test Jenkins déclenchera également tests de mérite automatiques pour tester de manière approfondie l' application et les modifications Et une fois cela fait, Jenkins informera les réviseurs pour qu'ils examinent les modifications du code Les réviseurs examineront les modifications du code, fourniront les commentaires nécessaires, suggéreront des améliorations, etc., et les développeurs répondront aux commentaires reçus lors de la révision du code Ils apportent toutes les modifications nécessaires, ajoutent des clarifications ou discutent d' approches alternatives, ou discutent d' approches alternatives, et ce processus itératif se poursuit jusqu'à ce modifications du code répondent aux normes de qualité requises Une fois que tout ira bien, une fois que les réviseurs auront approuvé le code, une fois que les réviseurs auront approuvé le code, nous passerons à la phase suivante où nous allons fusionner toutes ces modifications ou, en d'autres termes, nous allons intégrer toutes ces modifications la base de code principale Et avant de fusionner réellement les modifications, nous pouvons avoir une tâche dans Jenkins pour effectuer des tests ou des validations supplémentaires avant de fusionner Lors de la fusion des modifications ou intégration dans la base de code principale, nous pouvons lancer le processus de déploiement de ces modifications dans l' environnement de production ou de préparation Et encore une fois, Jenkins va faire le travail à notre place. Il va créer le projet, déployer les artefacts nécessaires sur l'environnement de production ou de préparation, et rendre l'application opérationnelle. Désormais, le processus consistant à apporter le code, à exécuter des tests automatisés et, finalement, à fusionner les modifications ou à intégrer les modifications dans la base de code principale est ce que nous appelons l'intégration continue Ou plus précisément, nous avons également développement continu dans le cadre duquel les développeurs apportent continuellement des améliorations, introduisent de nouveaux changements, et le processus de test continu des modifications à l'aide tests automatisés est un test continu. Ce que nous faisions manuellement auparavant est désormais un ensemble de tests automatisés. Et le processus de mise en œuvre des modifications dans l'environnement de production ou l'environnement de production est appelé livraison continue. Nous avons également souvent confondu terme «   déploiement continu ». La différence entre la livraison continue et le déploiement continu est très simple. Lorsque nous intervenons manuellement pour permettre à Jenkins de sélectionner le code dans la base de code principale et de déployer éventuellement l'application dans l'environnement de production, cela s'appelle la livraison continue Si nous automatisons ce processus, c'est-à-dire que juste après avoir intégré les modifications apportées à la base de code principale, Jenkins récupère automatiquement le code et le déploie dans l'environnement de production, on parle de déploiement continu Et une fois l'application déployée, l'équipe des opérations effectuera une surveillance continue, et l'ensemble du processus se répète cadre du cycle de vie du DevOps Contrairement à l'approche traditionnelle, améliorer le logiciel en un seul lot, dans le cas du DevOps, les mises à jour sont effectuées en continu, pièce par pièce, ce qui permet de livrer le code logiciel aux clients dès qu'il est terminé et testé De toute évidence, étant donné que nous n'intégrons pas grand nombre de modifications en une seule fois, nous n'aurons pas autant de conflits, et comme les tests sont effectués presque immédiatement après un commentaire, les développeurs recevront un retour instantané en cas de problème avec le code, ce qui effectués presque immédiatement après un commentaire, les développeurs recevront un retour instantané en cas de problème avec le code, ce les développeurs recevront un retour instantané cas de problème avec le code, leur permet de disposer de suffisamment de temps pour résoudre le problème la fin du cycle de développement. Donc, chaque fois que quelqu'un crée une comète, nous allons répéter l'ensemble du processus nous allons répéter l'ensemble du processus à nouveau, car tout est quasiment automatisé . Jenkins est au centre de tout le processus et relie tous les points entre eux Ensuite, nous allons avoir un bref résumé ce que nous avons accompli avec D Wops 8. 0107 Avantages de DevOps: Parlons de certains des avantages des DeWaps. Une meilleure collaboration et une meilleure culture, évidemment grâce à l' évolution des mentalités et intégration de certaines philosophies et pratiques culturelles , ainsi que d'outils collaboratifs, nous ont permis d' améliorer de manière significative la collaboration entre les équipes interfonctionnelles et la culture globale Innovation plus rapide et résolution des problèmes mettant l'accent sur l'automatisation et grâce à l'intégration et à la livraison continues, nous avons considérablement réduit le temps nécessaire à la publication du logiciel Grâce à ces itérations plus rapides, nous pouvons innover plus rapidement et résoudre les problèmes en temps opportun Des inscriptions opérationnelles plus stables. Grâce à l'utilisation de divers outils et technologies, nous avons pu créer des inscriptions stables dans toutes les équipes Donc, si l'application fonctionne dans une seule inscription, y a de fortes chances qu'elle fonctionne également dans autre environnement sans causer de problème. Faisons face aux problèmes et aux temps d'arrêt. En effectuant régulièrement des tests de mérite automatique fréquents et réguliers et en étant en mesure de maintenir environnements stables et fiables, nous pouvons réduire les risques de problèmes ou de temps d'arrêt pendant la production. Une meilleure efficacité opérationnelle, en utilisant divers outils tels qu'Ansibl pour la gestion des configurations, en utilisant des outils de surveillance tels que Nagios et améliorant la collaboration avec les autres membres de l'équipe, nous avons également amélioré l'efficacité opérationnelle globale divers outils tels qu'Ansibl pour la gestion des configurations, en utilisant des outils de surveillance tels que Nagios et en améliorant la collaboration avec les autres membres de l'équipe, nous avons également amélioré l'efficacité opérationnelle globale. Rentable. De toute évidence, en mettant l'accent sur l'automatisation, ce qui était auparavant effectué manuellement ou qui est désormais automatisé, et en faisant appel à des fournisseurs de services cloud, nous allons réduire les coûts de manière significative. C'est pourquoi, si vous venez de l'expérience dans le domaine des tests ou des opérations informatiques, vous devez sérieusement envisager de mettre à niveau vos compétences vers le DevOps Satisfaction du client De toute évidence, lorsque vous suivez les méthodologies DevOps, tenu de tous leurs avantages, cela se traduira en fin de compte par une meilleure satisfaction des clients car ils n'ont pas à attendre les versions aussi longtemps, ce qui se traduit évidemment meilleurs revenus et une meilleure réputation vous aidera également à garder une longueur d'avance sur vos concurrents sur le marché. J'espère que vous avez compris le tableau d'ensemble du DevOps. Je te verrai ensuite.