Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Christophe Chaudier, Christophe bonjour.
Bonjour.
Christophe, j'avais envie de parler avec toi de comment tu testes le code de déploiement.
Parce que ce que tu m'avais dit lors des préparations de cette interview,
c'est que tu considérais d'abord tu écris du code, en fait tu automatises les déploiements via du code,
et tu considérais l'infrastructure comme du code.
Du coup ça m'intéresse vachement, je me demande aussitôt,
est-ce qu'on peut faire du TDD sur du DevOps, sur de l'infra,
comment est-ce que tu testes toi aujourd'hui tes scripts de déploiement et ton code de déploiement en fait ?
Alors il y a plusieurs choses en fait, il y a le code du déploiement lui-même et le code de l'infrastructure.
On peut vraiment séparer les deux.
C'est vrai que...
C'est quoi la différence que tu fais entre les deux ?
La différence c'est...
Alors moi je travaille en infrastructure à ce code,
c'est-à-dire que je code mon infrastructure, les réseaux, les machines,
je ne utilise pas les consoles des hébergeurs, je fais vraiment du code,
et sur ces machines je peux déployer les logiciels.
Et il y a plusieurs manières de déployer ces logiciels.
Soit on fait ce qu'on appelle des images immuables de serveurs qui embarquent le code du logiciel,
soit on déploie le logiciel sur le serveur une fois qu'il est provisionné dans les data centers.
Et le code du déploiement lui-même peut être testé.
Donc moi ce que je fais souvent pour tester le code du déploiement,
d'abord je provisionne une machine virtuelle sur mon PC,
donc j'utilise le code que j'ai développé pour la machine,
et après je balance les mises à jour logiciels sur cette machine virtuelle,
et je teste mon code comme ça.
Donc soit j'écris d'abord le code de test,
et après je développe le processus de déploiement, soit l'inverse.
Et tu dis quoi, tu sais une bibliothèque particulière pour faire ça ?
Oui, alors j'utilise serveurs spec et testinfra,
qui sont deux bibliothèques, il y en a une qui est en rubis,
qui ressemble à airspec et l'autre qui est en piton.
Excellent, donc tu as vraiment tes tests qui run avec une console et tu as ton rapport de run ?
Exactement, j'ai mon rapport de run et on peut faire des tests à plusieurs niveaux,
excuse-moi, soit si on installe vraiment une machine, soit si on bosse,
comme ça m'arrive de plus en plus souvent sur des conteneurs,
là je teste, je fais des lignes sur mes Dockerfile,
et après je teste mes images Docker.
Et après tu déploie automatiquement les solutions de déploiement automatique et la boucle est bouclée ?
Exactement.
Non, désertieux, tu déploies automatiquement les solutions de déploiement ?
Les solutions de déploiement sont dans la CIA,
donc à partir du moment où les tests sont faits et qui sont verts,
la CIA s'occupe toute seule de jouer les tests de déploiement.
C'est du code qui est committé dans Guides ?
Oui, j'entends, j'entends.
Je trouve la mise en habile assez sympa,
tu auto-déploies du code qui est testé par la procédure d'autodéploiement, c'est pas mal.
Alors c'est vrai qu'en soi le code du déploiement n'est pas envoyé sur les machines,
il est vraiment juste joué sur les services de CIA,
donc il récupère le dépôt et puis il n'y a que ça à faire en fait,
pour le code du déploiement lui-même.
Parce que tu m'as dit que tu as des bibliothèques préférés toi,
que tu préfères pour programmer le déploiement automatique ?
Oui, j'utilise pratiquement que en cibles et un petit peu de shell de temps en temps,
donc vraiment je ne peux pas faire certaines choses.
Écoute, c'est vachement intéressant, c'est vrai que c'est un univers que je connais moins,
que j'estime que, enfin peut-être à tort, je suis curieux devant ton avis,
j'estime qu'il est difficile d'être vraiment expert à la fois de tout ce qui est système et développement,
et j'ai fait le choix il y a déjà un paquet d'années en début de carrière de dire
moi je vais me consacrer essentiellement au développement, mais c'est vrai qu'à une époque,
je faisais les deux, mais je trouve que le métier c'est tellement complexif,
c'est compliqué aujourd'hui de vraiment pousser l'expertise dans les deux domaines,
je ne sais pas ce que tu en penses, je suis curieux ton avis.
Je suis assez d'accord, c'est un métier à part entière développeur et DevOps,
c'est un autre métier vraiment, c'est assez compliqué parce qu'en plus on a les serveurs
à gérer, le processus de déploiement et voire même on a les réseaux virtuels parce que moi
je n'interviens que dans des hébergers de cloud, et oui, je pense qu'on ne peut pas faire les deux,
ou alors on fait les deux mais moyennement bien. En ce moment, on se pose beaucoup la question sur
justement avec l'apparition des plateformes à the service qui vont favoriser les développeurs à
déployer leurs applications dans cloud sans intervention des hops, les hops se posent beaucoup
la question de savoir si leur métier va disparaître mais en fait je pense que non,
il va juste se décaler et on va justement gérer avec les développeurs les plateformes à the service.
C'est vrai qu'une plateforme comme Eroku aujourd'hui apporte tout ça,
et justement moi je l'utilise pour ne pas avoir, pour que quelqu'un d'autre gère pour moi
toute cette intermédiation entre la stack logicielle que j'ai juste mais push à faire et que ça
soit réglé sur ce genre de choses comment tu vois le métier des hops évoluer.
Ça dépend surtout en fait de la complexité des logiciels parce que Eroku on peut lancer des
applications assez légères mais dès que les applications ont plusieurs microservices voire
des dizaines de microservices ça va devenir un peu soit très cher soit compliqué à maintenir.
Là il faut passer sur d'autres types de plateformes.
Ce que tu veux dire c'est que les applications enfin après c'est peut-être une interprétation
personnelle mais l'image que j'en ai c'est que tant qu'on restera sur des schémas d'infra
assez simples des solutions toutes clé en main peuvent arriver, et enfin sont déjà là,
tu vois. Par contre dès qu'on est sur des choses un peu pointues, un peu spécifiques,
ce qui arrive finalement assez vite dès que l'application a du succès, là on a besoin d'un
dévops en fait. Oui en effet d'ailleurs je n'interviens pas sur les projets qui naissent et les
startups qui démarrent mais plutôt sur les projets de nature qui ont besoin de passer à l'échelle.
Ouais je vois très bien. Tu vois j'ai boss sur un projet qui a un réel potentiel de percer et on
commence à se poser des questions intéressantes du genre et on fait commence si d'un coup 10.000
utilisateurs arrivent et parce qu'il y a des réelles opportunités pour faire arriver des wagons de
2.000 utilisateurs et effectivement c'est à d'un coup je me dis ok l'infra il va falloir qu'elle
évolue sérieusement quoi. Donc c'est à ce moment là qu'on appelle Christophe quoi. Exactement c'est
à ce moment là qu'on appelle Christophe. Ça marche. Bah écoute Christophe je te propose que
soit le mot de la fin je t'ai remercié d'être venu si je veux en savoir plus sur ton travail je
vais où ? Et bien il suffit d'aller sur notre site internet puisqu'on est plusieurs et il suffit d'aller
sur Lydra.fr et Lydra.fr. Christophe merci pour ta participation. Bah merci à toi de ton
invitation. Quant à toi chère auditeurs j'espère que ce podcast t'a plu je t'invite à nous rejoindre
sur artisan-développeur.fr si ce n'est pas déjà fait pour rejoindre la communauté des
développeurs passionnés et partager la passion du code. Je te dis à demain.