What is DevOps || DevOps Tools

Bonjour à toute l'équipe. Bienvenue à nouveau. Bienvenue à DevOps Training. Il s'agit de la première conférence de ce cours particulier. Aujourd'hui, nous allons apprendre ce qu'est DevOps et quels sont les outils DevOps. Nous allons donc aborder ces quelques sujets et, dans le cadre de cette conférence, nous apprendrons pourquoi nous suivons les pratiques de Davos et quels sont les avantages de ces pratiques. Nous commencerons donc par découvrir l'évolution du développement de logiciels au fil des ans. Nous aborderons ensuite un cas d'utilisation de Facebook, qui utilise DevOps. Ensuite, nous apprendrons ce qu'est DevOps et, à la fin, nous découvrirons les différents ensembles d'outils utilisés pour DevOps. Commençons donc par... Ainsi, à l'époque précédente, ou vous pouvez dire à l'époque antérieure où le développement de logiciels a commencé, il y avait différents types de modèles, n'est-ce pas ? Il existe différents types de cycles de développement de logiciels. Le cycle de développement logiciel le plus répandu était donc le modèle traditionnel en cascade. Dans le modèle en cascade, nous devons d'abord recueillir les besoins dans la phase de planification, puis nous procédons au codage, aux tests et à la maintenance, n'est-ce pas ? Il s'agit donc du cycle de vie complet du produit selon le modèle traditionnel en cascade. Chaque phase a donc sa propre signification, n'est-ce pas ? Dans le cadre de la planification, nous avons donc essentiellement recueilli les exigences par la suite. Ensuite, nous commencerons le développement et, après le développement, nous testerons le produit complet et, après le test, nous déploierons le produit complet et nous utiliserons la maintenance, n'est-ce pas ? Il y avait donc un type différent de lacunes disponibles dans ce modèle en cascade particulier, car le cycle de vie des produits est très long, n'est-ce pas ? Parce que nous ne pouvons pas lancer le produit tant que nous ne l'avons pas entièrement construit. L'effort de test est utilisé, le développement est également utilisé parce que nous développons le produit complet et ensuite nous commençons les tests, n'est-ce pas ? Nous ne faisons pas les choses en parallèle pour que le modèle ait ces failles. Le modèle suivant qui arrive sur le marché est donc le développement agile. Le produit a été développé en termes de fonctionnalités. Les azalées se caractérisent essentiellement par un développement judicieux du produit. Nous développons une seule fonctionnalité, n'est-ce pas ? Nous prenons l'exigence, développons la fonctionnalité, la testons et repartons en développement si nous rencontrons des bogues. Une fois que nous avons terminé un seul élément, nous reprenons le deuxième élément, n'est-ce pas ? Dans le cadre du développement agile, les délais de livraison sont très courts. Dans le modèle Agile, huit exigences changent très fréquemment. Le développement doit être rapide, mais après la vente, nous travaillons maintenant dans l'ERA, que l'on appelle les approches DevOps. L'approche DevOps est donc la mieux adaptée lorsque les exigences changent fréquemment. Le développement doit être agile et les opérations doivent l'être également. Et à l'ère DevOps, le développement et les tests se poursuivront en une seule phase, n'est-ce pas ? Nous pouvons développer et tester le produit en parallèle. Voyons comment nous pouvons y parvenir. Avant de passer au DevOps et aux technologies DevOps, j'aimerais d'abord partager l'expérience de Facebook, qui s'est déroulée en 2011. C'est vrai ? Nous savons donc très bien que Facebook est une très grande entreprise. Ils recrutent les meilleurs ingénieurs du marché, n'est-ce pas ? Ils travaillent également sur des technologies de pointe et Facebook est un exemple de la meilleure ingénierie au monde. Facebook a donc lancé quelques fonctionnalités en 2011. En 2011, Facebook a introduit de nouvelles fonctionnalités telles que la timeline, la musique et le ticker. C'est vrai ? Dans le dernier diagramme, vous pouvez voir la carte du monde. Nous montrons ici les différents centres de données de Facebook, n'est-ce pas ? Ce sont les zones de déploiement de Facebook. Ainsi, lorsque Facebook a lancé ces fonctionnalités en 2011, il les a déployées dans tous ses centres de données. Les nouvelles fonctionnalités ont été lancées dans le monde entier en une seule fois juste après cela. Ils ont dû faire face à certains défis. Ainsi, en 2011, Facebook comptait 500 millions d'utilisateurs dans le monde. C'est vrai ? Ils ont utilisé les nouvelles fonctionnalités intéressantes de leur site web qui ont attiré un trafic important sur les serveurs de Facebook. Résultat : les serveurs de Facebook s'effondrent. Ils ont cessé de travailler. C'est vrai. Et lorsque les serveurs ont cessé de fonctionner, il y a eu un retard dans l'ouverture de Facebook. Les utilisateurs ont rencontré différents types de problèmes. Ils ont donc reçu une réponse mitigée de la part des utilisateurs, ce qui ne mène à aucune conclusion puisqu'il n'y a aucun moyen de supprimer ces fonctionnalités. Il n'y a aucun moyen de sortir de ce genre de situation. C'est vrai ? C'est ainsi que Facebook a mis au point une stratégie appelée "dark launching technique". C'est vrai ? Après cet incident, Facebook a donc mis au point une technique de lancement sombre. Voyons donc ce qu'est la technique de lancement dans l'obscurité. Quelle est la stratégie de Facebook après l'incident de 2011 ? En ce qui concerne la technique de lancement dans l'obscurité, ils l'ont divisée en trois parties. La première partie a fait l'objet d'une discussion et a été mise en œuvre de manière à ce que les nouvelles fonctionnalités soient d'abord déployées sur une base d'utilisateurs plus restreinte et plus spécifique. Ainsi, au lieu de s'adresser d'abord à l'ensemble des utilisateurs, si nous introduisons une nouvelle fonctionnalité dans notre application, si nous allons proposer quelque chose de nouveau, nous ouvrirons cette fonctionnalité particulière à un groupe spécifique ou à un groupe plus restreint, comme Google l'a également utilisé dans le chat de Google. Tout d'abord, Google Chat a été introduit dans l'entreprise elle-même. Google Chat était réservé aux employés de Google. C'est vrai. La nouvelle fonctionnalité sera donc d'abord déployée sur une zone plus petite. C'est vrai. Et il sera ouvert à la base d'utilisateurs spécifique. C'est vrai ? Ils surveillent ensuite en permanence les réactions et développent et testent continuellement le produit. Nous avons donc trois nouveaux mandats. La première est la surveillance continue. Le deuxième est le développement continu et le troisième est le test continu. Ces trois termes se retrouvent essentiellement dans le DevOps. Ainsi, lorsque nous déployons une fonction de base ou une nouvelle fonction à un groupe spécifique, nous surveillons les réactions à cette fonction particulière. Nous développons continuellement les bogues que nous rencontrons dans cette fonctionnalité particulière, nous la testons et nous la déployons à nouveau. C'est vrai ? Il existe donc un cycle dont nous parlerons dans la prochaine diapositive à l'aide d'un très bon diagramme. C'est vrai ? Une fois que la fonctionnalité est stable, une fois que nous savons que cette fonctionnalité particulière est stable, elle est déployée pour d'autres utilisateurs dans plusieurs versions. Ainsi, une fois que la fonctionnalité est stable, nous n'allons pas encore déployer la fonctionnalité complète dans son ensemble. Tous les centres de données ou l'application globale ou complète. Nous le publierons en plusieurs versions pour des utilisateurs spécifiques. Supposons que nous sortions d'abord les versions pour l'année, puis pour l'Europe, puis pour l'Amérique, puis pour le Royaume-Uni, n'est-ce pas ? C'est pourquoi nous publierons les nouvelles fonctionnalités en plusieurs fois. C'est ce qu'on appelle la technique du lancement dans l'obscurité. Voici donc le schéma de la technique de lancement dans l'obscurité. Tout d'abord, Facebook est une entreprise qui introduit une nouvelle fonctionnalité, n'est-ce pas ? Il le déploiera sur un groupe d'utilisateurs spécifique, qui se trouve dans la ceinture jaune. Tout centre de données spécifique. Ensuite, nous rencontrons des bogues, ce qui nous amène à revenir en arrière. Nous pouvons donc voir ici qu'un cycle est généré. Tout d'abord, la fonction est destinée à un utilisateur spécifique. Nous recevons un retour d'information, ce que l'on appelle le contrôle continu. Si nous recevons des commentaires, des bogues, alors la fonctionnalité est renvoyée à l'équipe de développement, n'est-ce pas ? Ils le répareront et le testeront. C'est ce qu'on appelle le développement par déploiement continu et les tests continus. La fonctionnalité est donc diffusée à un groupe spécifique. Ils font l'objet d'un suivi. Si nous rencontrons des bogues, ils peuvent être transmis à l'équipe de développement, qui les corrige et publie une nouvelle version. Il le testera à nouveau et s'adressera à nouveau à l'équipe de développement s'il y a un bogue. Il s'agit donc d'un cycle complet appelé contrôle continu, développement continu et test continu. C'est vrai ? Une fois que la fonctionnalité sera stable, nous la mettrons à la disposition de nos clients. Autres utilisateurs. C'est ce qu'on appelle l'intégration continue, n'est-ce pas ? Une fois que nous aurons intégré cette fonctionnalité particulière dans notre application, nous l'ouvrirons dans plusieurs versions à plusieurs utilisateurs. C'est ce qu'on appelle le déploiement continu. Nous déployons donc notre application en continu dans différents centres de données ou dans différentes zones de données. Nous apprenons donc cinq nouvelles choses, n'est-ce pas ? Il s'agit donc essentiellement de la mise en œuvre de la technique de lancement sombre, c'est-à-dire des activités ou des éléments fondamentaux du cycle de vie DevOps. Et le cycle de vie DevOps concerne le déploiement continu, le développement continu, les tests continus, l'intégration continue et la surveillance continue, n'est-ce pas ? C'est donc cette phase qui est à l'origine du DevOps. Nous apprenons maintenant l'existence des démons. Comme nous l'avons déjà dit, DevOps n'est pas une technologie, DevOps n'est pas un langage de programmation. En gros, DevOps est une approche de développement de logiciels, n'est-ce pas ? C'est vrai. Modèle en cascade, à droite. Modèle agile. DevOps est également une approche de développement de logiciels qui implique un développement continu, des tests continus, une intégration continue, un déploiement continu et une surveillance continue des logiciels tout au long de leur cycle de développement. Il s'agit donc de planifier le code, de le construire, de le tester et, après le test, de le déployer, de l'exploiter et de le surveiller. Si vous êtes confronté à un problème, consultez le plan. Bien, construire, tester et à nouveau déployer, exploiter et contrôler. Il s'agit d'un cycle complet, sans fin, qui nous permet d'avoir un signe comme celui-ci, qui est la conception infinie du DevOps. Nous travaillons donc essentiellement par versions, nous planifions quelque chose, nous codons cette chose particulière, nous développons cette chose particulière, nous construisons le projet, nous le testons à nouveau, nous le déployons juste après le déploiement. Nous en assurerons le fonctionnement et la surveillance. Si nous rencontrons des problèmes, nous recevons un retour d'information. Nous passons à nouveau à la phase de développement. Il s'agit donc d'un cycle sans fin. Mais dans le cadre de DevOps, nous avons des versions très fréquentes. Si vous, si vous, si vous voulez, vous pouvez sortir votre logiciel toutes les semaines, toutes les deux semaines, deux fois par mois, deux fois par mois ou tous les deux mois, tous les trois mois. Dans le cadre de DevOps, nous avons donc des versions très fréquentes. C'est l'avantage de l'approche DevOps. Dans ce diagramme particulier, nous présentons un certain nombre d'outils nécessaires pour le DevOps. Lorsque nous parlons de plan et de code, nous pouvons utiliser des outils comme Git, n'est-ce pas ? Comme Subversion et JIRA. JIRA est utilisé pour le signalement des défauts, git est utilisé pour le contrôle des versions des logiciels et subversion est également utilisé pour le contrôle des logiciels. Nous en discuterons. Obtenez les tutoriels complets de git dans les prochaines vidéos. Ensuite, nous construirons notre projet. Nous disposons de différents types d'outils de construction disponibles sur le marché, comme Maven et Gradle, que nous utiliserons dans ce tutoriel. C'est vrai ? Nous allons nous familiariser avec Maven. Si j'ai le temps, je créerai également les conférences sur le gradle. La phase suivante est celle du test et nous disposons d'outils de test tels que Selenium G unit. C'est vrai. Vous pouvez donc voir ici que nous avons différents frais et que nous avons différents outils disponibles pour chaque frais. C'est vrai ? Ensuite, il y a le déploiement continu et la surveillance. Nous avons des outils comme Ansible, Puppet Chef, Salt Stack, n'est-ce pas ? Nous disposons ensuite d'une surveillance continue, d'un capteur neuronal et de l'utilisation de nag. Cette phase complète est fondamentalement appelée la phase de développement, et ce sont les outils du profil DevOps ou des approches DevOps. C'est vrai. Nous construisons donc le projet, nous développons le projet, nous construisons le projet, nous le testons. Nous le déployons correctement, nous le contrôlons et nous le construisons. Il s'agit donc du DevOps. Voilà pour le DevOps. Si vous avez des questions concernant les sujets que nous avons abordés aujourd'hui, vous pouvez les poser dans le forum des questions et réponses et j'y répondrai dans les prochains tutoriels. Nous apprendrons ce que sont le déploiement continu, l'intégration continue, la surveillance continue et d'autres domaines. Nous vous remercions. Merci pour votre temps.