Le rapport parlera de certaines pratiques DevOps, mais du point de vue d'un développeur. En règle générale, tous les ingénieurs qui rejoignent DevOps ont déjà plusieurs années d’expérience administrative à leur actif. Mais cela ne veut pas dire qu’il n’y a pas de place pour le développeur ici. Le plus souvent, les développeurs sont occupés à corriger « le prochain bug critique et urgent du jour », et ils n’ont même pas le temps de jeter un coup d’œil rapide au domaine DevOps. Selon l'auteur, DevOps relève avant tout du bon sens. Deuxièmement, c’est l’occasion d’être plus efficace. Si vous êtes un développeur, que vous avez du bon sens et que vous souhaitez être plus efficace en tant que membre d'une équipe, ce rapport est fait pour vous.
Je me présente, j’avoue qu’il y a des gens dans la salle qui ne me connaissent pas. Je m'appelle Anton Boyko, je suis un MVP Microsoft Azure. Qu’est-ce que le MVP ? Il s'agit de Modèle-Vue-Présentateur. Model-View-Presenter est exactement moi.
De plus, j'occupe actuellement le poste d'architecte de solutions chez Ciklum. Et tout récemment, je me suis acheté un si beau domaine et j'ai mis à jour mon courrier électronique, que je montre habituellement lors des présentations. Vous pouvez m'écrire à : moi [chien] byokoant.pro. Vous pouvez m'envoyer un e-mail avec des questions. J'y réponds habituellement. La seule chose est que je ne souhaite pas recevoir de questions par email portant sur deux sujets : la politique et la religion. Vous pouvez m'écrire sur tout le reste par e-mail. Un certain temps passera, je répondrai.
Quelques mots sur vous-même :
- Je suis dans ce domaine depuis maintenant 10 ans.
- J'ai travaillé chez Microsoft.
- Je suis le père fondateur de la communauté ukrainienne Azure, que nous avons fondée quelque part en 2014. Et nous l’avons toujours et sommes en train de le développer.
- Je suis également le père du fondateur de la conférence Azure, que nous organisons en Ukraine.
- J'aide également à organiser le Global Azure Bootcamp à Kiev.
- Comme je l'ai dit, je suis un MVP Microsoft Azure.
- Je parle assez souvent lors de conférences. J’aime vraiment prendre la parole lors de conférences. Au cours de la dernière année, j’ai pu jouer environ 40 fois. Si vous passez par l'Ukraine, la Biélorussie, la Pologne, la Bulgarie, la Suède, le Danemark, les Pays-Bas, l'Espagne ou à peu près un autre pays d'Europe, alors il est fort possible que lorsque vous vous rendez à une conférence qui a un thème cloud dans son flux, vous me verrez peut-être sur la liste des orateurs.
- Je suis aussi un fan de Star Trek.
Parlons un peu de l'Agenda. Notre ordre du jour est très simple :
- Nous parlerons de ce qu'est DevOps. Voyons pourquoi c'est important. Auparavant, DevOps était un mot-clé que vous écriviez sur votre CV et qui recevait immédiatement +500 $ de salaire. Vous devez maintenant écrire, par exemple, blockchain dans votre CV afin d'obtenir +500 dollars sur votre salaire.
- Et puis, lorsque nous comprendrons un peu ce que c'est, nous parlerons de ce que sont les pratiques DevOps. Mais pas tant dans le contexte du DevOps en général, mais plutôt dans le contexte des pratiques DevOps qui pourraient intéresser les développeurs. Je vais vous expliquer pourquoi ils pourraient vous intéresser. Je vais vous expliquer pourquoi vous devriez faire cela et comment cela peut vous aider à ressentir moins de douleur.
Une image traditionnelle que beaucoup de gens montrent. C'est ce qui se passe dans de nombreux projets. C'est à ce moment-là que nous avons des départements de développement et d'exploitation qui prennent en charge nos logiciels. Et ces départements ne communiquent pas entre eux.
Peut-être, si vous ne pouviez pas le ressentir aussi clairement dans les départements DevOps et opérationnels, pourriez-vous faire une analogie avec les départements Dev et QA. Il y a des gens qui développent des logiciels et il y a des gens du contrôle qualité qui sont mauvais du point de vue des développeurs. Par exemple, je confie mon merveilleux code au référentiel, et il y a un scélérat assis là qui me renvoie ce code et dit que votre code est mauvais.
Tout cela se produit parce que les gens ne communiquent pas entre eux. Et ils se lancent des paquets, des applications, à travers un mur d'incompréhension et essaient d'en faire quelque chose.
C’est précisément ce mur que la culture DevOps est censée détruire, c’est-à-dire forcer les gens à communiquer entre eux et au moins à comprendre ce que font les différentes personnes participant au projet et pourquoi leur travail est important.
Et quand on parle de DevOps, quelqu'un vous dira que DevOps, c'est quand le projet a une intégration continue ; quelqu'un dira que DevOps l'est si le projet met en œuvre la pratique « infrastructure as code » ; quelqu'un dira que la première étape vers DevOps est le branchement des fonctionnalités, les indicateurs de fonctionnalités.
Au fond, tout cela est vrai à sa manière. Mais ce ne sont que les pratiques ultimes dont nous disposons. Avant de passer à ces pratiques, je vous propose de regarder ce slide, qui présente les 3 étapes de mise en œuvre de la méthodologie Dev-Ops dans votre projet, dans votre entreprise.
Cette diapositive porte également un deuxième nom non officiel. Vous pouvez effectuer une recherche en ligne pour découvrir quels sont les 3 mousquetaires du DevOps. Il est possible que vous trouviez cet article. Pourquoi 3 Mousquetaires ? En dessous, il est écrit : les personnes, les processus et les produits, c'est-à-dire PPP – Porthos, Porthos et Porthos. Voici les 3 mousquetaires du DevOps. Cet article décrit plus en détail pourquoi cela est important et ce que cela implique.
Lorsque vous commencez à mettre en œuvre une culture DevOps, il est très important qu'elle soit mise en œuvre dans l'ordre suivant.
Au début, vous devez parler aux gens. Et vous devez expliquer aux gens de quoi il s’agit et comment ils peuvent en tirer des avantages.
Notre conférence s'appelle DotNet Fest. Et comme me l'ont dit les organisateurs, nous avons principalement invité ici un public de développeurs, j'espère donc que la plupart des personnes présentes dans la salle sont impliquées dans le développement.
Nous parlerons des gens, nous parlerons de ce que les développeurs veulent faire chaque jour. Que veulent-ils le plus ? Ils veulent écrire du nouveau code, utiliser des frameworks de dernière génération, créer de nouvelles fonctionnalités. Qu’est-ce que les développeurs veulent le moins ? Corrigez les anciens bugs. J'espère que vous êtes d'accord avec moi. C'est ce que veulent les développeurs. Ils veulent écrire de nouvelles fonctionnalités, ils ne veulent pas corriger des bugs.
Le nombre de bugs produits par un développeur particulier dépend de la façon dont ses bras sont droits et de la mesure dans laquelle ils poussent à partir de ses épaules, et non de ses poches arrière. Mais néanmoins, lorsque nous avons un grand projet, il arrive parfois qu'il soit impossible de tout suivre, il serait donc bien pour nous d'utiliser certaines approches qui nous aideront à écrire un code plus stable et de meilleure qualité.
Qu’est-ce que les responsables de l’assurance qualité souhaitent le plus ? Je ne sais pas s'ils sont dans le hall. Il m’est difficile de dire que je veux un contrôle qualité, car je n’en ai jamais été un. Et n’en déplaise aux gars, on dira que j’espère que je ne le ferai jamais. Mais pas parce que je considère leur travail dénué de sens et inutile, mais parce que je ne me considère pas comme une personne capable de faire ce travail efficacement, donc je n'essaierai même pas de le faire. Mais d'après ce que j'ai compris, ce que le QA n'aime pas le plus, c'est de travailler le matin, en exécutant constamment des sortes de tests de régression, en s'attaquant aux mêmes bugs qu'ils ont signalés aux développeurs il y a 3 sprints et en disant : « Quand allez-vous , Monsieur D'Artagnan, corrigez ce bug.' Et M. D'Artagnan lui répond : "Oui, oui, oui, je l'ai déjà réparé." Et comment se fait-il que j'ai corrigé un bug et en ai créé 5 en cours de route.
Les personnes qui soutiennent cette solution en production souhaitent que cette solution fonctionne sans bugs, afin de ne pas avoir à redémarrer le serveur tous les vendredis, lorsque toutes les personnes normales vont au bar. Les développeurs ont déployé vendredi, les administrateurs restent assis jusqu'à samedi, essayant de mettre en place et de corriger ce déploiement.
Et lorsque vous expliquez aux gens qu'ils visent à résoudre les mêmes problèmes, vous pouvez passer à la formalisation des processus. Il est très important. Pourquoi? Parce que lorsque nous parlons de « formalisation », il est important que vous décriviez comment vos processus se déroulent au moins quelque part sur une serviette. Vous devez comprendre que si, par exemple, vous déployez dans un environnement d'assurance qualité ou un environnement de production, cela se produit toujours dans cet ordre ; à ces étapes, nous exécutons, par exemple, des tests unitaires automatiques et des tests d'interface utilisateur. Après le déploiement, nous vérifions si le déploiement s'est bien ou mal passé. Mais vous disposez déjà d’une liste claire d’actions qui doivent être répétées encore et encore lors du déploiement en production.
Et ce n'est que lorsque vos processus sont formalisés que vous commencez à sélectionner les produits qui vous aideront à automatiser ces processus.
Malheureusement, je constate très souvent que cela se produit à l'envers. Dès que quelqu'un entend le mot « DevOps », il suggère immédiatement d'installer Jenkins, car il pense que dès qu'il installera Jenkins, il aura DevOps. Ils ont installé Jenkins, lu les articles « Comment faire » sur le site Web de Jenkins, essayé d'intégrer des processus dans ces articles Comment faire, puis sont allés vers les gens et les ont penchés en leur disant que le livre dit qu'il faut procéder de cette façon, donc nous procédons de cette façon.
Ce n'est pas que Jenkins soit un mauvais outil. Je ne veux en aucun cas dire cela. Mais ce n'est qu'un des produits. Et le produit que vous utilisez devrait être votre dernière décision, et en aucun cas la première. Votre produit ne doit pas être motivé par la mise en œuvre d’une culture et d’approches. C'est très important à comprendre, c'est pourquoi je passe autant de temps sur cette diapositive et j'explique tout cela si longtemps.
Parlons des pratiques DevOps en général. Quels sont-ils? Quelle est la différence? Comment les essayer ? Pourquoi sont-ils importants ?
La première pratique dont vous avez peut-être entendu parler s'appelle l'intégration continue. Peut-être que quelqu'un sur le projet dispose d'une intégration continue (CI).
Le plus gros problème, c'est que le plus souvent, lorsque je demande à une personne : « Avez-vous du CI sur le projet ? et il dit : « Oui », puis quand je lui demande ce qu'il fait, il me décrit absolument tout le processus d'automatisation. Ce n'est pas tout à fait vrai.
En fait, la pratique de CI vise simplement à intégrer le code que différentes personnes écrivent dans une sorte de base de code unique. C'est tout.
En plus de CI, il existe généralement d'autres pratiques en cours de route, telles que le déploiement continu et la gestion des versions, mais nous en reparlerons plus tard.
CI lui-même nous dit que différentes personnes écrivent du code et que ce code doit être continuellement intégré dans une base de code unique.
Qu’est-ce que cela nous apporte et pourquoi est-ce important ? Si nous avons DotNet, alors c'est bien, c'est un langage compilé, on peut compiler notre application. S'il compile, c'est déjà un bon signe. Cela ne veut encore rien dire, mais c'est le premier bon signe que nous pouvons au moins compiler.
Ensuite, nous pouvons exécuter quelques tests, ce qui constitue également une pratique distincte. Les tests sont tous au vert – c’est le deuxième bon signe. Mais encore une fois, cela ne veut rien dire.
Mais pourquoi ferais-tu ça ? Toutes les pratiques dont je vais parler aujourd'hui ont à peu près la même valeur, c'est-à-dire à peu près les mêmes bénéfices et sont également mesurées à peu près de la même manière.
Premièrement, cela vous permet d’accélérer la livraison. Comment cela vous permet-il d’accélérer la livraison ? Lorsque nous apportons de nouvelles modifications à notre base de code, nous pouvons immédiatement essayer de faire quelque chose avec ce code. Nous n'attendons pas jeudi car jeudi, nous le publions à QA Environment, nous le faisons ici et ici.
Je vais vous raconter une triste histoire de ma vie. C'était il y a longtemps, quand j'étais encore jeune et beau. Maintenant, je suis déjà jeune, belle, intelligente et modeste. Il y a quelque temps, j'étais dans un projet. Nous avions une grande équipe d’environ 30 développeurs. Et nous avions un très gros projet d’entreprise qui s’est développé pendant environ 10 ans. Et nous avions différentes succursales. Dans le référentiel, nous avions une branche dans laquelle marchaient les développeurs. Et il y avait une branche qui affichait la version du code en production.
La branche production avait 3 mois de retard sur la branche qui était à la disposition des développeurs. Qu'est-ce que cela signifie? Cela signifie que dès que j'ai un bug quelque part qui passe en production à cause de la faute des développeurs, parce qu'ils l'ont autorisé, et à cause de la faute du QA, parce qu'ils l'ont examiné, alors cela signifie que si je reçois un tâche de correctif pour la production, je dois alors annuler mes modifications de code il y a 3 mois. Je dois me souvenir de ce que j'avais il y a 3 mois et essayer de le réparer là-bas.
Si vous n’avez pas encore vécu cette expérience, vous pouvez l’essayer sur votre projet de maison. L’essentiel est de ne pas l’essayer sur un modèle commercial. Écrivez quelques lignes de code, oubliez-les pendant six mois, puis revenez et essayez d'expliquer rapidement de quoi il s'agit et comment vous pouvez les corriger ou les optimiser. C'est une expérience très, très excitante.
Si nous avons une pratique d'intégration continue, cela nous permet de la vérifier avec un certain nombre d'outils automatisés ici et maintenant, dès que j'ai écrit mon code. Cela ne me donnera peut-être pas une image complète, mais cela supprimera néanmoins au moins certains risques. Et s'il y a un bug potentiel, je le saurai tout de suite, c'est-à-dire littéralement dans quelques minutes. Je n'aurai pas besoin de reculer de 3 mois. Je n'aurai besoin que de revenir en arrière de 2 minutes. Une bonne machine à café n’aura même pas le temps de préparer du café en 2 minutes, donc c’est plutôt cool.
Cela a l'avantage de pouvoir être répété à maintes reprises sur chaque projet, c'est-à-dire pas seulement celui sur lequel vous l'avez installé. Vous pouvez répéter à la fois la pratique elle-même et CI elle-même sera répétée pour chaque nouvelle modification que vous apportez au projet. Cela vous permet d'optimiser les ressources car votre équipe travaille plus efficacement. Vous ne serez plus confronté à une situation où un bug vous vient du code avec lequel vous avez travaillé il y a 3 mois. Vous n'aurez plus à changer de contexte lorsque vous passerez les deux premières heures à essayer de comprendre ce qui s'est passé ensuite et à entrer dans l'essence du contexte avant de commencer à corriger quelque chose.
Comment mesurer le succès ou l’échec de cette pratique ? Si vous rapportez au grand patron ce que nous avons mis en œuvre sur le projet CI, il entend du bla bla bla. Nous l’avons mis en œuvre, d’accord, mais pourquoi, qu’est-ce que cela nous a apporté, comment le mesurer, dans quelle mesure le mettons-nous en œuvre correctement ou incorrectement ?
La première est que grâce au CI, nous pouvons déployer de plus en plus souvent, et plus souvent précisément parce que notre code est potentiellement plus stable. De la même manière, notre temps pour trouver une erreur est réduit et le temps pour corriger cette erreur est réduit précisément parce que nous recevons une réponse du système ici et maintenant, ce qui ne va pas avec notre code.
Une autre pratique que nous avons est la pratique des tests d'automatisation, qui accompagne le plus souvent la pratique CI. Ils vont de pair.
Qu’est-ce qu’il est important de comprendre ici ? Il est important de comprendre que nos tests sont différents. Et chaque test automatisé vise à résoudre ses propres problèmes. Nous avons par exemple des tests unitaires qui nous permettent de tester un module séparément, c'est à dire Comment ça marche dans le vide ? C'est bon.
Nous disposons également de tests d'intégration qui nous permettent de comprendre comment les différents modules s'intègrent les uns aux autres. C'est aussi bien.
Nous pouvons avoir des tests d'automatisation de l'interface utilisateur qui nous permettent de vérifier dans quelle mesure le travail avec l'interface utilisateur répond à certaines exigences définies par le client, etc.
Les tests spécifiques que vous exécutez peuvent affecter la fréquence à laquelle vous les exécutez. Les tests unitaires sont généralement écrits courts et petits. Et ils peuvent être lancés régulièrement.
Si nous parlons de tests d’automatisation de l’interface utilisateur, alors c’est bien si votre projet est petit. Vos tests d’automatisation de l’interface utilisateur peuvent prendre un certain temps. Mais généralement, un test d’automatisation de l’interface utilisateur prend plusieurs heures sur un grand projet. Et c'est bien si c'est quelques heures. La seule chose est qu’il ne sert à rien de les exécuter pour chaque build. Il est logique de les exécuter la nuit. Et quand tout le monde est venu travailler le matin : les testeurs et les développeurs ont reçu une sorte de rapport indiquant que nous avions exécuté l'autotest de l'interface utilisateur la nuit et obtenu ces résultats. Et ici, une heure de travail d'un serveur qui vérifiera que votre produit répond à certaines exigences sera bien moins chère qu'une heure de travail du même ingénieur QA, même s'il est un ingénieur QA Junior qui travaille pour l'alimentation et merci. Néanmoins, une heure de fonctionnement de la machine coûtera moins cher. C’est pourquoi il est judicieux d’y investir.
J'ai un autre projet sur lequel je travaille. Nous avons eu des sprints de deux semaines sur ce projet. Le projet était vaste, important pour le secteur financier, et aucune erreur ne pouvait être commise. Et après un sprint de deux semaines, le cycle de développement a été suivi d'un processus de test, qui a duré encore 4 semaines. Essayez d'imaginer l'ampleur de la tragédie. Nous écrivons du code pendant deux semaines, puis nous le faisons à la manière de CodeFreeze, le conditionnons dans une nouvelle version de l'application et le déployons auprès des testeurs. Les testeurs le testent pendant encore 4 semaines, c'est-à-dire Pendant qu'ils le testent, nous avons le temps de leur préparer deux versions supplémentaires. C'est un cas vraiment triste.
Et nous leur avons dit que si vous voulez être plus productif, il est logique que vous mettiez en œuvre des pratiques de tests automatisés, car c'est ce qui vous fait mal ici et maintenant.
Pratiquez le déploiement continu. Super, vous avez terminé la construction. C'est déjà bien. Votre code a été compilé. Maintenant, ce serait bien de déployer cette version sur un environnement. Disons dans un environnement pour développeurs.
Pourquoi c'est important? Tout d’abord, vous pouvez vérifier dans quelle mesure vous réussissez le processus de déploiement lui-même. J'ai rencontré des projets comme celui-ci, quand je demande : « Comment déployer une nouvelle version de l'application ? », les gars me disent : « Nous l'assemblons et l'emballons dans une archive zip. Nous l'envoyons à l'administrateur par mail. L'administrateur télécharge et développe cette archive. Et tout le bureau commence à prier pour que le serveur récupère la nouvelle version.
Commençons par quelque chose de simple. Par exemple, ils ont oublié de mettre CSS dans l'archive ou de modifier le hashtag dans le nom du fichier java-script. Et lorsque nous faisons une requête au serveur, le navigateur pense qu'il possède déjà ce fichier java-script et décide de ne pas le télécharger. Et il y avait une ancienne version, il manquait quelque chose. En général, il peut y avoir de nombreux problèmes. Par conséquent, la pratique du déploiement continu vous permet au moins de tester ce qui se passerait si vous preniez une image de référence propre et la téléchargiez dans un nouvel environnement complètement propre. Vous pouvez voir où cela mène.
De plus, lorsque vous intégrez du code entre vous, c'est-à-dire entre les commandes, cela vous permet également de voir à quoi cela ressemble sur l'interface utilisateur.
L'un des problèmes qui surviennent lorsque de nombreux javascripts Vanilla sont utilisés est que deux développeurs déclarent imprudemment une variable portant le même nom dans l'objet window. Et puis, selon votre chance. Le fichier java-script qui est extrait en deuxième écrasera les modifications de l'autre. C'est aussi très excitant. Vous entrez : une chose fonctionne pour une personne, une autre ne fonctionne pas pour une autre. Et c’est « merveilleux » quand tout cela sort en production.
La prochaine pratique que nous avons est la pratique de la restauration automatique, à savoir le retour à la version précédente de l'application.
Pourquoi est-ce important pour les développeurs ? Il y a encore ceux qui se souviennent des années 90 lointaines, lorsque les ordinateurs étaient grands et les programmes petits. Et le seul moyen de développer du Web passait par PHP. Ce n'est pas que PHP soit un mauvais langage, même si c'est le cas.
Mais le problème était différent. Lorsque nous avons déployé une nouvelle version de notre site php, comment l'avons-nous déployée ? Le plus souvent, nous avons ouvert Far Manager ou autre chose. Et j'ai téléchargé ces fichiers sur FTP. Et nous avons soudainement réalisé que nous avions un petit, petit bug, par exemple, nous avons oublié de mettre un point-virgule ou oublié de changer le mot de passe de la base de données, et il existe un mot de passe pour la base de données, qui se trouve sur l'hôte local. Et nous décidons de nous connecter rapidement à FTP et d'éditer les fichiers directement sur place. C'est juste du feu ! C'est ce qui était populaire dans les années 90.
Mais si vous n’avez pas regardé le calendrier, les années 90, c’était il y a presque 30 ans. Maintenant, tout se passe un peu différemment. Et essayez d'imaginer l'ampleur de la tragédie lorsqu'ils vous disent : « Nous avons déployé la production, mais quelque chose s'est mal passé là-bas. Voici votre identifiant et votre mot de passe FTP, connectez-vous à la production et corrigez-les rapidement. Si vous êtes Chuck Norris, cela fonctionnera. Sinon, vous risquez que si vous corrigez un bug, vous en créerez 10 de plus. C'est précisément pourquoi cette pratique de retour à la version précédente vous permet d'accomplir beaucoup de choses.
Même si quelque chose de mauvais est entré en production quelque part, alors c'est mauvais, mais pas fatal. Vous pouvez revenir à la version précédente dont vous disposez. Appelez cela une sauvegarde, s'il est plus facile de le percevoir dans cette terminologie. Vous pouvez revenir à cette version précédente et les utilisateurs pourront toujours travailler avec votre produit et vous disposerez d'un temps tampon suffisant. Vous pouvez tranquillement, sans hâte, prendre tout cela et le tester localement, le corriger, puis télécharger une nouvelle version. C'est vraiment logique de faire cela.
Essayons maintenant de combiner d'une manière ou d'une autre les deux pratiques précédentes. Nous en aurons un troisième appelé Release Management.
Lorsque nous parlons de déploiement continu dans sa forme classique, nous disons que nous devons extraire le code d'une branche du référentiel, le compiler et le déployer. C'est bien si nous avons le même environnement. Si nous avons plusieurs environnements, cela signifie que nous devons extraire le code à chaque fois, même à partir du même commit. Nous le retirerons à chaque fois, nous le construirons à chaque fois et nous le déploierons dans un nouvel environnement. Premièrement, c'est le moment, car pour construire un projet, si vous en avez un grand et que vous venez des années 90, cela peut prendre plusieurs heures.
En plus, il y a une autre tristesse. Lorsque vous buildez, même sur la même machine, vous construirez les mêmes sources, vous n'avez toujours aucune garantie que cette machine soit dans le même état qu'elle était lors du dernier build.
Disons que quelqu'un est venu et a mis à jour DotNet pour vous ou, à l'inverse, que quelqu'un a décidé de supprimer quelque chose. Et puis vous avez une dissonance cognitive selon laquelle, à partir de ce commit il y a deux semaines, nous construisions une build et tout allait bien, mais maintenant cela semble être la même machine, le même commit, le même code que nous essayons de construire, mais cela ne fonctionne pas. . Vous devrez faire face à cela pendant longtemps et ce n’est pas un fait que vous y arriverez. À tout le moins, vous vous gâterez beaucoup les nerfs.
Par conséquent, la pratique de Release Management suggère d’introduire une abstraction supplémentaire appelée référentiel, galerie ou bibliothèque d’artefacts. Tu peux appeler ça comme tu le veux.
L'idée principale est que dès que nous avons une sorte de commit, disons, dans une branche que nous sommes prêts à déployer dans nos différents environnements, nous collectons les applications de ce commit et tout ce dont nous avons besoin pour cette application, nous l'emballons dans une archive zip et enregistrez-la dans un stockage fiable. Et à partir de ce stockage, nous pouvons récupérer cette archive zip à tout moment.
Ensuite, nous le prenons et le déployons automatiquement dans l'environnement de développement. Nous courons là-bas, et si tout va bien, alors nous montons sur scène. Si tout va bien, alors nous déployons la même archive en production, les mêmes binaires, compilés exactement une seule fois.
De plus, lorsque nous avons une galerie comme celle-ci, cela nous aide également à gérer les risques que nous avons évoqués sur la dernière diapositive lorsque nous parlions du retour à la version précédente. Si vous avez accidentellement déployé quelque chose de mal, vous pouvez toujours prendre n'importe quelle autre version précédente de cette galerie et l'annuler dans ces environnements de la même manière. Cela vous permet de revenir facilement à la version précédente en cas de problème.
Il existe une autre excellente pratique. Vous et moi comprenons tous que lorsque nous restaurons nos applications vers une version précédente, cela peut signifier que nous avons également besoin de l'infrastructure de la version précédente.
Lorsque nous parlons d’infrastructure virtuelle, beaucoup de gens pensent que c’est quelque chose que les administrateurs mettent en place. Et si vous avez besoin, par exemple, d'obtenir un nouveau serveur sur lequel vous souhaitez tester une nouvelle version de votre application, vous devez alors écrire un ticket aux administrateurs ou aux développeurs. Devops prendra 3 semaines pour cela. Et au bout de 3 semaines, ils vous diront que nous avons installé pour vous une machine virtuelle, avec un cœur, deux gigaoctets de RAM et un serveur Windows sans DotNet. Vous dites : « Mais je voulais DotNet. » Ils : « Ok, reviens dans 3 semaines. »
L’idée est qu’en utilisant les pratiques Infrastructure as Code, vous pouvez traiter votre infrastructure virtuelle comme une simple ressource parmi d’autres.
Peut-être que si l'un d'entre vous développe des applications sur DotNet, vous avez peut-être entendu parler d'une bibliothèque appelée Entity Framework. Et vous avez peut-être même entendu dire qu'Entity Framework est l'une des approches activement défendues par Microsoft. Pour travailler avec une base de données, il s'agit d'une approche appelée Code First. C'est à ce moment-là que vous décrivez dans le code à quoi vous souhaitez que votre base de données ressemble. Et puis vous déployez l’application. Il se connecte à la base de données, détermine lui-même quelles tables sont présentes et lesquelles ne le sont pas, et crée tout ce dont vous avez besoin.
Vous pouvez faire la même chose avec votre infrastructure. Il n'y a aucune différence entre si vous avez besoin d'une base de données pour un projet ou si vous avez besoin d'un serveur Windows pour un projet. C'est juste une ressource. Et vous pouvez automatiser la création de cette ressource, vous pouvez automatiser la configuration de cette ressource. En conséquence, chaque fois que vous souhaitez tester un nouveau concept, une nouvelle approche, vous n'aurez pas besoin d'écrire un ticket pour DevOps, vous pouvez simplement déployer vous-même une infrastructure isolée à partir de modèles prêts à l'emploi, de scripts prêts à l'emploi et l'implémenter. là toutes vos expériences. Vous pouvez le supprimer, obtenir des résultats et en rendre compte davantage.
La prochaine pratique, qui existe également et qui est également importante, mais que peu de gens utilisent, est la surveillance des performances des applications.
Je voulais dire une seule chose à propos de la surveillance des performances des applications. Qu’est-ce qui est le plus important dans cette pratique ? C'est en quoi consiste la surveillance des performances des applications, à peu près la même chose que la réparation d'un appartement. Ce n’est pas un état final, c’est un processus. Vous devez le faire régulièrement.
Dans le bon sens, il serait bon d'effectuer une surveillance des performances des applications sur presque toutes les versions, même si, comme vous le comprenez, cela n'est pas toujours possible. Mais, au minimum, cela doit être effectué pour chaque version.
Pourquoi c'est important? Parce que si vous constatez soudainement une baisse de performances, vous devez alors comprendre clairement pourquoi. Si votre équipe a, disons, des sprints de deux semaines, alors au moins une fois toutes les deux semaines, vous devez déployer votre application sur un serveur distinct, sur lequel vous disposez d'un processeur, d'une RAM, de disques, etc. clairement fixes. Et exécutez ces mêmes tests de performances. . Vous obtenez le résultat. Voyez comment cela a changé par rapport au sprint précédent.
Et si vous découvrez que le retrait a fortement diminué quelque part, cela signifiera que c'est simplement à cause des changements survenus au cours des deux dernières semaines. Cela vous permettra d'identifier et de résoudre le problème beaucoup plus rapidement. Et encore une fois, ce sont à peu près les mêmes mesures par lesquelles vous pouvez mesurer votre réussite.
La pratique suivante que nous avons est la pratique de gestion de configuration. Rares sont ceux qui prennent cela au sérieux. Mais croyez-moi, c'est en réalité une chose très sérieuse.
Il y a eu une histoire amusante récemment. Les gars sont venus me voir et m'ont dit : « Aidez-nous à réaliser un audit de sécurité de notre application. » Nous avons longuement regardé le code ensemble, ils m'ont parlé de l'application, ont dessiné des schémas. Et plus ou moins, tout était logique, compréhensible, sûr, mais il y avait un MAIS ! Ils avaient des fichiers de configuration dans leur contrôle de source, y compris ceux issus de la production avec la base de données IP, avec les logins et mots de passe pour se connecter à ces bases de données, etc.
Et je dis : « Les gars, d'accord, vous avez fermé votre environnement de production avec un pare-feu, mais le fait que vous ayez le login et le mot de passe de la base de données de production directement dans le contrôle de code source et que tout développeur puisse le lire est déjà un énorme risque de sécurité. . Et peu importe le degré de sécurité de votre application du point de vue du code, si vous la laissez sous contrôle de code source, vous ne passerez aucun audit nulle part. C'est ce dont je parle.
Gestion de la configuration. Nous pouvons avoir différentes configurations dans différents environnements. Par exemple, nous pouvons avoir des identifiants et des mots de passe différents pour les bases de données destinées au contrôle qualité, à la démonstration, à l'environnement de production, etc.
Cette configuration peut également être automatisée. Il doit toujours être distinct de l'application elle-même. Pourquoi? Parce que vous avez construit l'application une fois, et qu'ensuite l'application ne se soucie pas de savoir si vous vous connectez au serveur SQL via telle ou telle IP ou telle ou telle IP, cela devrait fonctionner de la même manière. Par conséquent, si soudainement l'un de vous code toujours en dur la chaîne de connexion dans le code, n'oubliez pas que je vous trouverai et vous punirai si vous vous retrouvez sur le même projet que moi. Celui-ci est toujours placé dans une configuration distincte, par exemple dans web.config.
Et cette configuration est déjà gérée séparément, c'est à dire que c'est justement le moment où un développeur et un administrateur peuvent venir s'asseoir dans la même pièce. Et le développeur peut dire : « Regardez, voici les binaires de mon application. Ils travaillent. L'application a besoin d'une base de données pour fonctionner. Ici, à côté des binaires, il y a un fichier. Dans ce fichier, ce champ est responsable du login, ceci est du mot de passe, ceci est de l'IP. Déployez-le n'importe où. Et c’est simple et clair pour l’administrateur. Il peut le déployer vraiment n'importe où en gérant cette configuration.
Et la dernière pratique dont je voudrais parler est une pratique très, très liée aux nuages. Et cela apporte un effet maximal si vous travaillez dans le cloud. Il s'agit d'une suppression automatique de votre environnement.
Je sais qu'il y a plusieurs personnes à cette conférence parmi les équipes avec lesquelles je travaille. Et avec toutes les équipes avec lesquelles je travaille, nous utilisons cette pratique.
Pourquoi? Bien sûr, ce serait formidable si chaque développeur disposait d’une machine virtuelle qui fonctionnerait 24h/7 et 24j/7. Mais c'est peut-être une nouvelle pour vous, peut-être que vous n'y avez pas prêté attention, mais le développeur lui-même ne travaille pas 8h/12 et 5j/7. Un développeur travaille généralement XNUMX heures par jour. Même s'il arrive tôt au travail, il prend un grand déjeuner pendant lequel il va à la salle de sport. Que ce soit XNUMX heures par jour pendant lesquelles le développeur utilise réellement ces ressources. Selon notre législation, nous avons XNUMX jours sur XNUMX dans une semaine qui sont considérés comme des jours ouvrables.
En conséquence, en semaine, cette machine ne devrait pas fonctionner 24 heures sur 12, mais seulement 70 heures, et le week-end, cette machine ne devrait pas fonctionner du tout. Il semblerait que tout soit très simple, mais qu'est-ce qu'il est important de dire ici ? En mettant en œuvre cette pratique simple sur ce planning de base, cela vous permet de réduire le coût de maintenance de ces environnements de 3%, c'est à dire que vous avez pris le prix de votre développement, QA, démo, environnement et l'avez divisé par XNUMX.
La question est : que faire du reste de l’argent ? Par exemple, les développeurs devraient acheter ReSharper s’ils ne l’ont pas déjà fait. Ou organisez un cocktail. Si vous aviez auparavant un environnement dans lequel le développement et l'assurance qualité broutaient, et c'est tout, vous pouvez désormais en créer 3 différents qui seront isolés et les gens n'interféreront pas les uns avec les autres.
Concernant le slide avec mesure continue des performances, comment comparer les performances si on avait 1 000 enregistrements dans la base de données du projet, deux mois plus tard il y en a un million ? Comment comprendre pourquoi et à quoi sert mesurer la performance ?
C’est une bonne question, car vous devez toujours mesurer les performances sur les mêmes ressources. Autrement dit, vous déployez un nouveau code, vous mesurez les performances du nouveau code. Par exemple, vous devez tester différents scénarios de performances, disons que vous souhaitez tester les performances de l'application sur une charge légère, où il y a 1 000 utilisateurs et la taille de la base de données est de 5 gigaoctets. Vous l'avez mesuré et obtenu les chiffres. Ensuite, nous prenons un autre scénario. Par exemple, 5 000 utilisateurs, taille de base de données 1 téraoctet. Nous avons reçu les résultats et nous les avons mémorisés.
Qu'est-ce qui est important ici ? L'important ici est que selon le scénario, le volume de données, le nombre d'utilisateurs simultanés, etc., vous pouvez rencontrer certaines limites. Par exemple, jusqu'à la limite d'une carte réseau, ou jusqu'à la limite d'un disque dur, ou jusqu'à la limite des capacités du processeur. C’est ce qu’il est important que vous compreniez. Dans différents scénarios, vous rencontrez certaines limites. Et vous devez comprendre les chiffres lorsque vous les frappez.
Parlons-nous de mesurer les performances dans un environnement de test spécial ? Autrement dit, ce n'est pas de la production ?
Oui, ce n’est pas de la production, c’est un environnement de test, qui est toujours le même pour que vous puissiez le comparer avec les mesures précédentes.
Compris, merci!
S'il n'y a pas de questions, je pense que nous pouvons terminer. Merci!
Source: habr.com