Dev Ops Le magazine et observatoire du Dev Ops
Bonjour à toutes et à tous et bienvenue dans un numéro spécial de Dev Ops.
Alors on est l'été, on est à la cool, on est sur la plage, on est tous partis en vacances,
Paris et déserts et on s'est dit que on pourrait faire des numéros spéciaux spécialement dédiés à
une technologie ou à une façon de faire et ça va être des numéros assez courts, assez rapides,
on espère et on appelle ça les Lightning Dev Ops et donc vous êtes au premier numéro et nous
sommes avec Romain. Bonjour, Romain fait un article il y a très récemment en fait très peu de temps
en moi deux mois. Voilà sur le déploiement et donc je vais laisser vous en parler et puis
je serai de remonder dessus pour lui poser des questions. Déjà un petit peu de contexte,
moi donc je suis indépendant, je vais voir les entreprises pour les aider à régler leurs
problèmes sur le déploiement donc ça peut être un problème sur le processus de déploiement
ou juste sur la production qui scale pas ou en fait tous les sujets qui touchent un petit peu
Dev Ops et Serreux qui sont assez mal compris aujourd'hui et j'ai justement écrit cet article
pour résoudre un point de douleur qui est assez récurrent chez moi, c'est que les entreprises
n'ont pas conscience qu'entre le travail des développeurs et l'installation en production
voire le maintien de la production, il y a un gouffre, il y a un projet, il faut investir de l'argent,
faut investir des compétences et ça aujourd'hui c'est assez mal compris, les entreprises ont du
mal à identifier ce pôle de dépense, à identifier qu'il y a besoin de faire quelque chose à cet
endroit là. Et à quoi ça serait dû à ton avis ce manque de savoir en tout cas sur cette compétence ?
Moi je pense que le principal problème c'est que Dev Ops c'est quand même assez récent,
c'est à dire que même si pour certains d'entre nous ça fait plusieurs années qu'on en entend
parler, ça fait plusieurs années qu'on s'intéresse au sujet, malgré tout dans l'industrie ça fait
moins de 10 ans que ça dure donc la plupart des entreprises le connaissent pas. Typiquement en ce
moment je suis sur une mission dans un ministère, Dev Ops c'est nouveau, l'échelle de temps d'une
entreprise aussi grosse qu'un ministère, c'est pas la même que celle d'une startup donc faire
venir des pratiques qui sont nouvelles, l'agilité que soit de manière organisationnelle ou niveau
des outils, ça prend énormément de temps. Donc là aujourd'hui moi quand je vois des gros projets
souvent on est à des années-lumière de ce qu'on peut lire dans la presse, ce qu'on peut lire sur
les déploiements de Google, d'Amazon, il y a vraiment un gouffre énorme entre ce qu'on va
trouver sur ces entreprises un peu hype et ce qu'on trouve sur la réalité du terrain donc la plupart
des entreprises qui ont des produits qui datent d'il y a plus de 10 ans.
Justement donc ça va être quoi cette différence que tu as identifié si jamais on analyse le côté
donc Blin in Edge, les Google et Amazon par rapport à ce que tu vois réellement sur le terrain.
La plupart du temps c'est surtout une mauvaise interprétation, les nouvelles pratiques. Je
dirais le cas typique du client que je vais rencontrer c'est on a mis Agil il y a deux trois
ans et finalement en creusant un peu en fait ils ont juste renommé le manager Scrum Master,
le manager dans le sous il leur nommait PO et puis les devs, ça reste des devs.
Vraiment il y a une incompréhension complète de ce que c'est, c'est genre on essaye de
calquer tout ce qu'on a toujours fait comme avant sauf qu'on leur donne des nouveaux noms et ce qui
fait qu'une fois qu'on parle de déploiement continu, qu'on parle d'architecture immutable,
ils nous regardent avec des yeux ronds les clients et ils se disent bah non nous on fait pas ça mais
par contre on fait du DevOps et ça vraiment je pense que c'est je pense qu'on a un devoir d'éducation
qui n'a pas été fait. Le terme s'est répandu comme un espèce de feu de poudre, ça a été hype,
maintenant DevOps ça commence même à être puéte hype, on commence à dire serreux à tout bout de champ
mais dans tous les cas l'industrie ne l'a pas adopté. Donc il y a vraiment ce décalage et
aujourd'hui ça c'est une douleur et je pense qu'on a un devoir d'éducation à faire de l'industrie.
Et donc justement comment t'expliques toi le déploiement ? Si jamais tu devais parler à ta
grand-mère d'expliquer ce que c'est qu'un déploiement, comment tu l'expliquerais en fait ?
Alors la grand-mère c'est un challenge assez sévère quand même, c'est comme mon
neveu qu'à cinq ans, c'est compliqué d'expliquer un déploiement parce qu'il y a quand même pas
mal de notions sous-jacentes qui sont un peu compliquées, notamment le simple fait de savoir
qu'il y a une machine dans une cell server qui fait tourner l'application, c'est pas donné à tous
les profils. Donc j'ai quand même la chance que mon interlocuteur moyen, il a un niveau plus élevé
que ma grand-mère, c'est une chance, je m'estime vraiment heureux. Par contre eux ce qu'ils ont
vraiment pas intégré c'est que l'industrialisation c'est pas un seul script bash qui va se connecter
en cessa sur la machine et qui fait un guide pool. Il y a vraiment un process, il y a une nouvelle
manière d'imaginer sa production. Et pourquoi d'ailleurs ça ne marcherait pas de faire ce,
parce qu'on va rétorquer que pendant très longtemps ça marchait ainsi et ça marchait très bien
ou pas, je sais pas, mais en tout cas ça marchait, les gens arrivent à faire tourner des prods avec ça.
Pourquoi avoir une nouvelle manière d'imaginer le déploiement ?
Mais ça c'est une très bonne question, je l'ai souvent cette remarque là, c'est l'une
remarque que j'ai le plus souvent. La plupart des intégrateurs viennent me voir en me disant
mais c'est débile de passer par vos systèmes avec des scripts très compliqués parce que avant
je me connectais en cessa, je lançais ma commande et j'en avais pour cinq minutes. Le principal
problème que je vois c'est que la commande que vous lancez manuellement, il n'y a pas de trace
que vous l'avez lancé manuellement. Donc si vous demain vous avez 10 serveurs et non pas un seul,
vous faire 10 fois la commande manuellement sur les 10 serveurs et parfois la personne qui a fait
la commande elle a démissionné, donc plus personne ne sait que faut la taper, donc la prod
elle va tomber et ça va faire plusieurs heures d'indisponibilité le temps qu'on comprenne pourquoi.
Ça c'est le manque d'industrialisation, c'est que toute opération manuelle, ça équivaut
à si vous ne l'aviez pas fait en fait. Ça veut dire que si vous faites manuellement quelque chose,
potentiellement quand votre serveur tombe et qu'on le redémarre, on va oublier de le faire.
Et donc ça c'est typiquement le plus gros problème qui s'oppose au fait d'avoir un script
ou d'avoir des actions manuelles à faire et puis après c'est aussi une question de précision
et de taux d'erreur en fait. Un humain a forcément un taux d'erreur qui est extrêmement
élevé par rapport à une machine. Quand on automatise un déploiement, on est capable de le faire
10 fois dans la journée et on a confiance dans le déploiement parce que la machine ne fera pas
d'erreur. Les erreurs potentielles que la machine pourra faire, c'est les erreurs que les développeurs
ont fait, mais là bon bah c'est un bug et on le résout et ça marche comme n'importe quel autre
projet informatique au final. Mais justement en fait, on t'a parlé des bugs, peut-être l'avantage
qu'on peut voir avec un être humain en tout cas et là je me fais vraiment l'avocat du diable,
c'est de se dire que un humain va s'apercevoir de ses erreurs. Là où une machine ne fera que
bête et méchamment aller dans son bug. Est-ce que justement le déploiement n'a pas une partie humaine ?
Où est-ce que se place l'humain justement dans ce déploiement ? Est-ce qu'il est uniquement
dans la réalisation des scripts, enfin des scripts, de la mécanique de déploiement ? Où est-ce
qu'il y a une partie humaine qui doit être inhérente au déploiement ? Je pense qu'on ne pourra jamais
se passer des humains parce que ça je l'explique à tous mes clients, à chaque fois qu'on rajoute du
code, on ne rajoute pas du code, c'est pas one shot, il y a le maintien derrière. Il y aura forcément
des bugs, il y aura forcément des problèmes de déploiement à un moment donné, il y aura l'application
qui évolue, l'architecture qui évolue, la plateforme peu importe. Donc il y aura forcément un
humain pour corriger les bugs. La grosse différence entre des actions humaines et des actions machines,
c'est que les actions humaines, une fois qu'on les a finies, la prochaine fois on repart de zéro,
on est obligé de refaire tout depuis le départ. Une machine, c'est un script qu'on a écrit,
donc quand on a une modification à faire, on additionne cette modification à tout ce qu'on a déjà
accumulé comme expérience auparavant. Donc la machine ne fait que s'améliorer. L'humain,
lui, repart de zéro, donc il est capable de régresser sur ses opérations, sur ses procédures. L'automatisation
permet réellement de ne pas lier au défaut d'être humain tout simplement. C'est tout l'intérêt
d'automatiser, c'est de réduire l'auto d'erreur. Après, par expérience, on ne pourra jamais l'annuler.
Il y aura toujours des erreurs et j'ai jamais vu aucune entreprise pouvoir se venter de ne
fait plus d'erreur. Ça n'existe pas. Moi, il y a quelque chose qui me tient pas mal à l'aiseur. Là,
pour le coup, ce n'est peut-être pas une question, c'est vraiment une remarque de ma part. C'est un
sujet que j'aborde assez souvent en off ou même j'ai déjà fait des talks là-dessus, qui a
la différence entre mécanisation et automatisation. Moi, j'utilise le terme de mécanisation. Après,
je sais que Google dit la différence entre automatisation et automatique. Est-ce que tu
vas pousser ? D'abord, tu vas commencer par la mécanisation, c'est-à-dire les tâches qui
avant étaient manuelles sont scriptées ou sont faites de manière, comme t'as dit, avec un
apprentissage de code sur ce qui a été fait. Ou est-ce que tu vas même réussir à changer le
process entier de déploiement pour devenir vraiment automatique quand on parle chez Google,
ou avec un automate, le résultat, l'automatisme ? À quel niveau tu vas gérer le déploiement ? Est-ce
que vraiment tu vas juste mécaniser ou est-ce que tu vas aller au-delà dans ce que tu fais ?
Là, c'est assez marrant parce qu'en fait, je suis en train d'écrire une nouvelle article qui
parle de ça justement parce que le problème de l'automatisation, c'est qu'une fois qu'on a
fini d'expliquer aux clients ce qu'on a envie de faire et vers quoi on évolue, la plupart des temps,
ils sont impatients et ils veulent tout automatiser. Le gros problème de l'automatisation, c'est que
on refait nos scripts tout seul dans notre coin, les développeurs font des erreurs, il y a des bugs.
Au final, il y a vraiment toujours un double tranchant à rajouter du code quelque part. Parce
qu'en rajoutant du code, on rajoute forcément de la surface d'erreur et en rajoutant de la surface
d'erreur, logiquement, il y aura des bugs. En fait, j'ai toujours une très grande méfiance vis-à-vis de
l'automatisation. J'écris le moins de codes possible et j'invite mes clients à toujours en écrire le
moins possible. Plus on écrit du code, plus on fait des erreurs, c'est juste mécanique. Il y a un
moment donné, il faut juste éviter d'en écrire. Donc si jamais on utilise Jenkins, parce que c'est
le choix historique de la boîte et que Jenkins fait quelque chose et que ça a été codé par quelqu'un
d'autre, ça a été testé par quelqu'un d'autre, on va utiliser cette partie-là parce que au moins
celle-là, on sait qu'elle fonctionne. Et moi j'ai du mal à distinguer automatisme, mécanisation,
mais j'essaye d'avoir cette lucidité au cas par cas, en fait, à de voir que c'est pas parce qu'on
peut automatiser quelque chose qu'il faut l'automatiser. Mais même loin de là, souvent on perd du temps,
on écrit des scripts qui nous paraissaient simples, finalement on y passe une semaine.
Et en fait, on gagne très très peu. Donc en fait, il faut vraiment avoir cette lucidité et
n'automatiser que ce qui est vraiment crucial à automatiser.
Et donc justement, comment tu vas faire ? Qu'est-ce que tu vas faire si quelque chose n'est pas
crucial à automatiser ? Quels sont les possibilités que tu vas te laisser entre tous ces bien-là ?
Quels sont les mécanismes que tu vas mettre en place et tu te rends compte qu'une automatisation
est compliquée ? La laisser pour un être humain, changer de système, changer d'organisation,
etc. Je sais que ça va être au cas par cas, mais à peu près, qu'est-ce que tu vas pouvoir
retenir ? Dans quel cas on va pouvoir revenir comme avant ou sauter une nouvelle barrière ?
Oui, c'est assez compliqué. En fait, c'est vraiment... Enfin, par exemple là, je sais que c'est un gros
client, en finale, il y a une contrainte qui fait que c'est complètement impossible
d'automatiser une mise en production, puisqu'en fait pour une mise en production, il faut
avertir les services de production, parce que c'est un service externe, au moins une
semaine à l'avance, avec un mail qui détaille ce qu'il y a dans la mise à jour, etc.
Donc on en a automatisé une certaine partie grâce à du Git log, on rédige le mail, etc.
Mais en fait, la contrainte est trop forte, c'est la structure de l'entreprise nous
empêche de l'automatiser. Donc au final, quelque part, c'est pas grave, puisque avant,
c'était pire. En fait, je crois que c'est ça l'idée, le mettre mot. Avant, c'était pire.
Donc en fait, on a un mode amélioration continue. Si demain, cet organisme qu'on doit prévenir
une semaine à l'avance, il nous dise, bon maintenant, c'est deux jours parce qu'on a confié
dans les scripts, ce sera un progrès, ce sera toujours manuel, mais ce sera un progrès.
Vraiment, je pense que c'est l'idée principale derrière ce que je mets en place, c'est de
mettre en place des améliorations continues, d'être lucide sur ce qu'on fait, sur comment
on peut s'améliorer. Et puis ici, c'est mieux qu'avant, c'est que c'est une bonne solution.
Derrière, moi, j'ai jamais vu une chaîne complètement automatisée. J'ai vraiment
l'impression qu'à moins d'avoir énormément d'argent, ce qui est sans doute le cas de Google
ou d'Amazon, ça juste ne marche pas. Au bout d'un moment, on sort une barrière entre l'énergie
qu'on est capable d'y dépenser et le résultat qu'on veut obtenir, c'est comme avoir un uptime de 100%
et d'avoir jamais aucun down time. Il faudrait déployer une énergie colossale pour y arriver.
Du coup, en fait, on met un peu la casquette Michel Goudainov et on se dit que finalement,
notre déploiement n'est pas si mal puisque au moins, il est mieux qu'avant. Si je prends
là mon client actuel, on a réussi à faire un déploiement en urgence en moins de 5 heures,
là où avant, il nous fallait 4 jours, 5 jours pour un déploiement d'urgence.
Là, si je reviens au déploiement, à chaque fois, tu vas parler de déploiement applicatif,
le dernier déploiement métier d'une application donc fait en interne. Ça va être la même chose
si c'est un produit d'infrastructure. Par exemple, je vais déployer demain une base de
données à ce service, un cloud provider ou n'importe quoi, enfin un cloud interne type IAS.
Est-ce que le déploiement, en fait, ça veut vraiment dire la même chose dans tous les cas.
En fait, c'est plus ça que j'aime avoir. Est-ce que ça veut dire la même chose que de déployer
un CSS pour mettre à jour, je ne sais pas quoi, dans un site ou déployer un faim moire sur des
machines ? À quelle échelle est ce déploiement et est-ce qu'il y a des choses en fait en commun ou pas ?
Moi, sur la partie faim moire et bar métal, en fait, ce qui est matériel, j'ai assez peu d'expérience
et j'ai tendance à dire que là, ça reste un peu différent. Par contre, sur la partie logicielle,
que ce soit l'open stack qui permet de déployer derrière des applications ou que ce soit la
dernière version du front-end, moi, je n'ai pas tellement de différence. C'est-à-dire que j'essaye
de suivre au maximum les recommandations 12-factor app, les applications 12-factor, je pense
que ça a été traduit en français, il faudrait vérifier. Ce qui fait qu'à fait une application,
que ce qu'elle soit au niveau infra ou au niveau fonctionnel, en réalité, elle va être développée
selon les mêmes principes fondateurs. Donc, je ne vois pas tellement de différence. Puis de toute
façon, la production des gens qui déploient l'open stack, c'est la plateforme des gens qui déploient
l'applicatif. Mais moi, pour moi, le déploiement n'a pas lieu d'être réellement différent. C'est
dire qu'en fait, notre métier, c'est de s'occuper de la production, peu importe à qui elle s'adresse
en finale. Et ça, pour ça, je pense que toutes les productions se ressemblent au moins dans les
grandes lignes. Après, les besoins et les contraintes de chacun font que tous les déploiements sont
uniques. Et donc, t'as parlé de 12-factor app. Quels sont justement les bonnes pratiques 12-factor,
donc ces 12-factor ? Quelles vont être pour toi les choses en priorité souvent que tu as pu mettre
en place et qui n'étaient pas présentes ? Ceux qui connaissent vont trouver ça peut-être très
bateau. Mais quelles sont les premières choses qui permettent souvent d'améliorer les contextes
de déploiement ? Et que les gens ne connaissent pas ? Alors, en fait, c'est assez drôle parce que
dernièrement, à un meet-up, il y a un développeur qui m'a dit « mais non, ça n'existe pas ce que tu
me racontes ». Mais en fait, la plupart des clients n'ont aucun moyen d'automatiser l'installation
de leur serveur. C'est-à-dire que les serveurs, dans 90% de mes clients, c'est des choses qui sont
installées à la main. Donc en mode « je fais un SSH et puis j'installe avec un pétiguette, installe ».
Donc la toute première chose que je mets en place, en général, je le fais avec Ansible. Moi,
j'aime bien cette techno. Après, on peut la critiquer. Je n'ai pas de préférence particulière
jusqu'à celle que je connais le mieux. Donc en fait, j'utilise ça pour déjà automatiser la
réinstallation du serveur. Donc ma première étape, ma première milestone chez un client,
c'est de pouvoir détruire la production et de la recréer. Ça, c'est vraiment la
milestone la plus importante selon moi. Ensuite derrière, il y a des clients qui sont un peu
moins mal lotis ou eux, par contre, ils ont automatisé les serveurs. Mais il y en a très,
très peu qui sont arrivés à vraiment cette notion d'architecture immutable. C'est-à-dire
qu'ils continuent, même s'ils ont un équivalent de chef, peut-être peu importe, de provisionner
leurs serveurs au-dessus d'un serveur déjà provisionné. Ils ne partent pas d'un serveur tout
neuf. Donc ça, en fait, effectivement, c'est un peu plus rapide que de reprovisionner le
nouvel VM et de refaire le provisioning France Cratch. Néanmoins, ça pose un problème, c'est
que si le jour où votre serveur crache, vous n'êtes pas sûrs que votre provisioning fonctionne sur
un VM France Cratch. Donc ça, souvent, c'est la deuxième chose que je mets en place. C'est un peu
moins urgent parce que malgré tout, la prod fonctionne à ce moment-là, mais essayer de faire en sorte
que les images qu'on va déployer, on les provisionne une fois et ensuite on sauvegarde l'image. Et là,
à partir de là, c'est l'image de notre déploiement porte la version du logiciel. Et même si on
déploie juste un fichier CSS, on crée une nouvelle image. Tempire, ça coûte du temps machine,
mais ça ne coûtera pas du temps humain dans le déploiement. Ça, c'est la deuxième chose que
je mets en place. Et la dernière, souvent, je m'arrête là parce que déjà, ça se fait sur 3-4
mois et je me dis que le client est sur de bonnes voies, donc j'ai pu vraiment de valeur ajouter.
C'est la notion de BlueGrain, donc le fait de pouvoir popper une instance de la nouvelle version,
refaire le câblage réseau pour que la nouvelle version prenne le pas sur l'ancienne et ensuite
diminuer l'ancienne version. Ça, c'est pareil. Il y a plein de personnes qui peuvent utiliser des
services qui sont tout faits, qui fonctionnent très bien. Moi, j'ai jamais utilisé de services
tout près pour faire du BlueGrain. Il y a toujours fallu que je réécrive le script. Ça, c'est
pareil. Ça peut faire sourire parfois, mais les scripts de déploiement, les scripts de BlueGrain,
actuellement, je n'ai pas trouvé de solution vraiment satisfaisante, toute prête, qui me
permettait de le faire. Souvent, c'est le code que j'ai réécrit chez chacun de mes clients.
Là, dans les deux premiers critères dont on t'a parlé, il y a assez peu question du logiciel
final. C'est plus l'environnement autour dont on a besoin, que ce soit les serveurs, les VM,
pour arriver à un déploiement stable. En gros, de ce que je comprends, en tout cas, tu commences
à commencer par une base, par construire les fondations pour après pouvoir déployer. Le
intervention au niveau de l'application. Une application doit être adaptée, à tourner à
deux versions différentes en même temps. Est-ce qu'il y a d'autres choses que tu fais comme ça
d'intervention dans le code du logiciel, donc le logiciel métier, celui qui est développé en
interne ? Et comment se passe cette relation-là, comment réussir à donner à une équipe de dev,
de dire, il y a une problématique de déploiement ?
Oui, j'ai tendance à dire que c'est ce qui fait que le travail est finalement plus compliqué que ce
qui lit pareil. C'est assez simple de parler du déploiement, des différentes méthodes de
déploiement. C'est de la littérature qu'on trouve sur Internet. Souvent, en anglais, malheureusement,
on peut trouver des traductions, ça marche bien. Par contre, le vrai challenge, selon moi,
il est surtout sur l'organisationnelle, en fait, il est surtout sur les relations
qu'ont les personnes dans le processus de livraison, dans le processus de création.
Quand un développeur me demande qu'est-ce que c'est qu'une brique Stakeless, bon,
je suis un peu embêté parce que ça veut dire que leur backend, il n'est pas Stakeless.
Typiquement, le BlueGrain, ça ne marchera pas bien. Je ne pourrais pas scale l'application en
mettant deux briques identiques parce qu'ils ne vont peut-être pas réussir à parler à la base de
les données en même temps. Il va vraiment falloir que j'éduque aussi les développeurs à
qu'est-ce que le déploiement, qu'est-ce que ça implique et pourquoi ils devraient s'y intéresser.
Cette relation-là, elle est assez compliquée parce qu'en fait, c'est de l'humain. J'ai pas
fait réellement d'études de psychologie. J'ai l'impression que je commence à être bon en
psychologie malgré tout parce que j'apprends sur le tas. Mais ça, voilà, les devs. Donc,
il y a vraiment une notion qu'il faut éduquer les devs en plus d'éduquer le management sur qu'est-ce
que c'est qu'un déploiement et qu'est-ce qu'il propose, il faut investir dessus. Donc, ça,
c'est la partie social du travail. Dans les faits, c'est une très large partie du travail. C'est
même la principale, passer son temps en réunion, passer son temps à corriger, à faire en sorte
que tout le monde se déchire pas sur les poules réquest mais soit plutôt constructif. Ça, par
contre, il n'y a pas de recette magique. Il y a même assez peu de littérature sur comment on gère
les conflits, comment on gère la transition, comment on fait les formations internes. Il y a aussi un
truc qu'on ne parle pas assez souvent, c'est que moi, j'arrive dans une entreprise, je suis à chez
jeunes, je n'ai pas encore 30 ans. C'est mal vécu. C'est qui ce petit con qui vient nous donner des
leçons. C'est un problème que j'ai. Voilà, ça, c'est la partie, je vais dire, un peu compliqué. Il
n'y a rien qui nous prépare à ça. Il n'y a pas de formation qui nous permet de définir comment on
le fait. Il faut y aller au feeling et il s'avère que je ne suis pas mauvais là-dedans, tant mieux,
mais j'avoue que ce n'est vraiment pas la partie la plus simple. Dans les déploiements,
là, tu as parlé très vite, tout à l'heure de Jane Keane, etc. Justement, comment on garantit le
déploiement quand on fait en sorte qu'il arrive de plus en plus souvent ? On a une équipe plus grosse
de testeurs pour pouvoir tester en permanence les nouveaux déploiements. Comment on va se passer
justement cette partie assurance des déploiements qu'on fait ? Sur la partie QA, j'ai eu un ou deux
clients qui avaient des testeurs à temps plein. Là, c'est royale. On peut vraiment se reposer sur eux.
La plupart du temps, ils n'ont pas. La plupart du temps, ils ont ni test QA, ni test automatisé.
C'est le CEO qui se connecte sur la prod et qui teste un peu comme il peut. En fait, encore une fois,
le maître mot, c'est mieux qu'avant ou moins pire. On essaie de faire au mieux. L'avantage d'avoir
industrielisé le déploiement, c'est que si une fois qu'on a déployé, on s'aperçoit que ça ne
marche pas, on peut rollback, on peut remettre la version d'avant et ça nous coûte du temps
machine. Mais au pire, ça dure une demi-heure si vraiment les scripts sont longs et il n'y a pas de
raison que ça dure plus de cinq minutes. Après, il y a aussi la solution de, ça ne marche pas,
mais le fixe est rapide. On ne va pas déployer la version N-1 mais la version N-plus-1.
C'est la solution qui est encore mieux puisque du coup, on fixe très rapidement. On casse
rapidement mais on repart rapidement. L'idée, c'est le moment de toute l'équipe qui évolue.
Là, on a évolué dans le mindset. Ce n'est pas grave de faire des erreurs. Là, on évolue vraiment
sur la notion assez reux qui est décrite comme le crédit d'erreur. Si vous n'avez pas suffisamment
de downtime, si vous n'avez pas pris suffisamment de risque, c'est plutôt bien. Maintenant,
le must du must, c'est d'avoir à la fois des tests automatisés et une équipe de QA. Le problème,
c'est que les clients n'ont pas tous le budget de se frérir ça. Écrire les tests automatisés,
ça prend du temps. Une équipe QA, ça prend des salaires. Jusqu'à maintenant, la plupart de mes
clients, ils n'ont pas ces choses-là. On s'occupe surtout d'automatiser le déploiement sur la
partie QA. Quand ils ont le budget tant mieux, puis la plupart du temps, c'est moins pire qu'avant.
En imaginant qu'il y a une QA, même en imaginant qu'elle soit super avec, comme tu as dit,
de l'automatisme et des tests user humains, qui va prendre la responsabilité de déployer ?
Et question donc qui vient avec, qui va le faire ?
Ça dépend de la boîte.
Mais justement, pour démystifier un peu ce processus de déploiement,
comment ça se passe ? Est-ce qu'il y a un grand meeting des chefs à plume qui dit,
là c'est bon, on a testé, on est OK, tout le monde met un go et on part dans ces cas-là ? Est-ce
qu'on a un flux plus continu ? Est-ce que c'est le SRE qui en prend la responsabilité ? Est-ce
que c'est le chef de produit ? Quelles va être toutes les dimensions qu'on peut avoir ?
J'ai eu pas mal de schémas différents. Dans les startups, on est plutôt en mode YOLO.
Le dev a fait un quick fix et il a pu sous le bouton et puis ça marche.
Sur les gros clients, c'est un peu différent. Il y a vraiment une réunion de validation.
Il y a le contact de la partie qui s'occupe de la supervision et des astreintes.
Donc au final, la question de la responsabilité, moi elle me fait doucement sourire,
mais elle est très différente dans chaque entreprise.
Parce que le problème de la responsabilité, c'est le problème de qui est-ce qu'on engueule si ça
et plus la boîte est grosse, plus elles sont réticentes à faire des mises en production,
plus elles sont réticentes à déployer. Ce qui est assez drôle, c'est que c'est vraiment un
cercle vicieux. S'ils sont réticents à déployer, ils vont attendre plus longtemps,
donc il y aura plus de features, donc il y aura plus de bugs potentiels. Donc il y a des chances
que ça se passe mal et vu que ça se passe mal, la prochaine fois ils seront encore plus fréleux,
ils vont mettre encore plus de temps, il y aura encore plus de surface. Du coup, ils vont forcément
évoluer vers un modèle où ils vont être bloqués, ils vont faire une mise à jour tous les six mois
et ça c'est le plus mauvais pattern qui existe. L'idée c'est de déployer le plus souvent possible
parce que quand vous déployez souvent, vous déployez peu. Les développeurs ont pas eu le temps de faire
30 000 features, donc quand on déploie peu de features, il y a peu de bugs potentiels et souvent
les utilisateurs sont très contents de tester la feature et ils sont même pas en colère quand
ils trouvent des bugs, ils sont même plutôt contents de dire « à la nouvelle feature, c'est pas encore sec ».
Donc là, l'idée de la responsabilité diminue au fur et à mesure que les déploiements diminuent,
c'est-à-dire que à partir du moment où les erreurs sont moins graves, tout le monde s'en fout
et on peut prendre la responsabilité, ça se passera bien. Là où ça devient problématique,
c'est justement quand les déploiements sont très espacés et que le problème d'une mise à
prod peut faire un donetime de 48 heures, 72 heures, là c'est très grave et là on a besoin
d'un pôle qui prend la responsabilité. Mais ça c'est typiquement le mauvais pattern et c'est
ce que j'essaie de casser, donc j'essaie de ne plus parler de responsabilité de déploiements parce
que justement j'aimerais bien qu'on enlève ça en fait. Et donc là on parle de logiciels qui sont
en tout cas de structures qui sont déjà bien définies, avec des logiciels qui sont déjà en
place et donc qui sont dans un mode maintenance en fait, ça aide d'ajouter des nouvelles
fonctionnalités ou de résoudre des problèmes. À quel moment je m'occupe du déploiement ? C'est
à quel moment dans le cycle de vie d'un produit et dans la création d'un produit, on va se soucier
de ces problématiques de déploiements. C'est quelque chose qu'on a eu dans le dernier DevOps
qui malheureusement n'est pas encore en ligne parce que je n'ai pas accès aux sources venant de l'école
42, donc c'est quelqu'un à des contacts, je veux bien, mais quelqu'un nous avait justement
posé la question de savoir quels étaient les outils qu'il fallait utiliser, à quel moment je
m'en souciaie, qu'est-ce qu'il fallait que je fasse alors que je suis dans la création d'une
start-up. À quel moment je me soucie de ce problème là, de déploiements ? C'est au tout début,
c'est quand on a un logiciel qui marche, à quel moment on va avoir ces problèmes qui apparaissent
ou en tout cas qui devient problématique et à quel moment toi tu les résolveras ?
En fait la réponse rapide qui me vient d'être tout de suite c'est le plus tôt possible dès
le premier sprint, il faut qu'on soit en prod puisqu'en fait en gros à chaque itération,
à chaque changement, la milestone pour dire ça y est c'est fait, c'est que c'est en prod. Je veux
dire si c'est pas en prod ça sert à rien, l'entreprise n'aigle pas d'argent avec donc c'est comme si
on n'avait rien fait donc le mise en prod c'est le plutôt possible. Mais là on en revient en point
du départ c'est que l'industrie n'est pas éduquée sur justement ce problème de déploiements donc
la plupart du temps ils vont engager des devs pour faire un produit avec une deadline intenable
parce que les investisseurs veulent quelque chose dans deux mois et il y a quatre mois de devs.
Donc en fait on va postponner la partie déploiement, c'est pour ça qu'elle arrive souvent en retard.
J'arrive souvent dans des entreprises qui me disent bon bah voilà on a développé un truc
magnifique par contre c'est pas en prod et on sait pas comment faire. Pour moi c'est un mauvais
pattern, si jamais on a la possibilité de partir d'un projet from scratch, la CIA et la CID,
c'est des choses qu'il faut réfléchir dès le départ. C'est pas le but d'avoir une CIA
CID complètement obtise aux nions à tout automatiser, enfin on va perdre du temps si jamais on veut
faire ça, mais d'avoir au moins des linter et un process pour dire quand j'ai pu ce bouton là,
j'ai une image qui se crée et ensuite je peux la déployer, c'est le plutôt possible. C'est le
premier jour du projet en fait. Si jamais on attend la veille du déploiement pour se demander
comment on déploie, c'est sûr on est sur un échec. Et donc pour finir, quelle va être pour
toi la journée type idéale d'un SRE en cas tel que toi tu verrais la journée idéale, la journée qui
se passe très bien dans une organisation quasi parfaite et qui va... Alors en fait c'est
assez drôle parce que le travail SRE, on garde une vision assez utopiste de on n'a plus rien à faire
en fait. Typiquement moi j'essaiera rien dans le cadre idéal, les développeurs sont autonomes,
ils créent une application et les personnes qui sont chargées de mettre en production, souvent
c'est le CEO ou le commercial, il appuie sur un bouton et puis ça marche et puis tout va bien.
Donc ça, ça serait la journée typique dans le cadre vraiment idéal. Ma journée à moi,
elle est plus tirayée entre des développeurs qui se demandent est-ce qu'ils devraient mettre
plus de logs, comment ils devraient les rapatrier pour avoir plus d'informations sur la production,
d'un point de vue déploiement ça va être, est-ce que cette feature là tu penses qu'elle est
sèche, est-ce qu'on peut passer sur telle nouvelle version de tel brick ? Donc j'ai quand même beaucoup
de travail au quotidien, c'est notamment sur l'évolution des bricks, on typiquement
fait révoluer solaire sur la dernière version de solaire parce que là on a en version 6 et
une version 7, pareil pour Elka, pareil pour MongoDB, pareil pour... Ça c'est ce que les
développeurs ne gèrent pas et puis du côté développeur ça va être, j'ai une nouvelle
variable d'environnement à préciser, il faut la rajouter dans les déploiements et ça c'est la
journée typique calme qui m'arrive. Après il y a la journée moins typique où il y a un problème
en prod et donc là je suis sur le qui vive mais en général on appelle les développeurs puisque
les bugs ça fait partie de l'application quoi. La plupart du temps, ça peut arriver un bug
d'architecture mais c'est plus rare. Bon, super, je pense qu'on a fait à peu près le tour de la
partie déploiements, je sais pas si c'est quelque chose à rajouter. Là comme ça ça me vient pour
la tête. Bon, c'est qu'on a assez parlé du sujet. Donc voilà, j'espère que ça vous a plu,
un format court sur le déploiement. On va essayer d'en faire beaucoup cet été pour que vous ayez
un peu de lecture soit sur la plage soit quand vous rentrez dans les transports en commun,
Vida à Paris ou Aya. Et on vous souhaite tous de bonnes vacances.
Oui, de bonnes vacances. Rechargez-vous, lisez, bullez, faites ce que vous voulez et voilà
et puis on vous souhaite de revenir bien en forme à la rentrée pour encore plus de DevOps.
Oui, exactement. Merci à tous.
Au revoir.