Julien Pivotto
Transcription (Traduit)
Donc, je vais vous parler de DevOps, mais je suppose que pour beaucoup d'entre vous, tout cela ne sera pas nouveau, peut-être certaines choses, mais beaucoup de gens le font déjà, donc sans connaître le nom, sans vouloir simplement dire, oh, je fais du DevOps, non, vous le faites simplement, et c'est vraiment super. Alors, où en suis-je ?
Donc, je m'appelle Jean-Pierre Vautour, je suis consultant chez Inuit.
Je défends les logiciels open source depuis 2004. Et depuis que j'ai commencé à travailler, j'ai toujours été un évangéliste et un croyant de DevOps.
Et vous pouvez me trouver sur Twitter et GitHub également. Alors, InWits, faisons une petite introduction. Donc, InWits est une entreprise belge, mais nous sommes présents dans quatre pays différents : la Belgique, les Pays-Bas, l'Ukraine et la République tchèque. Et nous sommes 50 personnes. Nous avons des clients dans toute l'Europe. Et nous faisons à la fois le développement et l'exploitation de logiciels open source. Nous avons beaucoup de clients, y compris des petites et grandes entreprises, des banques, donc nous voyons beaucoup de structures différentes, beaucoup de professionnels de l'IT différents, beaucoup de clients provenant de tous les différents domaines que vous pouvez imaginer. Mais revenons à ce pour quoi nous sommes ici, donc DevOps.
Oui, qu'est-ce que DevOps ? En avez-vous entendu parler ? Probablement oui. Cela signifie beaucoup de choses pour beaucoup de gens, beaucoup de choses différentes.
Et je vais essayer de vous montrer quelle est notre vision, la vision des personnes qui ont créé le mouvement.
Donc, prenons un atelier de développement traditionnel, nous sommes dans une conférence agile, donc je peux m'attendre à ce que ce ne soit plus le cas déjà dans vos différentes entreprises. Au moins, je l'espère pour vous. Mais dans les ateliers de développement traditionnels, vendredi, 17 heures. C'était un turbo, mettez ce code en production, non. Parce que nous sommes à la télévision nationale dans 20 minutes. Donc l'autre, et c'est, Cela arrive encore dans beaucoup d'environnements différents et même dans certains environnements agiles lorsque vous développez votre produit, mais quand il est développé, quand votre code est peut-être testé, il est prêt, mais la dernière étape n'est tout simplement pas faisable comme ça. C'est tout simplement trop compliqué. Et de l'autre côté,
vous avez les opérateurs. Oui, ils demandent, d'accord, quelles sont les dépendances, les bases de données ? Ils posent beaucoup de questions différentes qui sont pertinentes pour eux, mais auxquelles beaucoup de développeurs ne pensaient tout simplement pas, ils n'y avaient pas réfléchi, parce que oui, ça marche sur leur machine. Quel GDK doivent-ils utiliser ? Eh bien, le GDK sur leur machine fonctionne simplement. Et puis après une danse serrée en production, tout explose. Et personne n'a la moindre idée de pourquoi. Pourquoi ça ne marche pas, pourquoi ce n'est pas accessible. Et ils commencent à se rejeter la faute, comme, d'accord, c'est à cause de l'équipe ops. Ils n'ont pas mis la surveillance sur cette partie. Et les devs disent, d'accord, ouais, ce n'est pas notre affaire. Et puis les opérateurs disent, d'accord, nous ne savions pas que nous devions surveiller ça. Base de données SQL ou que c'est vraiment une base de données. Alors, que se passe-t-il vraiment en coulisses ?
Pourquoi les différentes personnes sont-elles payées ? Donc les devs et les ops.
Quels sont les objectifs de chacun ?
Eh bien, les développeurs sont payés pour créer de nouvelles fonctionnalités. De l'autre côté, les opérateurs sont payés pour obtenir plus de stabilité afin que l'application soit toujours stable.
Les développeurs veulent faire de nouvelles releases. Ils veulent atteindre leurs objectifs en implémentant de nouvelles fonctionnalités. Tandis que les ops s'occupent de la disponibilité des applications. Donc l'application doit être disponible 7 jours sur 7, 24 heures sur 24.
Le développeur doit être capable de répondre aux changements, comme dans le Manifeste Agile. Donc ils veulent pouvoir développer rapidement, tester rapidement. Mais de l'autre côté, les opérateurs se soucient de la sécurité. Donc ils ne veulent tout simplement pas que vous alliez dans la base de données et que vous mettiez à jour votre propre dump ou que vous fassiez quoi que ce soit de ce genre.
Ils travaillent dans des silos différents et ne se parlent pas. Donc ce qui se passe, c'est qu'ils ont des objectifs différents. Ils ne veulent pas les mêmes choses à ce moment-là et c'est un peu
C'est, vous ne pouvez pas comprendre cela parce que le but des deux est qu'ils soient payés et qu'ils mettent simplement l'application en production et qu'elle fonctionne. Mais si vous êtes agile, si vous êtes agile dans un seul silo, si seuls les développeurs sont agiles et que ça s'arrête là, alors vous avez un problème. Vous allez avoir des problèmes.
Mais si nous regardons de plus près, alors les développeurs font aussi du travail d'administrateur système parce qu'ils testent leur produit, ils font du travail sur les bases de données, ils font de petits déploiements sur leur ordinateur portable. Et les ops, ils font aussi une sorte de développement. Donc peut-être qu'ils font des scripts batch en Python, ils font de l'infrastructure en tant que code, ils font des scripts de surveillance, donc ils ne sont pas si... Ce sont toujours des métiers différents, mais ils font parfois un peu les mêmes choses. Mais la réalité est que l'IT évolue.
Vous obtenez plus de vélocité.
Il y a des mots à la mode comme le cloud, les conteneurs. Tout cela change beaucoup de choses. Vous avez des environnements volatils. Vous pouvez avoir 10 machines virtuelles aujourd'hui, 20 demain.
Vous devez être scalable. Il y a maintenant un marché global, donc vous n'avez pas seulement des utilisateurs de 9h à 17h. Vous avez des utilisateurs à tout moment de la journée, de la nuit, qui viennent de n'importe quels pays. Donc vous devez vous soucier de la disponibilité. Et il n'y a pas de place pour les anciennes équipes, pour les personnes qui travaillent de leur côté, et je me fiche du reste.
Donc c'est ça, DevOps. C'est simplement faire travailler ensemble les développeurs et les opérateurs. Ce n'est rien de plus que ça. C'est revenir aux bases et simplement mettre tout le monde dans le même groupe et
Il y a beaucoup de gens qui ont réfléchi et fait cela depuis plus de 10 ans. Ils le faisaient simplement dans leur entreprise. Et puis ils ont décidé qu'ils devaient répandre la parole à tout le monde. Personne ne savait de cela, de ce qu'ils faisaient, parce que fondamentalement, l'IT était brisé. Il y avait beaucoup de silos partout dans le monde, et dans chaque entreprise, ça ne fonctionnait tout simplement pas. Donc ils ont décidé de faire une première conférence en 2009 à Gand. Et cette année, en 2014, c'était le cinquième anniversaire des DevOps Days. Donc c'était une conférence avec, il y avait 60 personnes au début, mais ensuite il y aura des dizaines d'événements, y compris un à Paris en 2013. Et les gens sont venus et ils ont simplement partagé leur expérience. Ils font des expériences. Et les DevOps Days étaient comme ça. Donc le matin, vous avez des conférences avec des intervenants venant de nombreux horizons différents. Et l'après-midi, vous avez des espaces ouverts. Ce que vous obtenez est ce que vous apportez. Donc si vous voulez participer à un espace ouvert, vous y allez simplement, vous discutez. Et puis si vous ne voulez pas, alors vous pouvez simplement sortir. Et cela signifie que les gens doivent être impliqués. Parce que si vous n'êtes pas impliqué, alors vous dépensez simplement votre argent dans les conférences, peut-être en dormant ou en faisant autre chose. Mais l'après-midi, si vous ne participez pas, vous allez simplement vous asseoir sur une chaise et ne rien faire. Et ce sera très ennuyeux. Donc DevOps Days, c'est aussi une question d'implication des gens. Et il y a certaines grandes entreprises qui aussi Elles organisent leurs propres DevOps, elles sont même privées, parce qu'elles ont une grande équipe, elles ont peut-être 200 personnes qui travaillent ensemble et elles veulent améliorer le flux de travail, alors elles Elles ne veulent pas faire partie d'un DevOps externe parce qu'elles ont déjà beaucoup de personnes différentes avec beaucoup de problèmes. Et ce qu'elles voulaient, c'est simplement pouvoir parler sans avoir de fuites, afin de pouvoir discuter librement des vrais problèmes, parler des serveurs, du vrai business. Si vous étiez dans le monde bancaire, par exemple, vous ne pouvez pas parler de ce que vous voulez. Donc certaines grandes entreprises ont fait cela. Elles ont leurs propres journées DevOps internes, et cela fonctionne plutôt bien. Donc DevOps est un mouvement culturel et professionnel. Donc les deux aspects sont importants. Donc ce n'est pas seulement une question de professionnels, ce n'est pas seulement une question de culture, ce sont vraiment les deux mondes.
Donc, le ROPSIS est divisé en quatre principaux sujets différents. Tout d'abord, la culture, l'automatisation, la mesure et le partage.
Et c'est ce que John Willis et Damon Edwards ont écrit dans le DevOps Café. Parce qu'au début, ils parlaient simplement de DevOps, mais il n'y avait pas de définition claire. Tout le monde venait et expliquait sa propre chose, mais à un certain moment, ils avaient besoin d'une sorte de définition ou d'explication pour pouvoir Impliquer plus de gens, intéresser plus de personnes. Mais que peut vous apporter DevOps ?
Eh bien, tout d'abord, cela vous apportera un délai de mise sur le marché plus rapide, ce qui est vraiment important, ce qui est une valeur clé. Mais aussi une certaine fiabilité de votre infrastructure que vous n'avez pas lorsque vous n'êtes pas conscient de ce qui se passe. Cela vous donnera une vision claire de ce qui se passe et quand. Et cela vous apportera également une certaine confiance entre les différentes personnes qui travaillent sur vos projets.
Mais commençons d'abord par la partie culturelle.
Donc une entreprise informatique traditionnelle aura encore cela. Et beaucoup d'entreprises ont cela à cause de l'héritage ou parce que cela doit être ainsi, donc elles ont différents silos. Dans ce silo, vous avez les développeurs, puis les opérateurs, et ensuite vous pourriez avoir d'autres silos comme l'équipe QA ou l'équipe de test ou même l'équipe de surveillance, et vous pouvez encore avoir plus de silos. Et le problème avec les silos, c'est que les gens ne peuvent pas parler entre les différents silos parce qu'ils sont dans une équipe et parfois ils doivent d'abord parler au manager. Mais ce n'est pas comme ça que ça marche. Ce n'est pas ainsi que fonctionne l'informatique. Donc la première chose que vous devrez faire, ou cela ne se fera pas en un jour, bien sûr, mais vous devez brûler les silos. Et pourquoi devez-vous brûler les silos ? Parce que vous ne voulez qu'une seule équipe. Une équipe qui aura des personnes avec différentes compétences. Donc développement, intégration, tests, infrastructure, surveillance, tout cela doit être dans une seule équipe. Et pourquoi voulons-nous une seule équipe ? Parce que nous voulons une équipe avec un seul objectif. Aider l'entreprise.
que les gens doivent comprendre qu'ils ont le même intérêt à avoir l'application opérationnelle et à mettre en production de nouvelles fonctionnalités dès que possible. Ainsi, ils peuvent être payés par l'entreprise et l'entreprise peut simplement vendre ses produits et ainsi gagner de l'argent pour payer les développeurs et les opérateurs et toutes les autres personnes dans les équipes. Donc l'objectif de l'équipe est simplement d'aider l'entreprise. Comment faites-vous cela ?
Eh bien, d'abord, vous devrez permettre la communication.
Cela signifie pas de bureaux fermés. Idéalement, vous mélangerez espaces ouverts et bureaux, mais les gens doivent s'asseoir ensemble pour pouvoir simplement se lever et aller poser une question à quelqu'un d'autre. Mais vous devez aussi faire des stand-ups. Si vous êtes dans le monde agile, alors vous savez déjà cela. Mais ce qui est différent ici, c'est que vous devez impliquer vos personnes opérationnelles dans cette réunion, dans ce stand-up, parce qu'elles doivent savoir ce qui se passe, ce qui arrive. Si vous prévoyez de développer une nouvelle fonctionnalité qui impliquera une nouvelle base de données ou que vous allez faire 10 fois plus de lectures dans votre base de données, alors les personnes opérationnelles doivent le savoir à l'avance.
Les gens doivent communiquer par e-mails, chat, ou tout autre moyen, parce que nous sommes dans un monde où beaucoup d'équipes sont réparties dans le monde entier, comme vous avez des développeurs dans un pays et ensuite des testeurs dans un autre pays, peut-être l'équipe QA dans un troisième pays, et alors c'est vraiment l'enfer pour la communication.
Ce qui vous amène au dernier point. Une langue pour les gouverner tous. Parce que, oui, parfois je vais chez un client et puis, oui, toute la documentation est en néerlandais et je ne parle pas un mot de néerlandais. Que peut-il bien se passer alors ? Donc vous avez besoin d'une seule langue. Même dans l'informel,
Même dans les e-mails, par exemple, parce qu'un e-mail peut être transféré. Vous devez insister pour que les gens parlent toujours la même langue. Un monde où de nombreuses équipes sont dispersées aux quatre coins du globe, comme lorsque vous avez des développeurs dans un pays et des testeurs dans un autre, peut-être l'équipe QA dans un troisième pays, et alors la communication devient vraiment un enfer. Qu'est-ce qui vous amène au dernier point ?
Une langue pour les gouverner tous. Parce que, oui, parfois je vais chez un client et, oui, toute la documentation est en néerlandais et je ne parle pas un mot de néerlandais. Que peut-il bien se passer alors ? Donc vous avez besoin d'une seule langue. Même dans les échanges informels, même dans les mails, par exemple, parce que le mail peut être transféré, vous devez insister pour que les gens parlent toujours la même langue.
Et ensuite, vous devez instaurer la confiance.
Donc maintenant, vous avez des personnes qui communiquent, vous avez des opérationnels impliqués dans les différents stand-ups, mais vous devrez instaurer la confiance. Donc vous devrez faire des expérimentations. Lorsqu'il y a un succès, vous devrez le mesurer. Il en va de même pour les échecs. Vous devez automatiser toutes les choses que nous verrons plus tard. Et cela créera une certaine confiance entre les personnes, car les opérationnels sauront à l'avance que les développeurs savent ce qu'ils font et les développeurs sauront que les opérationnels ne veulent pas la même chose qu'eux. Donc ils ont juste besoin, eh bien, de jouer ensemble.
Parce que quand vous êtes seul, vous pouvez encore beaucoup jouer, mais quand vous avez deux personnes différentes, alors vous avez plus d'idées, plus de créativité, et vous pouvez adopter différentes approches. Désolé, pourquoi faites-vous cela comme ça ? Je préférerais le faire d'une autre manière. Pourquoi prenez-vous cette base de données ? Je préférerais utiliser celle-ci parce qu'elle correspondra mieux à nos exigences en matière de stabilité et autres.
C'est aussi plus amusant et il y a plus de compréhension entre les différentes personnes. Parce que si vous ne voyez les autres, si vous ne voyez les opérationnels que lorsqu'il y a un problème, ou si les développeurs ne voient le manager que lorsqu'il y a un problème, alors vous n'avez que des conflits avec votre équipe. Mais si vous commencez à jouer ensemble, à faire des expérimentations, alors vous serez aussi plus compréhensif et développerez plus d'empathie entre les différentes personnes. Et cela vous permettra de construire la confiance entre les personnes.
Ensuite, vous devez partager la responsabilité. Alors, qui est responsable de cette application ? Oh, mais ce sont les gars des ops parce qu'ils font la surveillance, mais qui est responsable de la surveillance ? Oh, mais cette surveillance, nous pensions que c'était, non, tout le monde est responsable. Si vous voyez un problème, vous dites simplement, d'accord, je pense qu'en dernier lieu nous avons un problème et vous, Vous mettez peut-être tout le monde en alerte si c'est nécessaire. Et je dis, tout le monde, c'est vraiment tout le monde, même les managers. Pourquoi voulez-vous mettre les managers en alerte ? Eh bien, c'est simple.
Si ça plante toutes les nuits à 3 heures du matin. Parce qu'il y a un problème d'infrastructure, ou si toutes les heures vous recevez un SMS parce que c'est un faux positif, alors les choses bougeront.
Vous connaissez le phénomène de fatigue des alertes, c'est quand vous recevez beaucoup de mails de votre système d'alerte qui ne sont rien parce que cela n'impacte pas la production. Ce que vous devez faire, c'est impliquer tout le monde. Donc si vous impliquez les managers, alors ils vous aideront à résoudre les problèmes. Ils vous accorderont du temps pour le faire.
Il y aura aussi moins de reproches parce que vous ne chercherez pas à savoir, oh, qui a fait ça ? Oui, qui dois-je blâmer ? Non, vous allez simplement résoudre les différents problèmes.
Mais vous ne pouvez faire cela que si vous donnez accès aux personnes. Donc vous ne voulez pas bloquer les gens. Ils doivent simplement être capables de faire ce qu'ils ont besoin de faire.
Donc si quelqu'un a besoin de pouvoir lire certains logs, alors donnez-lui simplement accès aux logs. Cela ne signifie pas que n'importe qui doit avoir accès à la base de données de production, non. Mais si vous avez besoin de quelque chose et que c'est pertinent, alors vous devriez pouvoir le faire sans demander la permission. Laisseriez-vous une personne aveugle peindre votre maison ? Donc si un développeur va déployer une grosse application dans mon environnement, je veux savoir qu'il peut, qu'il sait ce qu'il fait, qu'il connaît l'impact que cela aura, et qu'il aura une vue de son application parce que, oui, il y a beaucoup de problèmes différents dans l'infrastructure que vous pouvez voir avant qu'ils ne surviennent. Et si les gens n'ont pas accès à l'information, alors ils ne peuvent tout simplement pas faire quelque chose de pertinent pour vous.
Un autre concept de l'agilité, la définition de terminé. Oui, mais quelle est la définition de terminé ?
Un projet logiciel n'est pas terminé tant que votre dernier utilisateur final n'est pas mort. Il y aura toujours de la maintenance, il y aura toujours des correctifs de sécurité. Donc vous ne pouvez pas simplement dire, d'accord, le projet est terminé maintenant. Non, parce qu'il y a encore des gens qui l'utilisent et ils pourraient avoir besoin de votre aide à ce sujet.
Donc la définition de terminé est un peu différente ici.
Donc c'était toute la partie culturelle. Il y a beaucoup d'autres choses là-dedans, mais je m'arrêterai à ce point et attaquerai la deuxième partie. Donc l'automatisation, qui est quelque chose de bien connu dans le monde Agile, mais ce n'est pas, ça vaut le coup de faire un rappel là-dessus. Donc que voulons-nous faire ?
Toutes les choses.
Vous voulez avoir des builds et un build reproductible, pas simplement un développeur qui exécute make ou autre chose et qui envoie un binaire à un serveur ou même par mail.
Vous devez avoir un build sur un serveur de build que tout le monde peut voir, tout le monde peut voir les logs, tout le monde peut voir les artefacts. Et le build doit être robuste.
Et il doit être fait sur un environnement qui ressemble à la production.
Parce que si vous construisez avec JDK 8 ou JDK 7 et que la production est une autre version, alors cela va probablement casser.
Et si vous avez ce build qui est reproductible, alors vous n'avez pas de travail. Oh, ça marche sur ma machine. Je ne sais pas. Vous pourriez avoir tort en production parce que je ne sais pas comment vous l'avez déployé, mais pour moi ça marche. Donc c'est votre problème. Les tests doivent également être automatisés autant que possible. Ainsi, vous pouvez avoir confiance en votre propre code. Et le déploiement doit également être automatisé. Il existe de nombreux outils pour faire cela, pour effectuer le déploiement, les tests et autres de manière automatisée afin que tout le monde puisse voir les logs, tout le monde puisse voir le processus que vous utilisez, et toute l'équipe peut être impliquée dans l'écriture de nouveaux tests, l'écriture de nouvelles fonctionnalités de déploiement. Mais pour faire cela,
vous devez avoir plus confiance en votre code. C'est pourquoi vous voulez automatiser vos builds. C'est pourquoi vous voulez des tests. C'est pourquoi vous voulez beaucoup de différences. C'est juste pour avoir plus confiance en votre code et ne pas avoir peur de le mettre en production parce que vous saurez qu'il ne cassera rien parce que vous avez suffisamment de tests.
Donc l'automatisation des tests, que pouvez-vous tester ? Eh bien, vous pouvez faire des vérifications de style, des vérifications de syntaxe, des tests de régression, des tests de compatibilité, LNRM, Cucumber, le développement piloté par les tests. Donc vous avez différentes approches pour faire les tests. Et plus vous ferez de tests, plus votre test sera mature, alors plus vous aurez confiance. pour simplement déployer le plus souvent possible.
Donc DevOps implique la livraison continue.
Mais pour certaines personnes, la livraison continue implique DevOps. Ce n'est pas mon cas, mais pour certaines personnes, DevOps n'est que de la livraison continue. Donc si vous faites de la livraison continue, alors vous faites simplement du DevOps. Et ils ont complètement oublié la partie culturelle que nous aimons vraiment dans DevOps.
Alors la question suivante, combien peuvent déployer aujourd'hui ? Eh bien, je dirais que ce n'est pas un concours. Ce n'est pas parce que vous déployez 10 fois par jour que vous le faites correctement. Donc ce n'est pas un concours, mais oui, c'est quelque chose qui compte.
Vous avez donc plusieurs principes qui vous permettront de faire cela.
Le premier est l'intégration continue. Donc tout le monde travaille sur la même branche, dans la même branche Git. Vous fusionnez dès que possible, puis vous exécutez les tests, vous déployez le code dans un environnement de développement d'infrastructure, vous le testez, vous effectuez des tests de performance, des tests d'intégration, des tests de mise à niveau.
Et cet environnement, cet environnement de développement sur lequel vous ferez l'intégration continue, devrait idéalement être le même que l'environnement de production. Et cela vous apportera plus de confiance, vous pourrez dire, d'accord, j'ai au moins testé mon code une fois. Et ensuite, vous pouvez faire un pas de plus. Un pas de plus, une fois que vous avez intégré votre test dans un environnement spécial, alors vous pouvez le livrer ou le déployer. Donc la livraison continue et le déploiement continu, ce n'est pas la même chose, je vais vous montrer la différence, mais c'est l'étape suivante. C'est juste que maintenant, j'ai automatisé beaucoup de choses différentes et maintenant je vais simplement déployer cela, le livrer. La première étape est la livraison. La livraison signifie que lorsque vous commitez, vous avez une build, vous avez un artefact, vous avez un moyen de déployer ce que vous venez de pousser. Et ce code est toujours dans un bon état parce que si le test d'intégration a échoué, alors vous n'avez pas fait cette build. Donc s'il y a une build, alors c'est dans un bon état. Je pourrais le déployer en production. Vous pouvez avoir des fonctionnalités masquées, comme dans la conférence précédente, nous avons des fonctionnalités que seul nous voyons. C'est la même chose ici, donc vous obtenez des indicateurs de fonctionnalités. Donc vous savez que... Si la build est déployée en production, alors elle n'aura pas cette fonctionnalité parce qu'elle est trop nouvelle. Si la build est déployée en production, elle ne configurera pas une base de données, par exemple, parce que ce n'est pas encore prêt, mais c'est déjà dans le code. Donc nous n'avons qu'un seul code. Nous ne divisons pas le code entre développement, master, et beaucoup de branches différentes qui ne font qu'apporter de la confusion. Quand vous avez une branche différente, alors vous avez un produit différent, ou vous avez déjà une grosse mise à jour. Mais la plupart du temps, vous ne devriez avoir qu'une seule branche et faire de petits pas et faire de petits commits. Et dans la livraison continue, oui, une action humaine est nécessaire pour déployer. Cela ne signifie pas que quelqu'un doit se connecter en SSH aux serveurs pour mettre à jour l'application, mais cela signifie que les jobs s'arrêteront. Ils n'iront pas jusqu'au déploiement, car c'est le travail du déploiement continu. Et dans ce cas, C'est exactement la même chose que l'événement de livraison. Dans ce cas, vous savez que votre code fonctionnera. Vous l'avez testé. Il n'a pas cassé vos différents environnements. Et vous pouvez simplement le déployer sans temps d'arrêt et faire des mises à niveau silencieuses, de sorte que vous ne remarquiez même pas qu'il a été mis à niveau. Et à ce stade, vous n'avez plus aucune intervention humaine. Mais cela nécessite que vous ayez déjà une infrastructure de test majeure et que vous fassiez confiance à vos tests.
Mais une fois que vous atteignez ce point, alors c'est simplement la fin de la livraison continue. Parce qu'un développeur sait que s'il pousse son code, alors à un moment donné, il sera en production. Eh bien, peu importe le moment des différents tests.
Comment cela se reflète-t-il dans la réalité ? Eh bien, vous obtenez des pipelines. Dans ce cas, ce sont des pipelines Jenkins. Il exécutera beaucoup de jobs différents, mais vous obtiendrez des retours sur ce qui se passe. Vous obtiendrez des graphiques. Vous serez plus confiant dans les différents tests. Que vous lancez. Et les pipelines vous permettent, au lieu d'avoir un gros job, un gros job, d'avoir simplement de petits jobs qui contiennent les vérifications de style, les vérifications de syntaxe, et puis à la fin, vous obtenez simplement une build avec peut-être un bouton ou quelque chose comme ça, il suffit d'appuyer.
Donc vous devez exécuter. Vous devez d'abord faire l'intégration sur une plateforme de développement. Et ensuite, vous pouvez vous entraîner à faire des déploiements sur une infrastructure UATV, donc un environnement de test d'acceptation utilisateur. Dans ce cas, vous amènerez les gens dans un endroit où ils verront toujours le dernier commit fonctionnel de leur produit.
Et une fois qu'il a été déployé en UAT, vous pouvez faire la livraison en production, ce qui signifie qu'à ce stade, vous pouvez considérer que la mise en production est peut-être une décision commerciale, car quand ai-je besoin de livrer cette fonctionnalité ? Peut-être que ce n'est que la semaine prochaine, donc je ne livrerai pas en production. Non, je n'appuierai pas sur le bouton. Mais vous savez que le code a déjà été déployé en UAT en premier.
et ensuite vous obtenez la promotion. Donc d'abord, vous cliquez sur un bouton, pour promouvoir votre build, pour voir, d'accord, cette build est valide, elle fonctionne en UAT, donc je la veux en production, et ensuite vous avez plus confiance en votre code. L'UAT n'a pas planté depuis peut-être six mois, et vous dites, d'accord, nous sommes prêts maintenant, et vous retirez ce bouton.
Donc le code ira dans l'environnement de développement et dans l'UAT où vous pouvez encore avoir des tests d'acceptation. Et ensuite, vous pouvez simplement avoir le code déployé en production.
Mais quelle est la règle concernant les déploiements ? Eh bien, si ça fait mal, si c'est difficile, si ça prend du temps, si c'est ça, faites-le plus souvent. Ainsi, vous pouvez vous améliorer en continu, vous pouvez être plus efficace. Donc si c'est difficile de déployer, Alors apprenez à le faire avec moins de pannes. Quand vous regardez les grands sites web, Facebook, Amazon, ils ne tombent pas en panne à chaque fois qu'ils déploient quelque chose. Donc vous devez apprendre et le faire de plus en plus souvent.
Mais ensuite, vous avez aussi le problème de l'infrastructure. Et il y a un concept appelé infrastructure en tant que code, ce qui signifie que vous considérez l'infrastructure simplement comme un logiciel. Donc vous mettez votre infrastructure sous contrôle de version. Donc vous pouvez avoir l'historique. Vous pouvez la modifier. Vous pouvez voir ce qui changerait cela. Donc, si c'est difficile à déployer, alors apprenez à le faire avec moins de pannes. Quand vous regardez les grands sites web, Facebook, Amazon, ils ne sont pas terminés à chaque fois qu'ils déploient quelque chose. Donc, vous devez apprendre et le faire de plus en plus souvent.
Mais ensuite, vous avez aussi le problème de l'infrastructure. Et il y a un concept appelé infrastructure as code, ce qui signifie que vous considérez l'infrastructure simplement comme un morceau de logiciel. Donc, vous mettez votre infrastructure sous contrôle de version. Ainsi, vous pouvez avoir l'historique, vous pouvez la modifier, vous pouvez voir ce qui changerait cette chose.
Et vous pouvez déployer la surveillance, la sauvegarde, l'application depuis le même endroit. Donc, vous savez que s'il y a un site web, alors il y a une vérification d'Achille pour ce site web, par exemple.
Mais cela ne signifie pas que c'est du scripting bash. Ce n'est pas un script bash dans un dépôt Git. Vous savez, c'est quelque chose comme Puppet, comme Chef, comme un vrai système qui sera capable de répondre aux changements dans votre environnement, qui sera capable de faire des rapports sur ce qui a changé et pourquoi cela a changé.
Mais dans ce cas, alors, oui, votre code de préparation, votre code Chef, oui, c'est du code. Donc, il doit être déployé. Et ce n'est pas. Cela ne signifie pas que vous pouvez simplement écrire votre code privé, le commiter et le pousser directement en production. Non, il doit aussi être testé. Donc, vous devez également l'appliquer aux différents environnements. Rappelez-vous l'UAT, l'environnement de développement. Donc, tout d'abord, vous aurez une petite évolution dans votre code entre les différents environnements. Et la deuxième chose est qu'à ce stade, vous aurez des environnements qui seront les mêmes. Et vous pouvez également faire la promotion et la livraison parce que peut-être voulez-vous d'abord tester les derniers changements dans la base de données MySQL pour voir les performances dans l'UAT avant de les pousser en production. Mais quand vous appuierez sur le bouton pour avoir cela en production, vous connaîtrez l'impact de cela.
Donc, c'est le même chemin qu'un produit. Ainsi, dans ce cas, les personnes des opérations peuvent suivre les mêmes règles que les développeurs.
Et ensuite, vous avez l'orchestration parce que qui veut redémarrer manuellement tous les serveurs HTTPD, par exemple ? Vous avez besoin de quelque chose de plus, vous avez besoin de quelque chose de plus puissant que cela. Personne ne veut se connecter à 20 serveurs l'un après l'autre. Donc, vous avez des outils comme mcollective et Cibble qui peuvent faire cela pour vous.
De plus, la configuration de la base de données des différentes commandes, vous pouvez simplement orchestrer cela.
Et parlons de la troisième partie, qui est la mesure. Et un concept très bien connu dans le monde Kanban et Agile et Scrum est la mesure, le feedback.
Feedback, ai-je vraiment besoin d'en dire plus ? Cela signifie simplement que vous obtiendrez des informations. Vous obtiendrez des informations dès que possible.
La deuxième partie est la matrice. Donc, vous allez collecter des tonnes de matrices, vous allez construire des tableaux de bord, vous allez apprendre de vos logs, ce qui est très important parce que chaque application a des logs, mais combien d'entre eux sont vraiment collectés et
combien d'entre eux font l'objet de tableaux de bord pour voir quand quelque chose ne va pas ? Le log est souvent le premier endroit où vous voulez regarder. Et si le serveur est complètement hors ligne, vous ne voulez pas dire, oh, je ne peux pas voir les logs parce que le serveur est hors ligne. Non, cela n'a aucun sens. Donc, vous ne voudriez pas avoir une sorte de serveur de logs qui collectera tout et vous apprendrez de tout cela. Et cela est valable pour chaque plateforme, comme dans la présentation précédente. Vous devez surveiller votre environnement de développement. Cela ne signifie pas que vous devriez recevoir un SMS à 3 heures du matin parce que l'environnement de développement est hors ligne. Non, mais cela signifie que s'il y a un problème, vous devriez le voir dès que possible. Et si vous pouvez le voir avant qu'il n'aille en production, alors c'est vraiment, vraiment bien. Et quand vous voyez les problèmes tôt, alors vous êtes plus précis. Parce que corriger un problème en développement est moins risqué que de le corriger en production.
Et cela vous permet également de mesurer vos progrès. Parce que si vous ne faites les performances qu'en UAT, ou si vous ne mesurez les performances que dans votre environnement de développement, dans votre environnement de production, alors vous manquerez des informations. Si vous voyez que, oui, c'est la dernière build en production, je vois que j'ai un problème avec l'utilisation de mon CPU, alors vous ne saurez pas quel commit a produit cela. Mais si vous avez déjà fait les vérifications dans l'environnement de développement, vous saurez exactement quand le commit a été introduit et quel est le problème.
Vous pouvez également observer les effets secondaires avant qu'ils n'arrivent en production. Donc, tout cela est très important, c'est que vous ne voulez pas seulement surveiller la production parce que alors vous manquez l'objectif de la surveillance, qui est de prévenir les problèmes. Donc, vous pouvez même commencer par le développement Si vous voyez qu'à un certain moment la build prend deux fois plus de temps, alors vous avez déjà un problème là et vous pouvez directement blâmer les différents changements pour voir ce qui s'est passé exactement.
Si vous voyez que votre couverture de code diminue, vous voyez que vous avez aussi un problème. Donc, vous devez obtenir des métriques de partout. Et ensuite, vous surveillerez le runtime, ce que vous faites toujours. Vous surveillez l'utilisation du disque, le CPU, les E/S, la mémoire.
Mais vous voulez aussi surveiller le middleware. Donc, il n'y a pas que le tableau. Ils ne définiront pas seulement leur produit. Il ne suffit pas de simplement essayer de se connecter au port TCP 80 d'un site web pour voir s'il est opérationnel. Non, vous voulez vérifier le temps de réponse, les utilisateurs, mais aussi les files d'attente, les appels API, les connexions. Et vous devez implémenter dans votre application quelque chose que l'application fait vraiment. Si vous construisez une calculatrice, vous devriez être capable de vérifier si elle peut faire des calculs. Si vous construisez un site web où un utilisateur peut se connecter, vous devriez être capable de surveiller qu'un utilisateur peut effectivement se connecter. Et pas seulement vérifier si vous voyez la première page, car il pourrait y avoir un problème SQL avec la table des utilisateurs que vous ne verrez pas au premier abord.
Donc, vous voulez tester ce que l'application fait vraiment. Et aussi avoir votre avocat entre les deux.
Mais cela prend du temps parce que, oui, plus vous surveillerez, plus vous obtiendrez de faux positifs. Et c'est beaucoup de travail de simplement trouver l'équilibre entre ce dont vous avez vraiment besoin comme information et ce qui n'est pas pertinent, comment corriger vos différentes vérifications. Parce que parfois vous avez un problème de réseau et ce que vous obtenez est un problème d'espace disque. Et ensuite, vous devez d'abord obtenir les bonnes alertes. Il existe de nombreux outils pour faire cela qui peuvent simplement observer ce qui se passe et quels sont les inconvénients de cela.
Nous devons tout mesurer. Donc, cela ne signifie pas seulement la partie informatique. Vous voulez aussi surveiller combien de déploiements vous faites, combien de commits vous effectuez peut-être, ou combien de tickets vous corrigez, les files d'attente de commandes, la longueur, donc vous voulez suivre cela. Vous voulez aussi savoir, oui, d'accord, mon travail en cours. Oh, était-ce hier ? Ou était-ce il y a deux jours ? Oh, mon travail évolue-t-il ? Et ensuite, vous commencez à construire des graphiques. C'est encore une ancienne version de Logstash, mais
vous obtenez des graphiques, ce qui signifie que vous avez une vue dessus. Vous ne collectez pas simplement des données et puis vous les oubliez. Non, vous les utilisez réellement. Si vous êtes une grande entreprise, alors il est encore plus important de pouvoir montrer.
Montrer, d'accord, regardez, nous avons un problème là parce que nous avons beaucoup d'erreurs 500 sur notre serveur Apache. Essayons de trouver ce qui s'est passé.
Parce que parfois, oui, vous allez avoir des problèmes dont vous croirez qu'il n'y a pas d'impact, mais quelque chose de plus gros se cache là.
Donc, vous collectez les matrices, vous collectez vos roches, mais ensuite vous devez faire quelque chose avec elles.
Donc, vous devez en tirer des valeurs commerciales. Donc, oui, vous pouvez toujours obtenir beaucoup de métriques, mais si personne n'y trouve de sens pour l'entreprise, alors les managers, ils ne s'en soucieront tout simplement pas. Donc, vous devrez découvrir ce qui est pertinent. Si vous voulez suivre le nombre d'utilisateurs payants sur votre plateforme, faites-le parce que c'est important. Cela vous montrera la santé de l'entreprise. Si vous voulez partager les tableaux de bord entre les équipes de développement, de gestion et d'exploitation, vous devez avoir des valeurs communes qui parlent à tout le monde.
Bien sûr, les personnes de la gestion n'ont pas besoin d'avoir accès à toutes les métriques. Mais tout de même, elles devraient pouvoir discuter avec vous en disant, d'accord, regardez, nous avons un problème à ce moment-là. Donc, si vous avez un écran ou un tableau de bord, et que le manager passe et voit que, oh, le nombre d'utilisateurs qui prient, a diminué de 10%. Oh, est-ce possible ? Et ensuite, vous lui dites, oui, mais c'est parce que les plateformes deviennent lentes, les gens ne reviennent pas. Et alors le manager saura qu'il y a un problème et ils devront le régler, trouver le temps de le régler. Que se passe-t-il ? Que se passe-t-il, les gars ? C'est pourquoi vous voulez partager le tableau de bord afin que, lorsqu'il y a un problème, lorsque quelque chose ne va pas, tout le monde le sache.
Et ensuite, vous apprendrez pour votre matrice. Quand est-ce que cela s'est produit ? Quand, que se passe-t-il ? Et vous pouvez les utiliser.
Vous pouvez les utiliser, vous pouvez les analyser. Vous pouvez prévenir les défaillances. Donc, si vous vous rendez compte que chaque semaine, vous avez 1% d'espace disque en moins, vous pouvez savoir, d'accord, dans cinq semaines, j'aurai un problème, donc je peux effectivement savoir pour prévenir cela.
Vous pouvez corréler les défaillances. Vous avez des outils, notamment issus de, voyons voir, qui vous permettent simplement, lorsqu'il y a un problème, une anomalie dans un graphique, de savoir combien de graphiques présentent la même anomalie à ce moment-là. Donc, si l'utilisation du CPU est élevée, et qu'en même temps, je vois que les métriques de ma base de données sont toujours élevées, alors j'avance d'un cran, et j'obtiens déjà l'information qui m'aidera à faire mon post-mortem, donc mon analyse des recommandations. Parce que je saurai que, d'accord, le problème n'était pas vraiment le CPU, mais c'était le... à ce moment-là. Vous avez des métriques, mais ne regardez pas seulement une métrique, car un problème devrait impacter plusieurs métriques. Et vous devez savoir laquelle a pris la mauvaise direction en premier, laquelle a causé les autres.
Et cela va du développement à la position.
C'est pour cela que la mesure existe. Donc, avoir des métriques, des K métriques qui ont des valeurs métiers et qui peuvent aussi aider les gens à trouver ce qui ne va pas. Et la dernière partie est le partage.
Donc, vous voulez parler de votre expérience. Vous voulez peut-être utiliser des logiciels open source pour ne pas travailler seul, car si vous êtes dans le secteur des télécommunications ou dans le secteur bancaire, alors vous ne vous souciez pas de partager votre tâche Jenkins pour tester, je ne sais pas quoi, cela n'a pas d'importance, mais vous devez partager avec d'autres entreprises parce que, oui, vous n'êtes pas payé pour faire des trucs Jenkins, mais si vous pouvez obtenir une recette déjà utilisée par quelqu'un d'autre, cela facilitera aussi votre travail. Et quand vous avez du code que quelqu'un d'autre pourrait réutiliser, faites-le. Ainsi, d'autres personnes peuvent l'améliorer et elles peuvent simplement ajouter plus de fonctionnalités dont vous pourriez avoir besoin un jour. Donc, quand vous pouvez publier quelque chose que d'autres personnes réutiliseront, faites-le. Partagez votre expérience parce que le monde de l'IT est grand, mais si chacun joue dans sa propre chambre, alors nous n'avançons pas. Et oui, je partage simplement mon expérience avec vous. Et en conclusion, je vais vous dire ce que DevOps n'est pas, car DevOps concerne les modèles et les anti-modèles. Et DevOps n'est pas, la première chose est,
DevOps, ce n'est pas une question d'outils. Les outils, ils comptent. Oui, il est vraiment important d'avoir des outils parce que si vous n'en avez pas, si vous parlez juste de la manière de faire les choses, vous n'avancez pas, mais ce n'est pas l'objectif de DevOps. Ce n'est pas, oui, vous pourriez appeler certains outils des outils DevOps, mais ce n'est pas l'essentiel de DevOps. C'est vraiment une question de culture, d'automatisation, de mesure et de partage.
Le deuxième thème est que DevOps n'est pas l'ajout d'une nouvelle équipe. Ce n'est pas l'ajout d'une nouvelle personne qui fera des trucs DevOps. Non, car dans ce cas, cette personne ou cette équipe deviendra le goulot d'étranglement, ou pire encore, vous obtiendrez simplement un nouveau silo. Et ce n'est pas ce que vous voulez. Vous ne voulez pas d'un nouveau silo appelé DevOps, car alors vous aurez de nouveaux problèmes. Et si vous avez une super récompense qui peut tout faire dans votre infrastructure, alors un jour ce sera votre problème. Ce que vous voulez, c'est améliorer l'expérience et les connaissances de toute l'équipe, au lieu d'une seule personne qui fera tout le travail et nettoiera tout le désordre.
Comme tout le monde est responsable, chacun nettoie son propre désordre. Donc, si vous faites quelque chose de mal, vous le corrigerez vous-même et ne dépendrez pas des autres. Parce que dans le monde DevOps, les super-héros ne sont pas les bienvenus. Nous ne voulons pas que des personnes soient capables de tout réparer et que le jour où elles sont malades, plus rien ne fonctionne. Ce n'est pas ce que nous voulons.
Ce qui implique que DevOps n'est pas un titre de poste. DevOps n'est pas juste une personne, ce n'est pas, oui, il y a des développeurs que vous pourriez appeler développeurs full stack dans cette expression. Mais DevOps n'est pas un titre de poste. Si quelqu'un vous demande si vous êtes un DevOps, alors vous devriez probablement répondre non.
Parce que DevOps, ce n'est pas ça. Eh bien, si vous considérez que DevOps est la partie intégration continue, la partie livraison continue, alors oui. Mais ce n'est pas le cas. DevOps, c'est plus que ça. Vous n'êtes pas une culture, non. Donc, vous n'êtes pas un DevOps.
DevOps n'est pas une méthodologie, donc ce n'est pas contre Kanban, ce n'est pas contre Scrum, ce n'est pas contre tout ça. DevOps, vous devez toujours gérer vos projets. DevOps ne résoudra pas ce problème pour vous. Donc, vous devez toujours être agile, vous devez toujours utiliser Kanban, vous devez toujours utiliser la méthodologie que vous utilisiez avant. Et c'est la même chose qu'avec Kanban. Dans ce point de DevOps, oui, vous devez le faire fonctionner pour vous.
Parce que DevOps est un voyage, c'est un cliché,
Vous ne pouvez pas un jour aller voir votre patron et dire, d'accord, cassons tous les silos. Oui, faisons des trucs DevOps maintenant. C'est fini. Non, ça ne marchera pas. Il faudra du temps et encore du temps pour arriver au point où vous n'avez plus de silo et où votre application est déployée en continu. Il faut beaucoup de temps pour convaincre les gens, pour leur montrer, pour leur démontrer, pour apporter de nouveaux outils.
Pour apporter la nouvelle culture. Donc, c'est un voyage, un vrai voyage qui prend des années dans les grandes organisations.
D'accord, donc c'est tout. Il y a beaucoup de lectures à ce sujet, donc j'ai mis quelques URL là. Il y a aussi le livre The Phoenix Project.
Et à cet endroit, dans ce lieu, en avril, il y aura à nouveau les DevOps Days Paris, deux ans après le premier, où vous pourrez rencontrer d'autres personnes qui font face aux mêmes problèmes.
Donc, je vous encourage, si vous êtes intéressés, à venir à ces journées et à discuter avec la communauté DevOps.
D'accord.
Merci. Vous pouvez toujours me rencontrer. Je suis toujours là.