C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant tout de la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté
et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration contiere au trou face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contrêts.
DevOps.
L'objectif individuel, ça s'atteint alors qu'une ambition, ça se partage.
Bonjour à tous et à toutes et bienvenue dans un nouveau numéro de DevOps.
Aujourd'hui, on va parler des tests dans le cadre des infrastructures à SCOD.
Pour parler de ce sujet, j'ai Arno qui m'accompagne.
Arno, c'est la première fois qu'il fait un podcast et c'est la première fois donc dans DevOps.
Je te laisse te présenter.
Bonjour à tous. Je m'appelle Arno.
Comme Guy m'a dit, je viens plutôt du monde du développement.
J'ai fait 5 ans en tant que consultant chez Avanade,
donc là, du développement Microsoft en C-Sharp.
Et puis petit à petit, au fur et à mesure de mes missions,
je me suis plus décalé sur un profil Ops et Infra.
Maintenant, j'ai rejoint Microsoft depuis avril.
C'est récent et je fais surtout du cube, du terraform, du terragrunt.
C'est vrai que ça change pas mal de paradigme, je me dirais, du dé en termes d'outillage.
Alors oui, c'est pour ça d'ailleurs que je voulais t'inviter aujourd'hui.
C'est que c'est un profil vraiment différent de ce qu'on a l'habitude d'avoir dans DevOps.
C'est un problème. Je l'ai dit à de nombreuses reprises.
Je voulais avoir plus de développeurs dedans.
Et justement, quand on va parler des tests d'infrastructure AsCode,
je trouve que c'est le pont le plus évident peut-être entre l'infrastructure AsCode
et le monde du développement, parce que les méthodologies employées de tests
vont se ressembler beaucoup à celle qu'on peut avoir dans le monde du développement.
Ou pas d'ailleurs, et c'est ça d'ailleurs la discussion qu'on va essayer de parler.
Donc, on a travaillé ensemble sur des missions avec Arnaud.
Donc, je vous en avais déjà parlé.
Alors, maintenant, il y a longtemps quasiment deux ans sur des travaux au sein de Thales, pour le coup.
Donc, c'est dans ce cadre-là qu'on avait pu travailler ensemble.
Et aujourd'hui, on travaille ensemble sur une autre mission,
sur une mission avec encore des données sensibles.
Donc, vous n'aurez pas de détails, désolé, sur l'infrastructure, sur ce qu'on met en place.
Mais, on va essayer de vous parler du comment et du pourquoi on met en place des tests sur l'infrastructure AsCode.
Donc, si je vais résumer Arnaud et si jamais tu veux participer,
mettre des compléments à ce que je dis, n'hésite pas.
Globalement, donc, le projet est assez vaste avec énormément de composants.
On utilise le cloud Azure pour sponner tous les composants.
Et, en fait, on s'est vite retrouvés devant un problème,
qui est donc que tous les composants sont sponnés avec du Terraform.
Et, en fait, on s'est retrouvés très vite à avoir des problèmes de gestion de ce code,
qui devenait très important, avec des problèmes d'intégration entre tous les blobs.
Et, c'est là où on sait dire, à un moment, que faire des tests serait sans doute intéressant.
Oui, alors, juste une chose, déjà, pour revenir un peu avant d'arriver tout de suite à la forme.
Moi, déjà, une première chose que je vois qui change par rapport au monde des développements,
c'est qu'une phase d'exploration en infrastructure, ça implique de faire les choses manuellement.
Déjà, alors qu'en code, on va peut-être tout de suite commencer à coder, essayer des technologies,
essayer des librairies, essayer des packages, alors que si on commence directement à faire du Terraform
ou du Terraground, on peut très vite arriver dans un mur et commencer à automatiser des choses qui ne marchent pas.
C'est une perte de temps.
Oui, ça, c'est quelque chose que je vais dire vraiment très souvent pour le coup,
pour ceux qui me connaissent, on ne automatise pas quelque chose qui ne marche pas.
C'est vrai que c'est une, malheureusement, une...
on s'appelle. Une mauvaise habitude qu'on peut avoir en se disant, on part directement dans le Dev,
dans le Dev ou dans l'application avec Terraform en disant, bon, c'est plus simple de partir avec ça.
Et c'est vrai que ça peut être souvent le problème que j'ai vu dans des projets dedans.
Bon alors, on va imaginer là dans le projet que tout est bien, tout est beau et que tout fonctionne tel qu'on l'a évolué.
C'est-à-dire, on a trouvé l'architecture qu'on voulait, on a trouvé les composants qu'on voulait, on les a bien mis en place.
Voilà, ce n'est pas toujours la chose qu'on atteint centanément, mais voilà, on va dire qu'on a atteint ça.
On a fait notre structure AsCode. Alors là, tiens, je vais mettre encore un petit bémol par rapport à Terraform.
Alors, je n'étais pas forcément un très très grand fan de Terraform avant, je ne connaissais même pas trop.
Bon, là après quelques mois d'en avoir bouffé, par partout, clairement...
Enfin, je ne sais pas de toi quel est ton ressenti par rapport à quelqu'un qui a l'habitude de faire du code.
Et donc là, on a fait ça infrastructure AsCode, est-ce que tu y mettrais vraiment cette définition-là ?
Oui, mais en gardant bien l'esprit que ça reste d'abord l'infrastructure.
Ce n'est pas du code. On ne va pas avoir des if dans tous les sens, des boucles dans tous les sens,
et du conditionnel. Une infrastructure qui est déployée, ça ne bouge pas.
Et donc dans la façon dont on écrit le code, ça doit se ressentir et il faut que ce soit lisible.
On ne va pas commencer à faire des conteneurs, des injecteurs, des trucs hyper compliqués qu'on ferait en code avec des interfaces,
parce qu'en code, on veut que ce soit flexible, évolutif, blablabla.
Là, on déclare une infrastructure, donc il faut que ce soit lisible, simple,
et il ne faut pas que ça devienne compliqué avec des développeurs qui voudraient faire du code avec.
C'est ça un peu l'un des problèmes qu'on a rencontré dans notre usage de Terraforme,
en tout cas dans notre façon dont on a récupéré un peu tout ça, c'est que quand on entend code, on entend donc développeur.
Notamment, nous, les gens qui... enfin, l'équipe qui fait le Terraforme est considérée comme l'équipe de développement.
C'est son nom attribué dedans.
Et c'est vrai que les compétences qui avaient été mises en place sur cette partie-là étaient des compétences de développement.
Donc avec une modularité extrêmement forte de tous les composants Terraformes,
qui devaient amener de la simplicité, ce qu'on voit normalement dans le développement,
on a vissé un peu ça ce que tu disais Arnaud, dans le sens où on va faire des librairies, on va faire des choses comme ça, etc.
Dans le cadre d'un passe...
Voilà, faire en sorte que ce soit réutilisable, voilà, des choses comme ça en permanence.
Quand on est dans l'infrastructure AsCode, c'est vrai que d'un seul coup, ça peut être compliqué.
C'est-à-dire que le fait que ce soit peu vis... bah, rend des problèmes.
Et c'est un point que tu as dit, c'est le fait que l'infrastructure on n'y touche pas.
C'est-à-dire que si jamais demain, on se met à faire un refacto total d'un code Terraforme,
et bien, ok, il peut être plus joli, plus lisible, plus quoi que ce soit,
mais si ça demande à restarter entièrement toute l'infra,
et bien, ce n'est pas le but voulu alors que, dans le cadre d'une application,
si jamais on met les mêmes API, bon, bah, si tout le code change derrière et qu'il n'y a vraiment rien qui reste,
ce n'est pas forcément très problématique.
Et c'est vrai que ça, c'est une différence fondamentale entre les différents types de codes, on va dire.
Si jamais on dit que c'est du code.
Voilà, je vais un peu... on fonce le clou par exemple.
En développement, on utilise beaucoup des outils d'Anails de Code type SonarCube,
qui vont regarder notamment la duplication de code.
Et c'est un indicateur qu'il faut essayer de baisser.
Bon, bah là, en Terraforme, la duplication de code, c'est pas forcément un problème.
Vous l'aurez directement déclaré un module parce qu'on déclare deux fois la même ressource à deux endroits.
Bah, c'est vraiment overkill.
Pour moi, les modules c'est bien, mais c'est un outil comme un autre,
il ne faut pas en abuser, ça doit arriver quand on va par exemple déployer une centaine de VM.
Mais, dupliquer même une dizaine de fois un même composant à différents endroits,
parce qu'on gagne en lisibilité, parce que tous les composants,
j'irais, tous les sous composants d'un même gros composant sont même en droit.
C'est bien.
S'il faut aller tout le temps à gauche, à droite, chercher des modules
qui pourraient en plus être dans des ripos séparés,
on amène beaucoup de complexité dans un projet qui n'en veut pas.
C'est ça.
Alors, pour toute cette introduction, alors qu'on voulait parler à la base des tests de platform,
c'est qu'en fait, on ne teste que les choses qu'on veut atteindre.
C'est-à-dire que ça n'a pas la même chose de tester.
On ne testerait pas, là par exemple, tu as parlé à la duplication,
donc en fait, on pourrait très bien avoir des tests d'analyse syntaxique du code, etc.
qui seraient comme but justement de réduire cette duplication
et donc forcément, les actions qu'on mettraient en face iraient dans ce sens-là.
Nous, à l'heure actuelle, donc dans les tests qu'on met, il y a des tests basiques,
c'est juste des tests de validation des fichiers terraformes,
donc de l'infrasturasse code, enfin du code déployé.
Alors, toujours du mal à appeler ça code.
T'as dit à l'heure déclarativité,
oui, il ne faut pas oublier qu'on ne peut pas faire,
ce n'est pas une complète terraforme.
Le code fait ne nous permettra pas,
on ne pourra pas faire une interface graphique avec du code terraforme.
C'est une déclaration d'un format d'architecture,
ce n'est que ça, en étant beaucoup, c'est déjà ça,
mais c'est pour ça qu'on limite beaucoup.
Nous, on va mettre des tests d'analyse syntaxique dans le test d'analyse syntaxique.
Les tests ensuite qu'on a mis en place,
on les a mis en place suite au problème qu'on a eu, en fait.
C'est-à-dire que...
Alors, je n'ai pas de stats sur le code qu'on a,
mais comment ça devient conséquent, on va dire.
Les principaux problèmes qu'on a eu, c'est pas des problèmes de code.
C'est-à-dire que ce n'est pas des problèmes de décriture du code,
de quoi que ce soit.
On a plutôt eu des problèmes d'intégration du code.
Là où, quand on fait du développement Python, PHP, etc.,
on peut avoir des problèmes de abamallibrerie,
il lui manque tel méthode, il va y avoir tel autre problème, etc.
et c'est des choses qu'on veut tester avec des tests unitaires.
Nous, en tout cas, on a décidé de gérer les problèmes qu'on avait le plus.
Et les problèmes qu'on avait le plus, en tout cas, tu me dis si j'ai tort Arnaud,
c'était surtout des problèmes d'intégration, des problèmes de...
Je n'ai pas telle règle, tel autre.
En fait, le problème quand on fait de l'infrastructure AsCode,
c'est qu'on va appeler des composants qui vont marcher.
C'est-à-dire que si jamais, dans de la WS,
vous décidez d'installer un load balancer, d'installer une VM à côté,
mais que les deux vont fonctionner et vous allez avoir une VM et un load balancer.
Mais si le load balancer n'a pas été configuré pour aller pointer vers cette VM-là,
mais a été configuré pour pointer ailleurs,
votre code est juste, votre code est valide,
le résultat de sortie de Terraform sera parfaitement OK.
Mais à la fin, vous n'aurez pas le résultat attendu.
C'est ça.
Mais en fait, du coup, on va plutôt parler directement de tests d'intégration
voire de tests end-to-end que de tests unitaires en Terraform.
Ce n'aurait pas de sens.
On ne va pas tester unitèrement qu'on arrive à déployer un load balancer, comme tu l'as dit.
Exactement.
Donc, c'est ça, en fait, la différence que je fais.
C'est pour ça qu'on a du code, mais on ne va pas appliquer les mêmes méthodes.
Des tests unitaires, ça peut être bien.
Ça peut.
Dans certains cas précis où il va y avoir un intérêt à ça,
quel on peut discuter, c'est juste que nous, dans notre expérience,
qui est limitée à un usage,
on n'avait pas du tout ce besoin-là.
En tout cas, on ne l'a pas ressenti à ce moment.
Un test unitaire, ça pourrait être si on fait des librairies partagées,
de modules, par exemple.
Peut-être que là, ça aurait du sens de dire,
en fonction de tel ou tel ou tel paramètre,
des variables un peu extrêmes, j'arrive à me déployer ou pas.
Mais c'est vrai que nous, on met vraiment l'accent sur des tests end-to-end.
Donc, on va déployer plusieurs composants et voir effectivement
s'ils arrivent bien à un certain agréance ensemble.
Ça, on l'a automatisé parce que là, le déploiement,
il met une vingtaine de minutes,
on a plusieurs centaines de composants qui se déploient.
Et faire des tests à la main, ça prenait quasiment une journée.
Voilà.
Et donc, comme ça prenait du temps, on ne les faisait pas forcément.
Est-ce qu'il faisait qu'on avait un rendu de notre code qui n'était pas parfait ?
C'est-à-dire qu'en fait, on avait beaucoup de petits problèmes à gauche et à droite
qui se baladaient.
Donc, souvent, à cause d'un effet snowflake,
l'effet fleucomne-neige dont on parle,
dont on parle assez souvent ici sur DevOps,
ce qui était que,
entre deux environnements,
l'environnement de pré-prod et l'environnement de prod,
ils se ressemblent beaucoup, mais ils ne sont pas exactement identiques.
Parce que ce n'est pas les mêmes personnes qui les ont déployés,
parce qu'on n'est pas passés par les mêmes phases,
on n'a pas forcément les mêmes limitations, etc.
Ce qui faisait qu'on avait un rendu de qualitatif,
en tout cas, qui n'était pas suffisant pour nous.
Oui, en effet, on retrouvait un peu les mêmes problèmes
qu'on va retrouver dans du développement classique.
C'est que, comme on n'a pas de test, on est frileux,
on n'a pas confiance dans notre code,
on n'a pas besoin de faire des changements de peur de casser quelque chose.
Et grâce au test end-to-end,
même si c'est de l'infrastructure,
on a maintenant cette confiance dans notre code.
Voilà.
Sur les parties qu'on teste, comme toujours, quand on teste des tests.
Bien sûr.
Des tests.
Donc là, on va vous parler de l'expérience qu'on a eue.
Donc là, toi, tu as utilisé quoi ?
Quels ont été les réflexions que tu as eues pour te dire
comment je vais mettre en place ces tests ?
Quels ont été un peu les étapes par le cas de l'Eurent ?
D'abord, pour reprendre tout l'histoire,
on a commencé juste avec gutterraformes.
Au début, on déployait des briques, les unes à la suite des autres.
Et puis, petit à petit, on a eu vraiment trop de briques.
Donc là, on a fait un peu comme des légos, je dirais.
On a eu les briques d'un côté.
Donc ça, c'est la partie terraformes.
Et au-dessus, on a mis les plans,
comme des plans de légo, en terragrunt.
Donc on va avoir la configuration qui vient là-dessus.
Et ensuite, comme on l'a dit...
Terragrunt, si tu peux résumer Terragrunt,
pour ceux qui ne connaissent pas.
Terragrunt, c'est vraiment l'organisation de briques,
de composants terraformes,
et qui va ordonner et lier des composants terraformes les uns aux autres.
Vraiment, je continue sur ma comparaison avec des légos.
Il faut voir les briques terraformes comme des briques de légo.
Elles peuvent s'agencer de différentes manières.
Elles sont indépendantes les unes des autres.
Et Terragrunt va venir par-dessus ces briques en disant
« Tels briques doivent s'accrocher avec tels autres briques,
et au-dessus, on va mettre celle-là, celle-là, celle-là.
Et à la fin, j'ai un super château fort en légo ».
C'est vraiment Terragrunt qui fait...
C'est un peu le chef d'orchestre.
Oui, il y a une question d'orchestration,
puisqu'on a une gestion de dépendance entre les briques,
de passage d'information, etc.
Ça permet de ne pas avoir tout le code au sein...
Enfin, tout votre architecture au sein d'un même dossier.
Voilà, en fait, on va avoir Terraformes d'un côté
qui fait des composants,
qu'on va essayer de rendre de notre côté plus fonctionnel.
Par exemple, je ne sais pas,
déclaration d'un client et d'un autre côté,
déclaration d'un server.
Et comment est fait le lien entre les deux ?
Comment les deux vont se discuter ?
C'est Terragrunt qui peut venir par-dessus en disant
« D'abord, je vais mettre le server ».
Et puis, pour déplacer le client, je vais dire
« À l'IP du server, c'est ci ou c'est ça ».
C'est un exemple parmi beaucoup.
Donc voilà, on arrive avec
notre Terragrunt maintenant.
Et comme on l'a dit, le problème,
c'est qu'il y a beaucoup de composants
et que le moindre changement
peut impliquer des erreurs
et on n'était pas confiant.
Donc, il nous fallait des tests.
Et donc là, on a utilisé une librairie de tests en go,
qui s'appelle TerraTest.
Et avec ça, on peut déployer toute notre infrastructure
et faire n'importe quelle execution qu'on veut
sur nos composants grâce aux libres érigaux.
Et donc comme ça, par exemple, on va simuler
un envoi de fichiers,
on va simuler un dépôt dans un storage account.
On peut vraiment faire ce qu'on veut.
Et ainsi, on arrive à tester
l'intégration de tous nos composants
et dire si on est confiant
ou pas dans notre code.
Donc, on va parler d'abord de l'usage.
C'est que là, l'heure actuelle,
ce test commence à se s'activer.
Si jamais je veux juste lancer un test,
comment ça se matérialise ?
Alors, d'abord, je vais piocher
dans mes briques Terraform
et créer ma configuration TerraGround
à partir de ces briques.
Et donc comme ça.
Et ensuite, une fois que j'ai cette configuration
TerraGround,
tout simplement, avec ma librairie TerraTest,
je vais pouvoir dire,
déploie cette configuration-là de test.
D'accord. Donc, là, moi, ce que je fais,
c'est que je fais go, build quelque chose.
Je fais...
Bah go test.
Il faut vraiment voir ça comme des tests.
Je pense que beaucoup n'ont pas forcément fait
de tests unitaires.
J'essaierais de me faire comme disant.
Tout le monde n'a pas forcément fait de tests unitaires en go.
Donc là, nous, on est parti en go.
Donc, comme pour des tests en go langues normaux,
on va faire un go run test.
Et...
Bah du coup, tous les tests, on s'exécuter.
Et donc là, dans mon test,
avec la librairie TerraTest,
je vais dire TerraGround Apply All.
Ça va me déployer toute mon infrastructure.
Ça, ça va être la première étape.
La deuxième étape qu'on va appeler validation,
ça va être, bah, à partir des output de mon TerraGround,
je vais récupérer une adresse IP,
une URL de blob.
Et je vais pouvoir me connecter.
Je vais pouvoir déployer un blob.
Je vais pouvoir envoyer un fichier.
Et je vais voir si le composant en face,
une VM par exemple,
arrive à recevoir l'information.
D'accord.
Donc là, en fait, tous ces tests-là sont écrit en go.
En fait, l'avantage que tu as vu,
enfin, ou pas d'ailleurs,
par rapport à tout ça,
je ne sais pas s'il t'aurait pu les voir autrement.
Euh...
Non, moi, je...
Là, comme ça,
non, moi, ça me plaît bien.
Les librairies sont très complètes.
Elles marchent bien.
On peut, avec cette librairie TerraTest,
on peut juste faire des tests en Terraforme
si on le souhaite.
Donc, avec une même librairie,
on peut faire les tests Terraformes TerraTest,
comme on veut, c'est très flexible.
Il y a tous les outils qu'il faut.
Tout ce qu'on a,
qu'on fait à la main, je dirais,
avec les petites commandes TerraGroundTaply, etc.
TerraGroundDestroy,
on peut les faire avec cette librairie.
Ensuite,
qu'on soit sur Amazon, sur Azure,
ou sur autre chose, il y a toujours des librairies
en go qui permettent de se connecter
aux composants.
Donc, c'est très facile
de faire tous les tests
de bout en bout.
Voilà. Donc, en gros, là,
si on résume l'avantage, là,
du go,
en tout cas, là, de cette librairie test,
c'est que d'un côté, donc, on appelle le code
comme d'habitude, puisque c'est ce qu'on veut tester,
et qu'après, l'avantage, c'est que dans la phase de validation,
tu peux tout coder avec les librairies
quelconque en code,
c'est-à-dire récupérer un tel blob,
regarde le contenu,
regarde s'il y a bien tel...
Je ne sais pas, tu peux faire des regegs,
regarder s'il y a un contenu de fichier.
Exactement. Là, c'est vraiment, je dirais,
en fonction de l'usage
et des composants qu'on en a, mais effectivement,
dans la phase de validation,
on peut faire absolument ce qu'on veut.
C'est...
D'accord. Et peut-être, d'ailleurs,
l'avantage qu'on a entre les deux, c'est que, comme on ne écrit pas
dans le même langage que ce qui a permis de déployer,
potentiellement, ce qui est déployé
peut changer du tout au tout,
sans avoir besoin de changer les tests,
puisque les tests sont vraiment indépendants,
et voire même sont écrit dans un autre langage,
donc, permettre de vraiment bien valider.
Parce que souvent, quand on écrit dans le même langage
que ce qu'on a fait, potentiellement, on va tomber
dans le même bug et donc pas le voir, en fait.
Là, l'avantage, c'est que vous avez vraiment
d'un côté le terraform, donc vos
HCL
qui décrivent votre infrastructure
et de l'autre côté les tests concrètement.
Quel est le client, quel est le formalisme
du client, qu'est-ce qu'il va devoir faire,
que ce soit une API écrite en Go, ou même
n'importe quoi un appel, ou un fichier,
ou un rendu.
Toi, ton expérience par rapport à Go,
avant d'avoir commencé à faire ça, c'était laquelle,
parce qu'on a dit avant, on faisait du terraform.
Donc, on peut faire du Go,
on peut faire des providers, des choses comme ça,
terraform et écrit en Go, mais quelqu'un
qui fait du terraform ne touche pas forcément à ça.
Toi, ton expérience avant de commencer à faire ces tests,
c'était
de l'expérience en Go.
Moi, j'en avais déjà fait du Go un petit peu
à la chez Talaise, quand on était ensemble,
justement.
On dirait pas que c'est de ma faute,
que tu es fait du Go.
Non, pas du tout.
Ce qui est sympa avec le Go,
c'est que
ça marche tout de suite, c'est bête à dire,
mais on n'a pas besoin d'installer
des frémoires et des packages dans tous les sens.
Pareil, si on veut le déployer,
et pourquoi pas exécuter les tests
sur la runner une fois par jour.
Ma machine, j'ai rien besoin d'installer dessus,
donc c'est hyper précieux.
Ensuite, les librairies, comme on l'a dit,
sont hyper bien faites.
J'ai pas besoin de
déclarer plein de classes
ou plein de structures compliquées
pour pouvoir commencer à vraiment
rentrer dans mes tests.
Tout est là,
et voilà, c'est un langage
très concis et très efficace.
D'accord. Et l'expérience par rapport
aux autres librairies de tests que tu as pu
utiliser par le passé, puisque là, en fait,
on utilise vraiment une librairie de tests,
ça va être quoi, justement, même ton ressenti ?
Comment toi tu vois là ton expérience avec
ces tests d'infrastructure ?
Est-ce que tu avais déjà eu l'habitude
d'en faire dans d'autres projets ?
Est-ce que tu les avais inclus
ou pas dans différents de tes projets ?
Non, c'est vraiment le premier projet
sur lequel on a vraiment senti la nécessité
d'avoir des tests d'infrastructure.
Auparavant, quand on faisait des tests,
c'était vraiment des tests de code.
Ça pouvait être des tests N2N,
mais c'était toujours aussi bien du front
que du back, jamais de l'infrastructure.
Mais sinon, écrire des tests d'infrastructure
c'est vraiment comme écrire des tests
unitaire dans un peu de quel
être langage au final, c'est très simple.
Après, il faut bien comprendre
que étant de l'infrastructure,
ces tests peuvent être extrêmement longs.
C'est pour ça qu'on va pas forcément
les exécuter tout le temps, mais...
Voilà, c'est ça. Est-ce que tu les as mis en post-committe ?
Enfin, en pré-committe, avec l'huit ?
Ah non, là, si on faisait ça,
je pense qu'on aurait une mutinerie
des développeurs, puisque ça voudrait dire
quasiment une heure de test
avant de pouvoir faire un comit.
D'accord. Donc justement, c'est quoi la politique
que tu penses être la meilleure, justement, pour ça ?
Donc là, test d'une heure, c'est ça,
pour ça. Est-ce que ça peut être
baissé ? Ou pas ?
Est-ce que ça peut être parallélisé ?
Est-ce que tu penses le mettre
dans les PR, dans les moments d'une PR ?
Quelle serait le meilleur usage à ton avis,
l'un de dans,
faut que je me toque les besoins aussi ?
Déjà, on peut...
Dans notre cas, je vais parler de notre cas,
ça peut difficilement être baissé, voire optimisé,
terraforme esquilé.
Il faut...
Si un composant qui met 3,5 heures à être déployé,
on pourra pas faire de la magie en code
pour réduire ça.
Ce qui est vraiment le plus long chez nous,
c'est l'apply, et puis le destroy.
Les tests de validation, eux, sont assez rapides.
Donc vu que c'est très long et qu'on ne peut pas y faire grand-chose,
pour moi, je n'en appellerai d'abord
à la responsabilité des développeurs,
s'ils pensent avoir fait des changements importants
qui peuvent amener des régressions,
de les jouer manuellement, de prendre le temps,
sachant que ces tests qu'on peut laisser tourner à côté,
on peut faire autre chose pendant ce temps.
Et puis, pourquoi pas, pour bien faire les choses,
avoir des runners de pipeline
qui puissent exécuter ces tests une fois par jour.
D'accord.
Donc là, c'est plutôt ça.
Donc on voit bien que ce n'est pas exactement les mêmes tests
qu'on va faire avec des tests unitaires classiques de développeurs.
C'est vraiment ce qu'on a commencé à dire.
Effectivement, ce n'est pas des tests unitaires,
puisque un test unitaire, la définition,
c'est que ça s'exécutait hyper rapidement.
Là, nous, on est...
Tous nos tests se font sur une plateforme distante.
Donc si la plateforme ne répond pas,
ou je ne sais pas quoi,
il peut y avoir mille raisons pour lesquelles
les tests ne marchent pas.
Ce n'est pas forcément reproductible.
Et moi, j'ai simulé vraiment ça plutôt
à des tests end-to-end,
qu'à des tests unitaires.
D'accord.
Oui, c'est globalement ce qu'on voit la plupart du temps
dans ce genre de tests.
Est-ce que tu avais vu...
Là, j'avoue que j'ai plus trop de souvenirs,
mais est-ce qu'on avait vu d'autres solutions
possibles à utiliser que tera-test ?
Donc on rappelle tera-test,
c'est donc une librairie en go,
mais dédiée à terraformes,
qui permet de simplifier le lancement des tests,
enfin, le lancement de l'installation terraformes,
de pouvoir récupérer les valeurs
pour après pouvoir les utiliser
dans d'autres librairies go,
ensuite dans le reste des tests.
Et je crois d'ailleurs qu'elle ramène
quelques facilités,
quelques sucres syntaxiques
pour Azure, AWS, etc.
Mais est-ce qu'il y avait d'autres solutions possibles
que tu aurais pu voir
ou tu aurais entendu parler dessus ?
Alors moi, je n'en connais pas d'autres, non.
Je pense qu'il doit forcément exister
l'équivalent dans d'autres langages,
mais pour Djugo, c'est vraiment un bon outil.
Ok.
Bon, de toute façon, ça a répondu...
Est-ce que justement, le résultat,
est-ce que le résultat répond aux attentes ?
C'était ça un peu le...
...le chose...
...le test à l'air ?
Ah oui, oui, oui, oui.
Justement, vu que les librairies
qu'on utilise derrière sont très complètes,
nous, tous les tests qu'on a voulu coder,
pour l'instant, on n'a plus les faire.
On n'a aucune limitation
dans ce qu'on peut faire jusqu'à aujourd'hui.
Et quel a été le résultat
de la mise en place des tests ?
Bah, le résultat, c'est que...
Je sais que ça a été progressif,
parce que ça a été...
Quelles aient qualité le résultat ?
Enfin...
Je pense que vraiment,
ce qui nous a beaucoup aidé
pour arriver vers les tests,
c'est d'abord d'installer TerraGround,
puisque ça nous a permis d'avoir
justement plusieurs environnements,
d'éclairer plusieurs configurations,
que ce soit en dev, en test, en prod,
ce qu'on veut.
Et du coup, à partir de cette facilité
qu'offrait TerraGround,
faire des tests, c'est devenu très facile.
Le résultat, bah...
C'est comme n'importe quel test,
c'est vraiment la confiance dans le code,
et...
Et on est moins frileux à faire des changements
qui peuvent être très impactants,
puisqu'on sait que derrière,
on va pouvoir les tester efficacement.
Avant, moi, plusieurs jours,
plusieurs fois, j'ai fait des tests
en entier à la main, et...
Et c'est là que vraiment, on a craqué.
On s'est dit que c'était plus possible.
D'accord. Et tu as pu voir des problèmes.
Est-ce que ce qu'il y a eu un résultat
immédiat sur ces tests-là ?
Ah oui, oui, bah...
Le jour où j'ai mis en place,
oui, il y a eu beaucoup de choses de corriger.
Oui, oui, il y avait pas mal de choses
qui avaient été faites
sans être testées, parce que justement,
c'était des tests qui étaient vraiment trop longs
et pénibles à faire à la main,
et immédiatement,
la joue de ces tests a pu corriger
un grand nombre de choses qui avaient été
mises un peu sous le tapis, parce que...
parce qu'il y a un peu de la flême, et que c'était trop long.
D'accord.
Donc là, on est dans le cadre d'une grosse infrastructure
mise en place.
Dans le cadre d'une plus petite,
genre je sais pas si jamais vraiment,
j'ai qu'un site web, une base de données
mis sur de la WS avec un load balancer
dedans, devant intérêt
ou pas à mettre en place ?
Il te dépend.
Si c'est amené
à évoluer, à changer dans le temps,
si c'est un développement qui s'annonce
long, oui.
Si c'est une infrastructure
qu'on sait que voilà, j'ai un load balancer,
un site et ça va jamais bouger.
Bon, c'est peut-être un peu overkill.
Voilà, c'est comme tous les outils.
Il faut, quand on a un problème,
utiliser le bon outil.
Là, clairement, comme on l'a expliqué plusieurs fois,
passer des journées entières
à tester, c'était pas possible.
C'est pour ça qu'on a amené les tests.
Et pour le coup,
une question aussi que j'avais,
on a parlé tout à l'heure de l'EFES Snowflake.
Est-ce que tu penses que
ces tests-là pourraient
aider à cet EFES Snowflake ?
Alors, appelle-moi le EFES Snowflake.
Le EFES Snowflake, c'est de se dire
que tu peux avoir une déviation entre deux infrastructures.
Un exemple que je donne souvent.
Donc, tu déploies ton infrastructure
à un instant T, on va dire,
deux environnements
exactement avec le même code.
T'as un Teraform, tu le play,
ça apply, on va dire,
en imaginant des deux côtés pareilles.
Mais sur ton infrastructure de
Dev, tu fais passer
tous les changements au fur et à mesure.
À chaque comite, tu les apply.
Tu les apply, tu les apply. Alors que sur ta prod,
tu ne play que une fois tous les 10 comites.
En imaginant comme ça.
Est-ce que tu arrives au même résultat, en fait,
souvent dans les infrastructures,
entre appliquer à tous les comites
et appliquer une fois tous les 10 comites,
bah tu n'arrives pas à la même résultat. Alors même que tu es au même code,
parce que potentiellement, tu as laissé
il y a des restes dans ta plateforme de Dev
que tu n'as pas géré
dans ta plateforme de prod.
Un exemple que tu peux avoir, c'est je ne sais pas,
tu te mets dans un comite de développement
à rajouter un Load balancer.
Tu le rajoutes mais
deux comites plus loin, tu l'enlèves.
Voilà. Parce que pour plein de raisons,
tu as fait un refacto, tu n'en es pas aperçu,
tu as enlevé le Load balancer. Mais lui, il est toujours là.
Même si tu l'as enlevé de ton code Teraform,
bah il est là.
Et en fait, quand tu te mets à déployer
en production, bah en fait,
ça ne le déploie pas le Load balancer. Et donc, tu as un problème.
Alors, quand le développement, ça marchait
parce que tu avais le Load balancer,
en prod, tu ne l'as pas. Et tu peux avoir
l'effet inverse qui est que là,
toi, dans tes tests, tu construis en fait
une infrastructure depuis zéro
qui arrive à converger
là où peut-être, si jamais, il y avait
déjà eu une infrastructure avant,
elle n'aurait pas convergé.
Pour l'exemple que tu donnes avec le Load balancer,
ça devrait pas arriver. Parce que s'il a été
mis dans Teraform, ça veut dire qu'il a
arrivé dans un TF State, ça veut dire
que le jour où tu supprimes de ton code,
Teraform va voir qu'il doit le supprimer.
Donc, normalement,
si c'est fait correctement, tu devrais pas avoir
ce problème. Le problème que tu décris peut arriver
si... Alors, correctement,
là, on peut le dire,
si jamais, par exemple, on utilise des ressources,
des externales ressources, non, je ne sais plus comment s'appelle,
c'est des... Oui,
enfin, en fait, ce qui, déjà,
la première type de ressources qui peut venir
poser problème, c'est les ressources qui sont
en dehors du Teraform qui sont faites à la main.
Si en prod, par exemple, il y a eu des choses faites
à la main et qu'on vient avec... Par exemple,
si le Load balancer a été déployé à la main en prod,
parce qu'on en avait besoin tout de suite et qu'après, on amène le code
Teraform, oui, là, ça va planter,
il va nous dire, bah, mon truc existe déjà.
Donc ça, ça peut être
un premier cas. Mais
pour moi, le cas le plus dangereux
que tu décris, enfin, la cause
plutôt la plus probable de divergence,
viendrait de la façon dont on écrit le code
en lui-même. C'est-à-dire que si
justement on a la
gérée, la mauvaise idée
ou la contrainte de faire
du code conditionnel
en fonction des environnements,
c'est là que va arriver
les plus grosses divergences. Par exemple, on va dire
ah, bah moi, en Dev, je vais avoir besoin
de tels et tels composants, mais je sais qu'en prod,
ils en seront pas. Donc si je suis
en Dev, je vais les déployer
et si je suis en prod, je vais pas les faire.
Et ça, clairement,
là, directement en code, on écrit
une différence entre les deux
environnements. C'est ça qu'il faut arriver
à limiter.
On en revient un peu au premier point
qu'on disait en introduction, c'est
il faut pas, il faut un minimum de conditionnel
voire pas du tout, et il faut que l'infrastructure
soit la plus simple possible.
La plus déclarative, la plus
visible. La plus déclarative et la plus visible
et aussi la plus simple, sans conditionnel
justement pour limiter les différences qui peut y avoir
entre différents environnements liés à différentes
variables en entrée.
Comme ça, quel que soit l'environnement,
on sait à quel résultat
on doit arriver.
Et après, là,
on s'en remet,
on fait confiance au cloud provider
qui dit que les mêmes actions vont
avoir les mêmes concepts qu'ence.
Et donc, si on prend cette
hypothèse-là, quel que soit
l'état des deux plateformes, si on
applique la même
configuration
d'infrastructure, on doit arriver à la même chose à la fin.
Donc, normalement,
les Fesno Flakes, s'ils arrivent,
c'est plutôt à cause de comment le code
a été écrit
que des outils
qui sont utilisés.
Et donc, mais par contre, il peut y avoir quand même
quelque chose qui est...
ça, on l'a vu souvent, c'est qu'en fait, on a souvent
des dépendances entre des ressources
qui peuvent pas être faits dans le bon ordre.
Je sais pas un exemple
qu'on peut avoir, c'est des
sécurité sur un...
sur un réseau, par exemple.
Et bien, en fait, si jamais
on change le réseau,
il y a des sécurité dedans, on a
une dépendance, il y a un ordre
à faire des ressources, à enlever, remettre, etc.
Ça, c'est typiquement quelque chose.
Quand tu le construis depuis zéro
avec les tests d'intégration qui ont été
mis en place, tu le trouves pas.
Ça, comment tu pourrais le gérer,
comment tu verrais ça?
Je sais pas
extrêmement bien,
sûr, de voir le cas,
mais
là, je dirais
que c'est plutôt un problème de dépendance
entre certains modules.
Donc, peut-être que
c'est encore une fois plus un problème de code
et de déclaration des composants.
Ça peut arriver qu'il faille
à spécifier
à Terraform, que des
Depends On à la main, je dirais.
Voilà, mais justement comment ça... Parce que ça,
tu dis qu'il faut bien les mettre, je suis d'accord.
Est-ce que
tes tests
verraient ce genre de problèmes?
Est-ce que tes tests arriveraient à voir
le fait qu'ils manquent des Depends On
dans des deletes?
Oui, oui, ça,
typiquement, nous jusqu'à maintenant,
à chaque fois qu'on faisait un play,
on faisait pas trop le destroy derrière,
puisqu'on en avait pas besoin.
Et là, les tests, justement, ils disent,
si je veux arriver jusqu'au bout
et que je n'ai pas eu d'erreur, je vais faire mon destroy.
Là, typiquement, les tests ont vu
que l'ordre
des destroy n'était pas bon.
Typiquement,
un exemple bête,
c'était un cluster
AKS. Le cluster
AKS, une fois qu'il est déployé, on lui dit,
ton load balancer, tu vas le mettre dans un autre subnet
que le tiens. Mais ça,
Terraform, il le sait pas. Donc,
lui, il commençait avant de supprimer
les clusters, il essayait de supprimer le
subnet du load balancer. Et là,
le destroy plantait parce qu'il disait,
le subnet s'est utilisé, je ne peux pas supprimer.
Et donc là,
par exemple, ça a montré qu'il fallait
rajouter un deep-end zone du cluster
vers le subnet load balancer.
Ce qui est en plus plutôt bon
et plutôt juste parce que de toute façon,
si le subnet n'existait pas, rien qu'au disait,
à la play, ça ne marcherait pas.
Donc, effectivement, les tests,
ils permettent de voir énormément de choses.
D'accord. Donc, de faire dans un sens,
ça permet de voir des choses.
Le faire dans l'autre sens, ça permet de voir
encore d'autres choses. C'est ça, globalement ?
Oui. En fait, oui.
Il ne faut pas négliger la partie destroyer,
je dirais. C'est vraiment
aussi important que la partie apply.
Ça permet justement de voir que
les choses sont vraiment
créées dans le bon ordre. Et que
ce n'est pas juste un peu par chance ou par magie
que lors de la play, tout marche.
Parce que là, c'était un peu notre cas.
En fait, on avait de la chance.
Le cluster, il mettait du temps
arrivé et du coup, entre temps,
le subnet du load balancer
était arrivé.

c'était par chance.
Il n'y avait aucun endroit.
On avait donné la dépendance
entre cluster et
son subnet de load balancer.
D'accord. Donc, en défaite, on voit des choses.
Est-ce que quelque chose d'autre qui
pourrait être fait,
et là, pour le coup, c'est vraiment
de la perspective, c'est quelque chose d'un peu plus compliqué,
ce serait
de déployer l'infra
à une version T.
Et après, de faire un apply à la version
T plus un, celle qui est en train d'être essayée.
Est-ce qu'on ne pourrait pas avoir ce genre de choses là ? C'est par exemple de se dire
si jamais on a... on sait
à quel moment la production a été
déployée.
De se dire, première étape, je déploie
en l'état normalement la plateforme
de prod.
Deuxième étape, je play la version
actuelle du code. La version,
quand on n'est pas bien sûr dans du continuous
delivery. Est-ce qu'il pourrait pas y avoir
une version en deux passes
pour voir est-ce que ça marche ? Est-ce que ce serait utile
ou pas ?
Appliquer la version de la prod,
appliquer les changements
en cours par rapport à la version de la prod.
Faire ça en deux fois, en fait. Deux terraformes play.
De toute façon,
terraformes, ils se basent sur un
state, donc, il va toujours
savoir faire le diff
entre ce qu'il a actuellement et
les nouveautés.
Tu es spère.
Est-ce que je sais... C'est une question,
c'est... est-ce que ça
pourrait être utile ou pas ?
Est-ce que ça régleraient des problèmes ? Après,
c'est peut-être des soucis qui n'ont pas été rencontrés
et donc, qu'il n'y a pas forcément besoin de tester.
Non, nous jusqu'à maintenant,
on n'a pas eu de... ce genre
de problème.
Je dirais que Terraform a toujours bien fait son
boulot avec cet F-State, donc...
Sur ça, on est plutôt bon.
Ok. Non, mais c'est pas...
pas de problème, c'est pas...
pas forcément de besoin de faire plus que ce
qu'il y a nécessaire.
Oui, comme tu dis, de toute façon,
on prend les problèmes quand ils arrivent.
Donc, si on a le cas, effectivement,
il faudra qu'on y réfléchisse à une solution.
Ok, cool.
Je sais pas si on a... si tu as quelque chose
d'autre à voir, là, on a déjà fait
un bon récapitulatif
de...
de ce sujet, des tests
d'infrastructure à la SCODE,
très très très orienté
Terraform, pour le coup.
Je sais pas si y a d'autres choses
que... de ton expérience
que tu as vu et qui... qu'on n'a pas eu
le temps de partager, là.
Non, on a déjà fait le tour
de tout, mais je vais me répéter.
Je dirais que le...
dans mon parcours, le plus gros changement
entre le passage du dev
à une partie plutôt ops et infras,
c'est vraiment le mindset
de dire qu'en... qu'en
infrastructure, dupliquer du code,
être déclar... être déclaratif,
écrire des choses en dur, et ben
c'est bien. Et c'est ça
qui est assez différent du développement
pur. Il faut pas
avoir peur de... de changer
un peu ces façons de faire, puisque on change
d'outils et on... on
change de but.
Ok, voilà.
C'est vrai que c'est ça qui est très
différent. On ne touche pas aux mêmes ressources
derrière, on ne... on ne fait pas les mêmes choses.
Tout comme en...
si vous faites de l'IOT, si vous faites de l'embarquer,
vous ne coderez pas exactement de la même façon.
Vous serez beaucoup plus... frileux,
avec beaucoup plus de...
de conditions, etc. Parce que, ben,
vous ne... enfin, vous codez pas la même chose.
Si jamais vous coder un... un missile,
une navette spatiale, n'importe quoi, vous coderez pas
la même façon que votre site web,
ben là, c'est un peu pas. Vous coder de l'infra,
on ne coder pas de la même façon.
Voilà. Et donc, par exemple, pour...
pour illustrer mon propos, pourquoi je dis ça,
ben, c'est... c'est très simple. Si je déclare
une ressource et que je mets un nom
en variable, parce que, ben,
je veux que ce soit variabilisé, je fais du code,
voilà, ben, ça n'a pas de
sens, puisque de toute façon, si la valeur
de la variable change, la ressource doit être détruite
et recrée. Donc... donc,
à quoi bon mettre des variables là ou
de toute façon, faudra...
créer une nouvelle infrastructure.
C'est... c'est dommage et en plus, on perd
en lisibilité. On perd en lisibilité,
voire même en lisibilité de ce qui va
réellement être fait. C'est-à-dire que un développeur, pour votre
avion d'euro, cette variable est mal nommée.
Je la renomme. Ben, qu'est-ce
qui se passe ? On recrée entièrement toute l'infra.
Euh... et c'est peut-être ça...
Et on pète... et on pète tout. Et justement, c'était
peut-être ça, en fait, la chose que... que... que je voulais dire
tout à l'heure par le test... le test middle,
c'est-à-dire, ben, en fait, si jamais tu changes
le nom de la variable, quand tu crées et que tu détruis,
ben, ça t'a rien fait comme problème. Ça a... marché.
Alors que si tu te mets à changer de variable,
ben, là, dans ce coup, tu as eu beaucoup de changements. Et peut-être
la... la mesure
du nombre de changements que tu vas avoir
d'une release à une autre, c'est-à-dire, ok, je passe
de la... de la... je... je...
je vais mettre une nouvelle release de mon
code terraform en production, ben, de
savoir que ça va changer, tel composant,
tel composant, tel composant, tel composant.
C'est quelque chose qu'on a déjà essayé, qu'on sait
qu'il va arriver. Et on peut
mesurer presque même l'impact en
terme de temps. Oui, en effet, ben, maintenant
je comprends mieux ton... ton discours. Effectivement
le fait que chez nous, on soit
hyper déclaratif et qu'on n'hésite pas
à vraiment fixer beaucoup de choses en dur
fait qu'entre deux versions,
on sait prédire très précisément ce qui va changer
et ce qui ne devrait pas changer.
C'est vrai que... Il y a pas de variable
de changer... Il y a pas de variable de changer.
Il y a pas de chose comme ça. Il y a pas de...
il y a pas de surprise, il y a pas de code
qui passe derrière nous, faire des livres, des...
des forts, des... je sais pas quoi.
Et du coup, c'est vrai que... on est
très confiant sur... sur les changements qu'on amène
à chaque... à chaque release.
Ça, c'est vrai que ça peut être
un changement... enfin, c'est vrai que c'est une autre code
de la façon dont on a codé qui a fait qu'on a peut-être
moins besoin de tests à ce niveau-là,
au moins besoin de valider les changements d'une
release à une autre en termes d'impact. Oui.
Oui, oui, on n'a pas une variable
dont laquelle la terre entière
dépend. Oui. Oui, voilà, une variable
qui serait liée au temps, par exemple, de se dire
ben, dans une variable, je rajoute
l'heure de création, le jour de création,
un truc comme ça qui fait qu'il y ait le jour en revendipois.
Ouais, mais voilà, ça c'est quelque chose qui est tout à fait faisable,
qui serait tout à fait logique
pour certains, et qui, dans un cas, va changer
ou même juste, on a fait une typo dans un fichier.
Ben, la typo,
c'est toujours un problème, est-ce qu'on la change ou est-ce qu'on la change pas?
Sachant que la prod a été faite avec la typo.
C'est jamais tout le monde dépend
de cette typo.
C'est toujours une question, est-ce qu'on la met, est-ce qu'on la change
ou pas? Le problème, c'est que si jamais
cette typo, elle est... elle est fourrée au fin
d'une librairie d'un module tout au bout de nommage,
ben, on change la typo et on ne sait pas les impacts que ça a.
On ne sait pas concrètement
qui utilise cette librairie là
et quelles sont les ressources qui vont être changées.
Potentiellement, on peut péter entièrement toute une prod
pendant X étant,
X étant le temps de convergence,
si ça converge,
juste parce qu'on a changé une typo dans une librairie
de nommage à l'autre bout de l'infrastructure, une librairie.
Un module de nommage terraforme
à l'autre bout de l'infrastructure. Et ça, c'est quelque chose qu'on ne maîtrise pas.
Qui paraît très bien, c'est un comite extrêmement petit
qui a beaucoup d'impact.
C'est un plaidoyer pour la duplication du code
que tu es en train de faire.
Ah, mais complètement. Mais voilà, je l'explique.
Et là, potentiellement, la solution dont je parlais
est de faire une convergence en double passe,
c'est-à-dire première passe
avec la version de la prod, deuxième passe
avec la version actuelle,
peut donner des informations.
Mais là, pour le coup, encore, c'est l'humain
qui devra lire les résultats, puisque
ça veut pas dire que ça ne marchera pas.
Ça veut juste dire qu'un humain devra regarder
« ah oui, ça a mis deux heures à converger quand même ».
Parce qu'il a fallu tuer le délit
ça a mis 40 minutes
et il a fallu créer, c'était encore 40 minutes.
Oui, et puis peut-être que là,
on amène des remèdes
sur des symptômes qui devraient
être traités à un autre niveau, typiquement.
Peut-être qu'il y a un problème dans le code
ou dans la façon dont on déclare l'infrastructure
qui fait qu'on en arrive
à devoir mettre ce genre de solution.
Alors que normalement, ça doit pas arrêter.
Je suis assez d'accord
mais voilà, c'est potentiellement des choses
qu'on peut dire ceux qui vont écouter
si jamais vous avez ce problème-là.
Deux solutions, mettre des tests. Après, les tests peuvent aussi
permettre potentiellement de lever les lièvres et de dire
« regardez, on a vraiment un problème qu'on ne
connaissait pas trop ou qu'on n'avait pas trop fait attention
en mettant les tests, on les voit apparaître ».
Ce n'était pas juste la faute à pas de bol
ou la faute à
quarantaine qui avait fait un patch de stagiaire.
C'est que vraiment, notre code était pas robuste
tel qu'on pensait qu'il était en tout cas
par rapport à notre usage. Ça peut être aussi ça,
un test, comme tu l'as dit, ça lève des lièvres.
Ah oui, de toute façon,
on va parcer à l'histoire
et recéter tout le bien fait des tests.
Mais oui, ça va ça.
Mais le ne peut-être...
Il faut écrire des tests pour qu'ils permettent
de faire ça, sinon ça sert à rien.
Je reprends l'exemple que tu disais de tout à l'heure
du load balancer et du site web.
Ce que c'est très pertinent,
je ne sais pas.
Parce que vous n'avez pas la SLA qui va avec,
vous n'est-ce pas quelque chose dont vous n'avez pas forcément de SLA.
Ça va dépendre
à mon sens de l'essaleil, du nombre de fois vous déployez
ou quoi que ce soit.
Voilà, c'est ça.
Super, merci beaucoup Arnaud.
Comme d'hab, on a tenu plus longtemps que ce qu'on avait prévu
initialement
pour ce podcast.
Mais bon, tant mieux, c'est qu'on avait beaucoup de choses à dire
et beaucoup de choses à partager en tout cas.
Merci d'avoir écouté,
à tous ceux qui ont écouté.
N'hésitez pas
à nous faire vos retours
sur le Discord, sur Twitter.
Les moyens de communication ne manquent pas.
Et surtout,
venez proposer vos sujets.
Ça faisait longtemps qu'on n'avait pas fait
de podcasts sur DevOps.
Notamment parce que
je ne vais pas les faire tout seul.
Ce n'est pas mon genre de parler tout seul.
J'aime bien avoir des gens comme Arnaud
qui ont une expérience différente
qui vont parler de ce qu'ils ont pu faire,
de ce qu'ils ont pu vivre.
Je trouve ça plus intéressant en mon avis,
même pour vous, à écouter.
Donc, n'hésitez pas à me pinger
si jamais vous avez envie de parler de quelque chose.
Ça peut même être fait à deux.
Ton expérience Arnaud,
toi qui était la première fois qu'il faisait un podcast,
n'était pas
traumatisant, ça va ?
Je trouvais ça super comme format d'échange.
C'est très naturel.
Très bien.
Donc,
n'hésitez pas à venir sur le Discord
pour partager, même si vous n'avez pas envie
de participer au podcast,
partager votre expérience,
venir nous écouter en direct
sur Discord où on enregistre.
Et puis voilà, merci à tous.
Bon courage pour cette année 2021.
Et on se retrouve très vite
pour d'autres numéros de DevOps
ou d'Antoncube.
Merci à tous.
Merci beaucoup.