Dev Ops Le magazine et observatoire du Dev Ops
Bonjour à tous et à toutes, bienvenue pour le troisième numéro de Dev Ops.
Alors aujourd'hui, nous avons un peu changé les participants.
Donc à ma gauche, nous avons Bartelémy.
Il est toujours là.
En face de moi, toujours Victor.
Salut.
Et à ma droite, pour la première fois, nous avons Lucas.
Alors, je vais te laisser de présenter.
Bonjour, c'est Lucas.
Je travaille avant de priver en tant que lead dev.
Mais par contre, pourquoi on m'invite, c'est parce que mon métier précédent, c'était
de faire SRE à Google.
Donc, c'est une cascade que je porte un petit peu aussi avant de priver.
C'est un peu de vision SRE de DevOps et de production.
Donc voilà.
En fardeau.
En fardeau, si on veut.
Alors, super.
Alors, avant de commencer, j'aimerais déjà revenir sur quelque chose qu'on a fait la
semaine dernière ou la semaine d'avant qui était un numéro hors série.
Donc, si jamais vous l'avez pas vu, vous pouvez aller l'écouter sur SoundCloud et
sur les autres plateformes où on l'a mis à disposition.
On le refrape peut-être d'ailleurs très prochainement.
Donc là, c'était des interviews dans le sein d'un meet-up, donc des intervenants
qui étaient présents et pour avoir un peu leur vision de ce qu'ils ont présenté,
peut-être sous un autre point de vue que vraiment ce qu'ils ont fait dans les meet-ups.
Donc, n'hésitez pas et on le refrape.
Alors, on nous avait quand même dit que c'était un meet-up qui n'était pas très
orienté d'EvOps.
On avait choisi de le faire parce que pour des raisons techniques, pour des raisons
logistiques, c'était plus simple pour nous.
Les personnes étaient, cela dit, très intéressantes.
Donc, allez-y, écoutez-le et nous, de notre côté, on s'intéressera à faire des choses
plus orientées d'EvOps les fois prochaines dans de nouveaux meet-ups qu'on vous fera
partager avec plaisir.
Et on a aussi plein d'autres idées pour d'autres encore séries un peu différents.
Donc, on n'hésitera pas à vouloir faire partager lors de prochaines émissions.
Donc, aujourd'hui, on va parler comme on a Lucas de SRE, mais avant ça, une petite question
qu'on fait à chacun des numéros de DevOps, c'est quoi pour toi le DevOps ?
Ok, donc ça, je n'avais pas préparé cette question, mais des questions assez proches.
Pour moi, le DevOps, en tout cas, comme je le vois à l'heure actuelle, il y a deux
définitions de DevOps.
Il y a qu'est-ce que j'aimerais que soit le DevOps et qu'est-ce que j'observe et le DevOps.
Dans ce que j'observe du DevOps, principalement par exemple des recrutements, je vais scanner
des CV, je regarde un peu ce qu'ils ont fait, je discute avec des personnes.
Je vois beaucoup de DevOps qui font de l'automatisation, un peu de mécanisation, j'ai envie de dire,
pas forcément de l'automatisation, qui ont fait pas mal de Jenkins, de la CIA, des trucs
comme ça.
Par contre, avec la Cascade SRE que j'avais à Google, dans mon équipe, en tout cas,
il y avait une grosse partie d'automatisation et de système, mais beaucoup, beaucoup orienté
production, plutôt qu'automatisation.
Ce n'était pas nous qui construisions nos propres outils de scheduling, par exemple,
on avait déjà qui était fait.
On n'allait pas monter un nouveau Kubernetes parce que quelqu'un l'a déjà fait pour nous.
On était, on va dire, spécialisés sur un produit critique, ou deux, trois, quatre produits
critiques et on avait les clés du camion.
Là, il nous a bien présenté une introduction pour le prochain sujet, je pense.
On va commencer peut-être tout de suite.
Avant ça, une petite question.
Tiens, quel est l'objectif de la méthode des cinq pour quoi ?
Les cinq pour quoi ? Alors les Five Wives, le but, c'est de arriver soi-disant à la
route cause, on va dire, du problème.
On va demander pourquoi ça s'est passé, parce que tel mécanisme s'est produit, pourquoi
tel mécanisme s'est produit, parce que telle personne n'avait pas eu le temps de faire
un patch, pourquoi la personne n'avait pas eu le temps de faire le patch, on continue.
Et pourquoi la raison, au final, c'est toujours à cause des élections américaines ?
Super.
Tiens, d'ailleurs, j'ai choisi cette question, c'était dans le trivial poursuite édition DevOps.
Je choisis cette question parce qu'aujourd'hui, j'ai vu trainer une petite vidéo, je sais
pas ce que vous l'avez vu, avec un acteur...
Gérard Depardieu.
Gérard Depardieu, voilà, dans un de ses précédents films, et j'ai plein noté le film, j'aurais dit.
Mammouth.
Exactement.
Mais avec la plus que cinq pour quoi, parce que c'était sept ou huit pour quoi, et à la fin, ça arrive à la conclusion,
on a vu, qui sera celle tout le temps, qui est parce que je suis un con.
Et voilà, je pense que ça sera à peu près la conclusion de tous les patchsois si jamais on va assez loin.
Bon alors, on va tout de suite entamer dans le vieux du sujet pour le coup.
Donc, je vais laisser Victor nous parler un peu du SRE.
On va pouvoir partir sur un débat là-dessus avec Lucas et son expérience de l'origine,
enfin, devenant du cœur de la mule du SRE.
Donc, c'est à vite fait quelque chose.
Alors du coup, à la base, le sujet, c'est SRE versus DevOps, tel qu'on l'a définie.
Mais du coup, le DevOps, je pense que j'ai pas besoin de le redéfinir, puisque Lucas vient de donner sa vision,
qui je pense est plutôt pas mal.
En tout cas.
Et puis sinon, vous écoutez les précédents numéros de DevOps.
Voilà, ça fera pas mal de points de vue différents.
Donc, je vais plutôt parler de SRE.
Alors, SRE, c'est quelque chose qui a été en tout cas un terme qui a été introduit par Google en 2003
par Ben Trainer, qui a engagé une équipe de sept software engineers pour faire tourner les systèmes de production de Google.
Et donc, en gros, SRE, ça vient de là.
En fait, à la base, c'est des software engineers qui avant tout, avant d'être des six admins,
qui ont eu pour mission de faire ce que font aujourd'hui les admins six.
Et enfin, je ne sais pas, il y aurait...
Merci, c'est bon.

C'est pas... Lucas, peut-être...
Enfin, toi, tu étais SRE chez Google.
Comment on voulait l'introduire ?
Comment, quel était votre rôle ?
C'était construit en interne.
Est-ce qu'on vous expliquait à Genèse ou est-ce que vraiment, c'était...
Non, il n'y avait pas trop de points historiques.
On va dire après, à chaque individu d'aller demander un peu l'historique,
parce que c'est une entreprise où on peut demander à des personnes qui sont là depuis dix ans quelle a été l'évolution.
Mais l'évolution, en fait, si on lit le livre de Ben Trainer,
et...
C'est pas Ben Trainer qui a écrit le livre, mais...
Le fameux livre qui est sorti.
Le livre SRE que Ben Trainer a promu.
Le SRE, à la base, il est là pour appliquer la méthode scientifique, entre guillemets,
au système de production.
Donc on a un système qui vit.
Il est vivant.
Bon, il a des propriétés sur la résilience, les performances.
Et le but du SRE, c'est d'aller regarder, en fait, ce système-là,
est-ce qu'on doit doubler la capacité, est-ce qu'on doit la tripler ?
Quand on triple la capacité, est-ce qu'on doit le faire dans un seul data center,
dans plusieurs data centers, en fonction de différents paramètres.
Donc l'aspect du SRE original, à mon avis, c'était vraiment se dire,
bon, on va fixer les problèmes, mais en réfléchissant comme un software engineer.
En disant, bon, on a un problème une fois, quand on fait du code,
on va essayer de factorer plusieurs propriétés dans un seul module.
En disant, bon, il y aura un module aux résiliences, un module, je ne sais quoi,
de telle sorte que les systèmes profitent d'une approche scientifique en année.
Et les NN6, en fait, maintenant, parce qu'il devait y en avoir.
Enfin, quel était justement cette appréhension sur cette approche,
sur la décomposition des problèmes, sur la décomposition des...
Parce qu'en fait, le DevOps, alors si j'aime enfin un petit truc,
c'est justement, on a deux parties importantes de l'infrastructure,
qui est le build et le run.
Et on a donc ces deux mondes qui sont complètement antagonistes
avec des objectifs différents.
Et le DevOps, c'est en normalement la faculté ou l'envie, en tout cas,
de casser le silo et de faire en sorte que les deux métiers
travaillent ensemble.
Là, en fait, dans le cas de SRE chez Google,
est-ce que juste c'est un métier qui est complètement gagné sur l'autre,
c'est-à-dire qu'en fait, les développeurs se mettent à faire de l'ops
et mieux que des ops, est-ce que c'est juste une manière de transition ?
Enfin, quel est justement cette...
Est-ce que les SRE font du run, en fait ?
Oui, les SRE font du run dans le sens où ils sont responsables, en fait,
pour un système critique.
Et c'est eux qui vont être appelés quand il y a une panne,
qui sont en col.
Donc on va dire, la moitié du travail du SRE,
c'est la théorie après chaque équipe, des variations.
La moitié du travail du SRE, ça va être de gérer la prod.
Donc il y a un incident de prod.
On répond aux incidents de prod et on change les systèmes
de façon à ce que ça n'arrive plus.
Et l'autre moitié du travail,
elle est prise pour du développement.
Et souvent, c'est du développement d'outils pour être capable de faire,
par exemple, un rollout de manière automatique
avec les propriétés qui vont bien pour ce système-là,
parce que certains systèmes ont des spécificités différentes.
Et le travail, on va dire, de développement,
ça va être pour des trucs qui pourraient être faits,
peut-être par des scripts, par des DevOps.
Mais quand on a une infrastructure et derrière,
on a des dizaines et des centaines d'ingénieurs très capés
pour faire des outils d'automatisation,
on ne va pas les réécrire nous-mêmes,
on va utiliser ce qui existe déjà.
Moi, j'ai une petite remarque.
C'est OK, dans Google, on peut fonctionner comme ça,
parce que justement, il y a tout un écosystème qui est déjà en place
et qui est déjà maintenu par des équipes ultra compétentes,
comme tu viens de dire.
Mais dans des boîtes à une échelle plus petite,
qui ont malgré tout besoin de se déployer sur plusieurs décès,
avec plusieurs centaines de serveurs,
mais qui n'ont pas les capacités et la force de frappe de Google.
C'est quoi, comment on agit en tant que SRO
ou en tant que DevOps ?
Et justement, est-ce qu'on peut avoir ce même équilibre
entre gérer la prod et faire que des outils ?
Est-ce qu'au bout d'un moment,
on n'est pas aussi obligé de faire de l'infrastructure,
du déploiement, du baird métal et en fait,
gérer un petit peu tout le lifecycle,
l'applicatif du matériel jusqu'au support user ?
Je pense que c'est vrai,
quand on est une petite structure,
on ne bénéficie pas des économies d'échelle,
donc ça, ce n'est pas nouveau de la même manière.
Le CEO d'une petite start-up,
il doit staper le marketing, il doit tout staper.
Donc la finance,
tandis que c'est plus une question de petite structure
versus grosse structure,
et c'est bien connu, on va dire,
qu'en disant d'une grosse boîte,
il y a ce confort de pouvoir réutiliser les compétences
et pouvoir s'appuyer sur des systèmes
qui vont sceler au sens humain également.
On est dans un métier informatique,
on a informatique de faire une chose dix fois
versus de la faire 100 000 fois,
ce n'est pas très différent.
Est-ce que tu dirais du coup
que ce que Google a fait avec SRE,
c'est applicable dans les entreprises ?
À partir du moment où elles ont atteint une certaine taille ?
sûrement, oui.
Je pense qu'il y avait un mot qui est revenu dans son intervention
qui était infra.
Et en fait, la telle que tu le dis,
c'est genre l'infra est utilisable telle qu'elle,
c'est-à-dire qu'elle marche,
elle est en avance,
et elle répond aux besoins a priori des développeurs
et des produits.
C'est-à-dire que tous les composants sont déjà présents
pour servir aux produits.
Et donc en fait, le SRE, c'est un développeur
qui va utiliser sur étagère des composants déjà présents.
Il ne va pas créer des composants.
Oui, par exemple, il y aura par exemple Borg
qui a un papier de recherche maintenant
qui décrit un peu ce que c'est,
mais c'est l'équivalent du Kubernetes interne.
Et on va dire, il y a déjà une équipe avec des SRE
pour le Kubernetes.
Donc il n'y a pas besoin nous de reconstruire un Kubernetes.
Mais voilà, des fois, on a des spécificités.
C'est par équipe,
on est dans une équipe qui avait des machines
qui ne tournaient pas sur Kubernetes.
Donc on devait entre guémeux se taper la config
jusqu'à un certain niveau de ces machines-là.
Mais c'était spécifique et c'est un besoin spécifique, on va dire.
La plupart des produits tournent correctement
sur l'infra-existante,
mais il y a une équipe staffée à temps plein
qui s'occupe que de ça.
D'ailleurs, tu parlais qu'il y avait des SRE dans l'équipe de Borg.
C'est-à-dire que dans un produit comme Borg,
il y a des développeurs des SRE en interne
ou est-ce que ce n'est qu'une équipe de SRE ?
Quand on parle de produits infrastructure,
pour le coup, qui est quelque chose qui est beaucoup plus lié,
qui est beaucoup plus bas niveau dans la stack,
est-ce que le SRE devient le développeur de sa solution
ou est-ce qu'il n'a vraiment encore que ce rôle de déploiement
et c'est le seul à être d'astreinte ?
Et il y a des développeurs à côté ?
Oui.
Non, vas-y.
En fait, les équipes SRE viennent
quand un produit est suffisamment critique.
Par défaut, un service qui n'est pas suffisamment critique,
ça dépend de critères que des grands managers vont décider.
Il n'y a pas besoin de staffer des SRE en disant
si ton SLA, par exemple, il est suffisamment relax,
ça va être l'équipe de Dev.
Vu l'infra qu'on a, vu les systèmes de monitoring
qui sont déjà en place,
qui vont se débrouiller pour faire tourner le système de SRE,
ils ont une double casquette.
Et ce n'est pas quand je dis ils,
ils ne sont pas les individus, c'est l'équipe,
ont un panel de compétences avec des gens qui sont plutôt systèmes,
qui vont...
Il y a des bars différents, en fait,
entre les gens qui sont plus systèmes
et la barre de recrutement software.
Il y a deux bars un peu différents en fonction des capacités de chacun,
parce qu'il faut une diversité de profils
pour répondre aux besoins d'un produit critique.
Donc on n'a même pas que un SRE.
Donc plusieurs SRE...
Nécessairement, parce que si un SRE est malade,
il faut qu'il y ait un deuxième derrière.
Un profil SRE, il n'y a pas un...
Ce n'est pas une boîte magique,
ce n'est pas qu'on prend n'importe quel SRE.
Il y a donc une diversité même au sein même des SRE.
Tout à fait, il y a des gens qui ont plutôt des compétences
et une appétence à faire des problèmes, on va dire,
très orientés software.
D'autres personnes plutôt systèmes,
des gens qui savent débuguer des trucs assez gorts
dans le kernel Linux ou je ne sais quoi.
Il faut de tout pour faire un monde
et pour faire une équipe qui marche bien,
il faut un peu de tout également.
Donc ce que tu es en train de dire,
c'est que le SRE, c'est à la fois un signe de maturité de l'application
et c'est aussi un signe de la criticité ou de l'importance.
Donc on n'en a pas nécessairement besoin dès le début.
Si on fait un petit service qui n'est pas important,
il n'y a pas de raison de staffer une rotation entière
parce qu'il faut qu'il y ait un SRE, il faut que...
il y ait son backup parce que sinon la première personne,
elle ne peut pas aller dormir.
Il faut staffer plusieurs équipes
ou quand j'ai plusieurs équipes, pardon, plusieurs personnes
et ça veut dire qu'il faut le justifier financièrement également.
Comment ça se passe ?
Parce qu'en fait, l'un est toujours en SRE versus DevOps.
Dans le DevOps, il y a toute une partie intérieure
qui va être la culture et le sharing.
Donc si on reprend l'état chronique à Mocams,
comment se passe justement ?
Donc si jamais on part dans une petite équipe qui n'a pas beaucoup de SLA,
pour faire en sorte qu'elle part dans une direction
qui soit à peu près en lien avec le reste d'infrastructures
que elle ne réinvente pas la roue,
est-ce que c'est juste parce que les développeurs sont tellement brillants
qu'il n'y a pas besoin qu'ils connaissent
parce que la culture est assez transmise au sein d'un compagnie
et comment se passe justement ce côté partage intérieur ?
Je ne pouvais pas répondre sur un système qui n'avait pas de SRE
parce que moi-même, je veux discuter surtout avec d'autres pères.
Donc je n'ai pas vu des petits produits qui n'en avaient pas besoin
pour commencer, je n'avais pas de masse d'interaction avec eux.
Ensuite, Google, c'est une entreprise qui fonctionne assez bien,
qui a pas mal de outils, de formations internes, de vidéos enregistrées
et ensuite chacun est libre de se former comme il veut.
En général, il n'y a pas de frein pour dire
« faut pas que tu fasses ça, les gens vont plus te dire « ok, tu as un objectif »
tant que ton objectif est atteint, tu passes ton temps comme tu veux,
si tu veux te former plus, tu te formes plus.
Il n'y a pas de réponse, je ne pourrais pas répondre
et surtout pas à la taille de la boîte.
Il n'y a pas une notion de gatekeeper, un moment.
Le SRE contrôle valide et une espèce de « so » qui dit « sere compliant »
Est-ce que c'est plus vu comme un conseiller, un accompagnateur
ou comme une espèce de gatekeeper,
donc de personne qui est là pour contrôler et dire si oui ou non,
ça peut partir en prod.
Et si ça ne part pas en prod, c'est parce qu'on n'a pas respecté ses prérogatives.
Il y a des deux à mon avis.
Si tu fais partie d'un petit produit,
il va y avoir des checklists, des trucs comme ça
et les gens seront de toute façon très ouverts pour partager les best practices,
par exemple, parce qu'il faut utiliser ça,
est-ce que tu devrais mieux configurer ton système avec la propriété A ou la propriété B,
plutôt que les gens réinventent la roue.
On va leur dire « tu viens, tu veux faire du load balancing, regarde ça,
on lui devrait inventer la roue »
Et ensuite, la partie des produits un peu critiques,
cela, il y a des checklists dans le sens où les SREs,
c'est eux qui sont responsables de leur système à la fin de la journée,
donc c'est eux qui décident de la checklist.
Et une question justement, là-dedans,
donc ça, c'est quand ça marche,
qu'est-ce qui se passe justement quand les SREs ne sont pas respectés ?
Quand les SREs ont pris des décisions,
ont pu prendre des décisions,
c'est pas du blaming que je demande sur un projet en particulier,
mais qu'est-ce qu'ils posent passer dans un cas comme ça
si jamais les décisions prises au sein des SREs ne sont pas bonnes ?
Il y a les autres SREs qui se réunissent pour essayer de faire marcher le projet,
juste toute la tête tombe,
quel va être le genre de pratique à faire si ça n'arrive pas ?
Un post mortem.
Je sais que Lucas adore les post mortems.
Mais ça ne va être qu'un post mortem, il n'y a pas une question.
Non mais après, si le post mortem, il dit, il faut revoir
toute la façon dont je ne sais pas, les reload sont faits,
ça sera fait et c'est tout.
L'importance, la priorité est donnée aux actions du post mortem
ou ça passe un petit peu, enfin,
en termes d'importance, c'est vraiment très très important,
c'est fondamental dans le SRE le post mortem.
Ça dépend de la criticité du truc.
On fait des post mortems pour des petits incidents
parce qu'on a eu chaud et parce qu'il y a eu une panne qui était drôle,
on fait aussi des post mortems quand on a perdu beaucoup d'argent
ou de la réputation.
Et en général,
il y a une sorte de proportionnalité entre l'intensité de la panne
et le niveau du manager qui va aller regarder
quels sont les objectifs dans les mois qui arrivent
pour fixer les problèmes.
Ensuite, c'est une culture d'incident,
on va dire si il y a un truc vraiment grave qui arrive
et que ce n'est pas...
On dirait que c'est juste un coup du sort,
on se dit que ça peut se reproduire.
Donc pour éviter que ça se reproduise,
bien entendu,
il va falloir peut-être déprioriser des features
et dire qu'on ne va pas faire moins de features,
on va faire plus de fixe.
Un outil qui est très puissant pour ça,
donc le SLE s'en rapproche, c'est le error budget
pour dire qu'on a un budget pour les pannes,
alors on l'a cramé pour les 6 mois qui arrivent.
Donc tant pis, on ne va plus mettre de nouvelles features en prod
parce que...
On a cramé le budget.
Voilà, on a cramé le budget.
Mais normalement, on n'arrive jamais dans des extrêmes à ce niveau-là
parce que les EXIP sont déjà matures,
les process sont déjà en place.
Moi, je n'ai pas été témoin, on va dire,
de la mise en place de ce genre de système.
Donc à mon avis, dans une entreprise qui met ça en place,
il y aura forcément ce genre de problème.
Et comment, du coup, le suivi de ce qui est implementé en post-mortem,
enfin, ce qui est discuté en post-mortem et fait ensuite,
est-ce que c'est les équipes qui sont autonomes ?
Est-ce qu'il y a quelqu'un qui est affecté à ça
et qui s'assure que ce qui a été discuté va bien être fixé
ou va bien être implementé pour assurer que ça ne va pas revenir ?
Comment c'est ?
Peu y avoir des deux.
Ensuite, disons que les SRE,
en tout cas dans l'équipe OJT et Google en général,
ils vraiment adorent leur job et ils prennent le truc à cœur.
En se disant, bon, il y a vraiment cette panne qui était grave.
Voilà, donc ils sont un peu auto motivés.
Donc il y a ça qui est bien.
Si jamais on est dans une entreprise avec des gens qui traînent des pieds,
je ne sais pas trop comment faudrait faire,
mais s'il faut qu'il y ait des project managers spécifiques
dédiés à ce genre de trucs,
si jamais l'impact est grave,
bon, ça se justifie financièrement.
Après, il y a un constat global entre le SRE et le DevOps,
c'est que ça décrit les choses quand tout se passe bien.
Même quand ça se passe mal, au final, ça se passe bien.
Les gens sont d'accord, les gens font un post-mortem,
il y a des actions qui sont prises, mais c'est vrai que tu viens de le soulever.
Quand il y a des gens qui traînent des pieds,
quand il y a de la mauvaise volonté, quand il y a des personnes toxiques,
ou quand juste la direction ne s'est pas trop sur quel pied danser,
le modèle, il ne décrit pas comment faut faire,
comment gérer une transformation,
comment gérer n'importe quoi,
avant des situations qui peuvent être interprétées différentes manières.
Et là, c'est un peu compliqué pour nous au quotidien.
Après, je demande, enfin, là, c'est comme ça que je voulais rebondir.
Donc là, c'était la description de Google qui a mis
pas mal de temps quand on voit l'historique de Kandat le début des SRE.
C'est donc qui a eu l'histoire avant d'arriver à ce que ça en est maintenant.
Alors, à quel on voit, dans LinkedIn, même on voit que le SRE est devenu le top job,
donc il y a tout un énorme buzzword là-dessus.
Justement, on essaie de parler de l'implémentation
dans les autres entreprises, c'est-à-dire comment les autres entreprises.
Maintenant, se réapproprient ce terme-là.
Donc là, par exemple, je suis en train de changer d'entreprise,
c'est quelque chose qu'on voit en ce moment,
puisque d'ailleurs, je suis normalement le lead SRE
chez Vente privée actuellement.
Mais là, j'aurais bien aimé justement qu'on parle
de justement ce buzz sur le SRE auprès des autres entreprises.
Et comment vous le voyez et comment, toi peut-être, déjà,
quand tu l'as vu quand t'es arrivé en France,
non, d'autres entreprises, comment t'as perçu ça,
en fait, la première impact et nous, on pourra rebondir.
Bon, moi après, ça, c'est une histoire de terme.
Pour les termes, je suis quelqu'un d'un peu difficile.
Vous pouvez demander aux gens dans mon équipe,
dans le sens où si un truc n'a pas de raison d'avoir un nom,
ça peut s'appeler R ou A.
Ça me fait une belle jambe.
Ensuite, voilà, SRE ou DevOps, pour moi,
est-ce que c'est juste un terme marketing ou pas ?
Je ne peux pas parler au nom de Google
quand je dis des trucs, j'ai l'objet de contenir aussi
les parties secrètes et tout.
Mais la partie, c'est clair que Google,
c'est une entreprise qui fait les choses très, très bien.
Et du coup, tout ce qui est associé à Google,
c'est forcément vu de manière positive.
Ensuite, est-ce qu'on peut juste rebrander DevOps
en disant maintenant, les DevOps sont des SRE ?
Pourquoi pas, à la limite ?
Mais c'est qu'une histoire de nom.
Deux mains, on me met éboueur sur mon contrat de travail.
Si je fais le même travail, je suis payé pareil,
ça ne me dérangera pas.
Voilà.
Là, j'ai l'impression qu'il y a un espèce de SRE-Washing
sur l'admin 6.
C'est qu'en fait, les gens avant ont utilisé DevOps.
DevOps, c'est un lien très fort avec la communication,
la culture, le sharing, etc.
C'est quelque chose qui est plus de l'ordre de la philosophie
que de l'ordre du travail quotidien.
Après, le terme avait été un peu utilisé un peu partout
pour des admin 6.
C'est encore, ça dépendait beaucoup des fois des développeurs.
Enfin, on avait quelque chose qui était assez flou.
J'ai l'impression à l'heure actuelle,
quand je vois l'utilisation de SRE dans les entreprises,
que c'est vraiment du SRE-Washing de l'admin 6.
On n'arrivait pas à faire du DevOps.
On n'avait pas vraiment envie de changer.
On met SRE à la place et puis YOLO, normalement, ça passe.
En final, on fait un peu comme avant et on met juste SRE à la place.
En tout cas, moi, l'espèce d'avis que j'ai quand je vois
l'utilisation de SRE dans les entreprises françaises.
Après, je ne sais pas.
Moi, je suis un peu d'accord.
On est dans un métier qui bouge beaucoup techniquement.
L'architecture et les habitudes et le travail
à lequel ils existaient il y a 8-10 ans n'ont plus rien à voir
ou on très peu à voir avec ce qu'on fait aujourd'hui.
Modulo, l'endroit où on travaille.
Mais dans nos métiers autour de la table, je pense que c'est le cas.
Donc, on est dans un univers qui bouge très vite.
La terminologie doit bouger très vite si on veut rester dans le coup.
Donc, l'administrice, c'est quelque chose qui a toujours existé
et qui existera toujours.
On ne va pas se le cacher.
Et le fait d'apporter cette nouvelle terminologie,
ça dynamise un petit peu le marché.
Ça dynamise les personnes.
Ça les met en valeur.
Ça les...
Toutes les quantités du recrutement.
Et je pense que, également, le DevOps était
beaucoup trop orienté, chéri, une culture.
Et impliquait de trop gros changements, je pense,
et faisait peur au final aux personnes.
Parce que moi-même, dans mon précédent job,
j'ai été recruté en tant que DevOps.
Je ne sais pas, j'avais dû le dire dans un prochain épisode.
Et on ne savait absolument pas ce que c'était le DevOps.
On m'a dit, c'est une carte blanche, on fait un essai.
Il y avait cette ignorance vis-à-vis du DevOps
parce que, justement, ça ratissait extrêmement large.
Alors que le SRE rassure, déjà, parce que c'est Google,
ça vient de Google, donc c'est forcément bien.
Et de deux, ça rassure parce qu'on reste sur de la reliability,
enfin reliability, sur de la confiance, sur du technique.
Et en ce sens-là, c'est peut-être un petit peu un retour,
justement, à l'N-6 où on reste cantoné au sfer technique.
Même si on va parler de changement,
on va parler de méthodes de travail,
de méthodes d'intervention dans les équipes
et de partage entre les équipes techniques,
on reste entre équipes techniques.
Ça oui, donc en fait, en gros, la conclusion de là,
c'est si jamais on le voit SRE et que c'est pas Google qui est à côté,
mais confiance.
Ouais, un petit peu, ouais.
Il y a d'autres boîtes qui sont extrêmement,
enfin, de vraiment de bonnes volontés et qui essaient de faire bien.
Mais en France, aujourd'hui,
on connaît tous un peu l'état du marché
et les entreprises, en tout cas, sur la place parisienne.
Le SRE est extrêmement rare,
le vrai SRE tel qu'il est exécuté par Google.
Je ne sais même pas si j'en ai vu, en fait.
C'est des entreprises où on a entendu parler d'entreprises
qui font vraiment du SRE comme Google
où on prend des softwares à ingénieurs
et on les met sur de l'opérationnel.
Enfin, en tout cas, c'est comme ça que la définition originelle du SRE.
D'ailleurs, c'est assez marrant.
Enfin, Lucas, tu étais SRE chez Google,
maintenant, tu es lead dev dans une entreprise française,
alors qu'il y a des gens qui s'appellent SRE dans cette entreprise-là.
C'est ça que je trouve assez...
Oui, après, ça, c'était un choix personnel aussi de dire, bon,
j'ai fait beaucoup d'astreintes qui s'étaient très stressantes
parce que j'étais dans une équipe assez critique, on va dire.
Et maintenant, j'ai la chance de construire quelque chose depuis zéro
et avant de priver, pour construire quelque chose soi-même depuis zéro,
des bons postes du moment.
Bon, c'est être lead dev, comme ça, on construit un petit logiciel,
un petit produit, on va dire.
Tu fais pousser ton jardin, un petit cultive et ça marche.
On cultive.
Par contre, oui, je suis assez intransigeant avec le développement
parce que, du coup, j'ai toujours derrière ma tête
le système avec le pager prêt à partir,
à se dire, bon, le système,
je vais devoir l'architecturer de telle manière pour que, comme ça,
mes SRE à moi, ils vont m'embrasser en disant, ton système, il est facile.
Et au final, il coûte pas cher à maintenir
parce qu'il est construit de manière résiliente, par exemple.
Et est-ce que, comme conclusion, on pourrait pas dire,
justement, suite à ton expérience,
l'idéal, ça serait de faire tourner les rôles,
c'est d'avoir des SREs qui vont faire du développement,
par exemple, plusieurs mois et puis qui vont revenir faire du SRE
et visèrent ça, pour que tout le monde se comprenne.
Et pour moi, ça, c'est la philosophie des VOPs,
donc pour que les choses marchent bien,
est-ce qu'il ne faut pas juste changer les rôles ?
À Google, il y a ça, il y a un programme qui s'appelle Mission Control,
qui incite justement les software engineers pur et durs
de passer six mois dans une rotation on-call.
Donc leur but, c'est de apprendre le système de telle sorte
qu'ils puissent ensuite faire quelques rotations on-call.
Comme ça, ils ont compris justement
qu'est-ce qui est important pour que le système
fonctionne bien en production,
c'est-à-dire rendre le système observable, par exemple,
rajouter des compteurs ou juste comprendre que non,
la feature que tu viens de développer, on ne va pas la relâtre
en claquant des doigts et ça va prendre deux semaines,
par exemple, ou je ne sais quoi,
en fonction de la gravité du système.
Après, ça n'enlève pas aussi le souci de
quelles sont les produits d'infra,
parce que là, en fait, on parle quand même d'entreprises
qui n'ont aucun problème d'infra.
Enfin, en tout cas, pas moins que les trois quarts,
ou même 90% des entreprises existantes.
Ils investissent beaucoup dans l'infrastructure, on va dire,
parce qu'ils ont compris que c'est un avantage compétitif
dans internet et c'est tout.
Voilà, mais en fait, la philosophie DevOps
a encore, à mon avis, son sens,
même quand on met des SRO au sein des équiles de développement,
pour savoir qu'est-ce qu'on va développer
comme produit sous-chasse,
c'est-à-dire définir les interfaces propres
pour que les SRE au sein des équipes
puissent travailler facilement avec les produits d'infra.
Et je pense que c'est là où le DevOps
peut-être même prendre tout son sens,
c'est-à-dire qu'on a pu enfin,
enfin, on a enfin perdu le « je suis un DevOps »,
mais plus on arrive à être dans une entreprise
qui fonctionne en mode DevOps.
Et je pense que ce sont des SRE et peut-être un des leviers
pour arriver au DevOps infiner,
c'est-à-dire c'est une organisation du travail,
de telle façon, parce que les SRE
soient autonomes dans leurs produits, en fait.
C'était ce qu'on voulait à la base du DevOps,
c'était faire une sorte que les interfaces
soient bien définies.
On peut arriver à des trucs beaucoup plus disruptifs,
mais qu'on ne peut rien avoir,
l'entreprise libérée,
enfin, des habitudes d'organisation de travail qui...
Peut-être qu'il y a pas quelque chose là-dessus.
Ça va être un truc libéré, et un jeu.
Ça va être un truc libéré, ça me...
Peut-être on verra.
Ça fait longtemps qu'on en parle.
Donc voilà, il y a des choses
qui vont encore plus loin que le DevOps
et qui peut-être peuvent être intéressantes.
Super.
On va passer maintenant à un autre sujet.
Alors, pour information,
on a le moment de voir un sujet qui était Observability par Marc,
qui n'est pas là aujourd'hui.
Non, on n'a pas fait des choses ensemble.
Nous, on nous le saluera au passage, Marc.
Voilà.
On n'a rien fait ensemble, moi non plus.
Je n'ai pas une voix au top,
mais on fait avec.
Et maintenant, on avait un sujet.
Donc, c'est un sujet un peu ambineux.
On va essayer quelque chose avec Bartelémy.
Sur les CIA.
Et d'abord, Bart, je vais te poser une question
qui vient toujours du trivial poursuite édition DevOps.
Quel est le rôle du Scrum Master ?
Le Scrum Master doit organiser la vie de l'équipe
et notamment lors de cérémoniaux,
donc qui sont importants.
Il n'est pas d'accord.
C'est fait là.
Oui, en effet, c'est pas le but initial.
Ça, c'est plutôt la comment c'est implémenté.
Comment c'est implémenté ?
Scrum Master, c'est un facilitateur d'organisation d'équipe.
Il veille au respect de la méthodologie Scrum.
Ah, ok.
J'y étais prêt.
Je suis un chien,
mais donc, il concerne la méthodologie Scrum
et donc, il fait attention aux cérémoniaux.
Ok, ok.
Voilà.
Mais c'est donc ça.
Voilà.
Juste ça.
Et tiens, je n'aurais pas posé de questions.
C'est vrai ?
Oui, Victor.
Aller vite, vite fait.
Les principes SaaS et DevOps,
sont-ils complémentaires ?
Alors, principe SaaS déjà,
si je savais ce que c'était, ce serait bien.
SaaS, SaaS, SaaS, SaaS, SaaS, SaaS, SaaS, SaaS.
Ah, SaaS, d'accord, SaaS.
On savait.

On savait que c'était un connu,
genre SaaS ou je ne sais pas quoi.
Non, non, non, c'était anonyme.
Non, non, c'est…
Et là, en fait, c'est une réponse en oui ou non.
Attends, redis-moi la question,
du coup, ce que je vous dis.
Merci.
Les principes SaaS et DevOps,
sont-ils complémentaires ?
Euh…
Mais ça n'a rien à voir.
Enfin, je ne sais pas.
Et bah, je devais en ce cas,
une réponse.
Euh… bah non.
C'était oui.
Ah, merde.
Je n'ai pas plus d'explications.
Mais c'est pas une question bizarre.
Ben oui, je ne sais pas si c'est comme ça.
D'accord.
Alors, donc on va parler maintenant
avec Bart et les Mies CI.
En fait, le but, c'est vraiment
qu'on ait une sorte de débat là-dessus,
mais je vais te laisser Bart…
Si jamais mon téléphone s'amènerait,
mais on va faire sans les notes.
Alors, la CI.
La CI, on voulait parler de CI,
on voulait faire un grand dossier,
faire des limites,
une démonstration technique.
Racconter et…
En podcast.
En podcast.
À la télé.
Mais… mais, mais, mais, mais, mais.
Les choses étant ce qu'elles sont,
on n'a pas eu le temps.
Donc, on vous voit vous parler de CI
et faire intervenir les gens autour de la table
histoire de…
histoire que ce soit un petit peu plus dynamique.
Cela dit,
il est important, je pense,
de rappeler certains axiomes de base
que sont la CI et ce que doit réaliser la CI
avant qu'on aille plus loin.
Donc, je crois qu'on avait défini 3 ou 4 points.
Alors, en fait, d'abord, CI, donc…
Integration continue.
Integration continue.
Est-ce que c'est que l'intégration
et qu'elle est ensuite…

Et donc, en fait,
le rôle de la CI,
c'est à la fois le test et le build.
Et après, on va rajouter à ça souvent de la CD,
continuous delivery,
pour tout ce qui est deploy,
toute la partie deploy.
Donc, en fait, on a vraiment 2 parties très fortes
dans la CI qui sont le test et le build.
Et le packaging.
Build packaging.
Oui, c'est vrai qu'on peut rajouter cette phase de packaging
qu'on peut mettre dans le build ou dans l'un an.
En fait, on voulait aussi parler des outils.
Quand on parle CI,
90% des fois, on va parler de Jenkins.
Donc, on aurait bien aimé avoir…
Est-ce que vous avez déjà touché à Jenkins
et quels ont les secrets que vous expère avec ?
Je dis malheureusement oui ou pas ?
Oui, bien sûr.
C'est ça le but, justement.
Quels ont l'expérience là-dessus ?
En quelques mots, est-ce que ça dévoile ?
Oui, déjà touché à Jenkins, principalement en tant qu'utilisateur,
mais du coup, l'expérience utilisateur, pour moi,
n'est pas géniale après.
Qu'est-ce qui t'emmette le plus ?
Vraiment, Jenkins, même, sans parler des outils, c'est genre…
La façon de configurer les builds dans Jenkins,
de faire des scripts groovy,
alors qu'on aime ou qu'on n'aime pas le groovy.
Alors, pour savoir que les scripts groovy,
c'est quelque chose qu'on utilise nous aujourd'hui au quotidien,
on travaille ensemble avec Victor.
J'ai précédemment utilisé Jenkins,
sans l'utiliser de scripts groovy,
et on utilisait l'interface web
pour éditer nos jobs.
Donc, le groovy n'est pas obligatoire avec.
C'est vrai.
Ok, bien moi, Jenkins, on va dire, j'ai deux, trois expériences simples avec.
D'un point de vue utilisateur,
je trouve assez horrible la partie de configuration avec des clics.
J'ai entendu dire qu'il y a des Jenkins files maintenant,
qui sont peut-être un peu mieux,
mais je n'ai pas encore testé.
Et la façon dont on fait les jobs,
pour moi, c'est juste une sorte de cron job,
qui a aussi un historique avec un peu d'interface,
peut-être un peu trop d'interface graphique,
ce qui m'intéresse, c'est juste de faire tourner un job en permanence.
Et la façon dont on les administre,
nous, on a mis de toute façon,
le système va faire un guide check-out du repo,
on met les scripts dans le repo,
du coup, le Jenkins s'occupe de faire SH
vers le script qu'il a check-out lui-même,
c'est ce qui nous permet d'utiliser
GitLab qui a sa propre signaille,
on va peut-être en parler après,
ce n'est pas le sujet actuel,
mais et l'Emergerie Quest pour configurer le Jenkins,
à 80%, on va dire.
Je pense qu'on a fait le tour des points qu'on avait notés,
déjà, il y a une chose à remarquer, c'est qu'autour la table,
il y a quand même 100% de personnes
qu'on bossait avec Jenkins.
Et c'est le principal point fort de Jenkins,
c'est quand même qu'il est archi, archi connu,
archi déployé partout, c'est quand même quelque chose d'assez systématique aujourd'hui dans la IT.
Et oui, et son histoire en plus est venue au fait que
il était concomitant un peu au bon endroit au bon moment,
c'est-à-dire qu'il servait beaucoup dans Maven au début,
son rôle était d'être lié à du Java,
écrit en Java lié à du Java comme les Java eus à faire.
Et en fait, on avait justement ce moment
où on aimait, on a commencé à faire la CI,
2009 faire justement travailler là-dessus,
sur ce qu'on appelait les plateformes d'intégration continu, les PIC.
Et justement, on travaillait beaucoup de logiciels,
l'entreprise se faisait encore en Java.
Et on avait Jenkins qui était là et qui s'intégrait très bien
avec le reste de l'écosystème.
Et en fait, on l'a conservé après parce que Jenkins a su un peu évoluer,
on laissant l'accès aux freestyles jobs
pour réussir à faire lancer du Bache en fait.
Et donc là après, les gens ont fait n'importe quoi comme ils savent faire en bâcherie.
Et donc voilà, mais je pense que, oui,
le point par contre qui est revenu, c'est la configuration.
Et là où on voulait rebondir, c'est un peu dans l'histoire de la CI,
c'est qu'on a remarqué qu'il y avait des problèmes de configuration.
Ce qui est venu très vite après comme autre type de runner,
ça a été les runner type Travis par exemple,
qui était d'avoir au sein de son projet un fichier descriptif
de comment lancer sa CI.
Et dans ces cas là, on a parlé tout à l'heure des Merge request,
c'était même si dans une Merge request,
il y avait une évolution de la logique,
voire même le script changeait de nom.
Mais en fait, on n'avait pas de problème du moment que le fichier au centre s'appelait toujours pareil.
On n'avait pas de problème avec ça.
Donc je ne sais pas par contre là si vous avez des connaissances en Travis,
si vous l'avez utilisé.
Non pas vraiment.
Non plus, désolé.
Voilà, désolé.
Désolé, pas désolé.
Donc encore aujourd'hui, c'est quelque chose qui n'est pas forcément hyper commun.
Cela dit, tout à l'heure, tu as évoqué les Jenkins files.
Donc c'est un peu le même concept.
C'est-à-dire qu'on est plus sur une configuration qui va être décentralisée,
qui va être collocalisée du code.
Donc la configuration du job Jenkins et dans Jenkins,
mon code est dans Git ou dans SVN à l'époque.
Mais on va fusionner le lifecycle avec son code
et cela va notamment permettre justement de gérer tous les use cases de feature branching,
tous les use cases de travailler sur des branches,
des tags, de travailler avec revenir à l'état de la CIA telle qu'il était,
avec l'état du code il y a un an.
Plein de choses de pratiques et qui étaient difficiles d'accès avec Jenkins.
En plus d'avoir du software à de service telle que le propose Travis.
Oui en plus c'est vrai que là en fait,
comme tout à l'heure je disais Jenkins s'est apparu en même temps que Java,
Travis est apparu en même temps que GitHub en fait et l'émergence de GitHub très forte
dans les années 2012-2013 à peu près dans ces années là.
On a vu vraiment l'émergence de GitHub avec un modèle Freemium Trifer
qui est de pouvoir faire des projets open source gratuits.
Et bien il fallait donc d'avoir des CIA gratuites qui allait avec aussi en même temps.
C'était bien beau d'avoir son logiciel gratuitement sur GitHub en open source
et jamais il fallait monter soi-même son Jenkins.
Ça devenait compliqué et en fait on n'a pas eu d'offres Jenkins à de services très fortes
avec qui sont apparus et on avait Travis.
Après moi pour avoir utilisé énormément Travis,
le problème qui a apparu très vite c'est qu'on était extrêmement dépendant
de la plateforme Travis, c'est à dire qu'on était dépendant des logiciels installés
dans le runner, on avait tout ce problème en fait de la reproductabilité.
C'est à dire c'était reproductible au sein de Travis, pas vraiment ailleurs.
On avait en plus même du mal à savoir si jamais Travis faisait mettre à jour ces boxes,
qu'est-ce qui se passait ?
Alors il faut quand même remettre les choses dans le contexte,
tu parles des choses telles qu'elles étaient avant,
mais Travis a évolué telles qu'il existe aujourd'hui
et aujourd'hui on fait du docker dans Travis.
Voilà mais en fait il a surtout été modifié pour avoir un peu suivi à ça
sous l'impulsion d'autres CIA comme drone CIA qui a apparu
ou breaker par exemple.
Je sais pas comment on prononce breaker.
Breaker, breaker.
Breaker.
On dirait que c'est... on mettra ça sur le compte de la voie cassée.
Et donc en fait ça, ces CIA là pour le coup mettaient en place un système de box.
Alors soit c'était des images qu'on pourrait avoir type vagante
et donc on pouvait soit utiliser les boxes de base versionnées,
soit créer même sa propre box et dire
« Ma CIA va tourner dans tel environnement que j'ai moi-même contrôlé »
ou alors partir à partir de conteneurs type docker
et donc de se dire, bah voilà.
En fait ma CIA c'est partir de telle image docker et faire telle action dessus.
Et donc comme ça on contrôle l'environnement et ce qu'on va y mettre, ce qu'on va y faire dedans.
Et donc après Travis a évolué pour arriver,
pour reprendre un peu en main ça et pas laisser partir tout le monde,
vers ce type d'environnement.
Donc c'est pour ça que maintenant dans Travis on peut faire,
on peut partir d'image et en fait on a un peu plus de contrôle en tout cas de ce qu'il y a dedans.
L'environnement d'exécution du test.
Voilà, on peut faire du docker à in docker, enfin bref, on peut faire plein de choses.
Et on peut même préparer les services qui vont tourner au sein de notre CIA.
Cela dit Travis a quand même un inconvénient,
c'est qu'on est justement en software à de services
et que quand il s'agit par exemple de générer des livrables
et de les uploader dans son environnement privé,
sur son réseau, on est bien invité.
Donc je ne sais pas ce que propose Travis,
si il propose une off commerciale qui permet de gérer des tunnels,
gérer ce genre de choses-là, mais de toute façon on est sur quelque chose
qui est plus complexe que si on faisait renait en local une CIA chez nous
qui avait tous les accès en privé.
C'est toujours aussi le problème même de savoir l'évolution de cette plateforme-là,
on est quand même dans quelque chose où on a, c'est quand même une énorme black box.
La confiance, je veux dire.
Voilà, la confiance et la reproductibilité.
Un problème qu'on a très souvent quand on fait du Travis,
c'est que c'est facile de faire du LinkedIn sur le fichier qu'on va créer.
C'est très difficile par contre de le renait à l'avant,
de savoir la prédictabilité de ce qui va vraiment se passer.
Mais à un point après, donc là, c'est dommage,
on n'a pas de personnes qui a fait du Travis ou du drone, etc.
Un point qui a été arrivé très vite, c'est la notion de pipeline.
C'est à dire qu'en fait, on va vouloir faire des actions
et on va vouloir en refaire même au bout d'un moment plusieurs.
C'est à dire on va vouloir tester, faire des tests en parallèle.
Si les tests sont OK, passer à une autre étape,
pour après arriver à un build final en fonction d'état.
Et est apparu justement la barre, c'est toi qui le connais déjà un peu plus.
Il y a un truc qui s'appelle concourse.
Donc ça veut dire full, je crois, en anglais, un truc comme ça.
Il qu'est France les yeux.
Non, il y pas sûr.
C'est pas ça ? Allez vas-y, corrige-moi.
Donc il y a un outil qui s'appelle concourse, sur concourse d'Otario.
C'est un outil qui est essentiellement orienté autour de pipeline.
Alors le pipeline, c'est quelque chose qui n'est pas native dans les CIA
qui met qui a apparu et qui a été greffé.
Travis, je suis pas certain, je connais pas.
Si Travis a une notion maintenant de pipeline.
D'accord. Jenkins a une nouvelle notion de pipeline dans ses dernières versions.
Avant c'était sous forme de plugin, maintenant ça a été intégré dans la branche principale.
Mais là c'est un outil qui a été développé uniquement pour gérer des pipelines.
Donc on a deux types de... c'est simple, c'est assez visuel, vous pouvez les voir sur le site.
Il y a deux types d'item, c'est les tasks et les ressources.
Les ressources fournissant des... ça peut être une ressource de type guide,
ça peut être une ressource de type... peu importe des fichiers
ou des actions sur une interface REST,
il y a des plugins officiels d'autres qui vont être communautaires.
Et à côté de ça, de ces ressources, on va avoir des tâches qui vont définir des actions
qui va être, je sais pas, par exemple sur un hippo-guit, on va pouler le ripot
ou alors sur le déclenchement d'un nouveau tag,
on va déclencher une action de type BASH ou de type...
ou pouler une image ou pousser une image de Docker.
On a des outputs, des outputs.
Et vraiment, c'est uniquement... c'est très streamliné
et on est uniquement sur des pipelines.
Donc de la même manière qu'on avait sur Travis et qu'on a aujourd'hui un peu partout,
c'est défini d'en des fichiers collocalisés dans le ripot
et c'est exécutable à peu près partout
parce qu'on essaye d'avoir la description entière de son pipeline dans ce fichier-là.
Là, ce qu'on voulait montrer en ce moment-là,
donc là, on en a à peu près à cet état-là.
L'état de l'art à l'heure actuelle de la CIA,
c'est vraiment cette notion de pipeline et ces actions-là
qui peuvent être après plus ou moins implémentées dans les autres solutions
mais on voulait vraiment montrer cette évolution des produits de CIA.
Et enfin, un produit dont on n'a pas parlé,
enfin un peu lucal à évoquer, c'est le produit GitLab
qui est un peu...
dans le cas de la CIA, un peu l'ovenie, en fait, là-dedans.
Puisqu'en fait, c'est une solution donc GitLab-CIAI
qui est intégrée au sein d'un projet qui est beaucoup, beaucoup, beaucoup plus large.
Alors justement, c'est un produit tellement spécial que je voulais...
enfin, j'ai, je vais les récupérer des dates un peu clés
pour qu'on puisse voir d'où est-ce qui vient et où est-ce qui va
parce que c'est surtout ça qui est important.
Petite anecdote, enfin GitLab-CIAI,
on va le différencier de GitLab parce qu'aujourd'hui, on va parler de GitLab.
Au gens qui connaissent un petit peu Git et GitLab,
on pense que les GitLab c'est uniquement un clone de Git Hub
or aujourd'hui, ça fait quand même beaucoup plus,
ça va beaucoup plus loin.
Justement, et je vais y revenir en fait.
Donc, à la base, vraiment GitLab, donc c'est en 2011, les premiers comites.
Et donc, oui, ça se veut étant,
ça se veut être un clone de GitLab privé Open Source en Ruby.
Très vite, en 2012, on commence déjà à avoir une première offrance ASS.
Donc, c'est-à-dire, on est à la fois sur un projet Open Source
et à la fois sur la même chose ouvert en software as a service.
On a en 2015 l'intégration d'une CIA, donc c'est dans GitLab 8.
Donc, c'est 2015, c'est ça, intégration donc de GitLab CIAI.
Donc, on a une CIAI qui est basique, mais qui marche.
Pareil, qui fait profit de toutes les dernières évolutions en termes CIAI,
donc la colocalisation des définitions de jobs.
Et en 2016, donc à la suite d'une levée de fonds de 20 millions de dollars,
on a ce qu'ils appellent le master plan qui arrive, donc 2016.
La philosophie, en fait, de ce master plan-là,
c'est de faire en sorte que GitLab devienne le centre de la co-valaboration
entre tous dans les métiers du numérique.
Et ça, de la manière la plus effective et avec les meilleurs résultats le plus vite.
Donc, je suis en train de traduire en direct la phrase,
donc c'est un peu décousu.
Le point, en fait, essentiel, c'est d'arriver de l'idée jusqu'à la mise en production
et même après la meilleure ration continue le plus vite.
Ce qu'ils ont défini, ils ont défini en fait plusieurs étapes.
Tout à l'heure, on a parlé dans une CIAI du test et du build,
et après du deploy pour la CIAI, dans le cadre de GitLab, ils vont encore plus loin.
C'est-à-dire qu'ils veulent répondre à tous les besoins allants de l'idée
en passant par les tickets, en la définition du plan, dans l'écriture du code,
dans la création des commits, dans les tests, dans la review,
dans toute la phase de mise en pré-production, la masse de mise en production
et même sur les feedback utilisateurs.
C'est surtout un écosystème, en fait.
Exactement. C'est vraiment le but étant d'arriver à adresser tous ces points-là
de manière plus ou moins pluggable.
Tous ces besoins d'un projet numérique moderne.
C'est vraiment ça, en fait, l'idée GitLab.
Et même, d'ailleurs, ils sont arrivés il n'y a pas longtemps
avec ce qu'ils appellent l'auto-devops.
C'est encore une fonctionnalité beta, mais qui est intégrée dans la version 10.
L'auto-devops, en fait, en gros, c'est comment arriver à aller vite au test
quand on a un logiciel qui est plutôt assez simple.
En fait, on a du build qui est fait via Docker, si jamais il y a un Dockerfag
ou via ce qu'ils appellent Herocwish.
Donc, en fait, ça utilise un peu les mêmes fonctionnements qu'HeroCoo
et les boxes Herocoo, ça détecte le langage.
Si jamais c'est du PHP, ça met du PHP, du PHP, FPM, etc.
et ça fait les manifestes Kubernetes qui vont bien.
Si jamais c'est du .NET, ça va le compiler
et après, ça va le mettre dans ce qui va bien aussi.
On a des autotests.
En fonction d'une langage qui a été détectée, on va faire les tests qui vont avec.
Bien sûr, toujours dans la popularité du langage, dans l'écosystème,
dans les habitudes, ça peut être, après, bien sûr, pluggable.
On a même du code quality avec code climate et on a même une review.
C'est l'étape de review, ce n'est pas l'étape qu'on pourrait dire habituelle
qui est juste du commentaire de code.
Là, quand il parle de review, c'est vraiment, dans le sens,
pouvoir faire tester à des gens du métier.
On code une fonctionnalité.
Ça spawne un environnement de test qui est isoproduction
et après, on va pouvoir montrer cet environnement-là à une personne du métier.
On aura directement, quand on fait une maire de request,
la possibilité de pouvoir faire tester instantanément la fonctionnalité au métier.
C'est ça ce qu'ils appellent review.
Ça, c'est automatique, entre une image automatique, même avec Kubernetes.
Après, même, on peut aller jusqu'à l'autodploie si jamais on a un environnement cube
et même jusqu'à l'automonitoring, si jamais on a bien configuré les premiers TUs qui ont bien.
On arrive même quand il déploie l'application à faire les métriques.
Et tout ça, toujours au sein du même dashboard.
Il y a quand même une interface bien chiadée.
Alors, je n'ai pas pu l'utiliser entièrement, cette auto DevOps-là,
mais en tout cas, le but, en pensant, c'est encore une fonctionnalité bêta.
Le but, c'est vraiment d'arriver à avoir tout au sein du même projet GitHub.
Donc, voilà en fait l'expérience que vous avez là-dessus.
Pour le coup, GitHub, je vais y arriver.
Et beaucoup plus utiliser peut-être que tous les logiciels un peu obscurs
quand on en parlait tout à l'heure.
Donc, l'expérience GitHub.
J'ai déjà utilisé GitHub, mais pas du tout la partie CI, donc je ne pourrais pas qu'il y a d'un peu d'en parler.
Ce qui est dommage, parce que c'est un peu le thème des...
Et justement, pourquoi peut-être pas la partie CI ?
C'est justement important aussi de savoir pourquoi...
Tout simplement parce que dans les occurrence de l'entreprise,
qu'est-ce que je travaille actuellement, on a déjà des outils de CI,
Genkins notamment.
Et voilà, on n'a pas accès à cette fonctionnalité de GitHub.
Aussi parce que je pense que la version de GitHub qu'on a,
nous n'y donnent pas accès.
Alors, pour dire non, il y a accès.
Ah, j'y ai accès, ok.
Moi peut-être.
Pour raison, je le sais très bien.
D'accord.
Je ne dirais pas pourquoi, mais je le pense pas.
En tout cas, je n'en ai jamais testé.
Cela, c'est sûr.
Cela dit, on est un peu sur le même modèle que on disait lors de la présentation SRE versus DevOps.
On a un outil qui est aujourd'hui en place,
qui est proposé par une équipe et qui est maintenue par cette équipe-là.
Voilà, on l'utilise sur étagère.
On le prend et c'est comme cela qu'on fonctionne.
Donc, rien ne nous empêche de le challenger.
Mais aujourd'hui, pour les équipes de développement qui existent,
leur métier, c'est de faire du développement.
Cela ne va pas être de gérer leur propre CI et chacun face.
Donc, on est dans cette orientation-là.
On a un outil, on l'utilise.
Je pense que c'est valable comme philosophie.
Toi, lequel expérience ?
J'aime assez bien un kit-lab.
Après, je n'utilise pas le système de pipeline un peu compliqué.
Parce que, là, c'est plutôt mon MacAscat, on va dire développeur,
qui me dit, au final, toutes ces pipelines de six machins à eu lieu,
tu déclenches ce bidule et si bidule fait truc avant 36 secondes, tu fais machin.
Pour moi, tout ça, c'est un langage de programmation au final.
C'est juste qu'on ne profite pas de tout ce qu'on a dans un vrai langage de programmation.
Quand on fait, on va dire, ce qu'on appelle du YAML OPS,
on va, entre guillemets, coder ces pipelines dans du YAML.
C'est très bien, c'est déclaratif, YAML.
Mais passer le linter très simple, dire est-ce que c'est du YAML valide ou pas,
on ne peut pas faire grand chose, on ne peut pas générer de la doc automatique.
Quand je fais du code, quelle que soit le langage de programmation.
En général, il y a un minimum de, bon, j'appelle mon truc qui génère de la doc.
J'ai un linter, je peux mettre des tests unitaires de manière assez simple,
pour dire, bon, au final, comment j'organise mes step d'automatisation.
Le fait de pouvoir dire, ce truc-là, il se passe automatiquement dans un docker,
c'est ce que j'espère, l'infra peut me donner déjà.
Donc, il n'y a pas de raison que GeekLab soit le seul système qui a accès
à démarrer des conteneurs sur le Kubernetes ou des trucs comme ça.
J'aurais tendance, moi, à moins utiliser, en tout cas,
à moins investir de mon temps de dev pour construire ces pipeline.
Et plutôt, de me dire, bon, on va peut-être réinventer un peu la roue,
mais ce n'est pas des trucs qui vont coûter cher à réinventer,
genre, en une demi-journée, on peut faire un truc,
en une journée, on peut faire un truc.
Et un des gros problèmes que j'ai avec GeekLab, c'est qu'il n'est pas du tout pensé MonoRipo.
Et moi, j'aime beaucoup le MonoRipo, parce qu'on peut faire des comites
sur toute la code base en même temps et voir si on casse quelque chose
de manière assez atomique.
On peut faire des rollbacks atomiques sur plein de trucs.
Et on n'a pas besoin de se poser des questions de versioning de package
qu'on est obligés de se poser en MonoRipo.
Là, c'est le Googleur qui parle.
Il y a des choses, quand même, dans le MonoRipo qui sont assez disputables.
On sait pas le sujet d'aujourd'hui, on pourra avoir un...
On va pouvoir faire.
Je sais que j'ai un gros déballage aussi.
C'est peut-être en fait le l'ops en nous qui...
Oui, ça dépend des profils, en fait, des affinités.
C'est vrai que le fait de se mettre d'accord sur une interface
qui va être justement ce yaml là et de l'avoir en commun
pour tous les utilisateurs de l'outil et pas d'avoir ce petit pipeline là
pour le projet x et y, puis un autre petit pipeline là pour le projet...
Enfin, la force de l'unité et la force du standard, elle est quand même relativement puissante,
même si ça nous fait perdre la flexibilité d'un vrai langage de programmation.
Je pense aussi que le problème qu'on a, c'est que GitLab n'est pas un standard.
C'est aussi ça le problème qui a, c'est que faire tourner et écrire le yaml oui,
ce que disait Lucas, après, dès qu'on arrive sur la prime de oui,
du LinkedIn, on sait s'il y a même les valides.
Et après, c'est en fait qui fait l'assi-high de l'assi-high.
Et c'est ça, je pense, en fait, l'énorme problème qu'on a à l'heure actuelle,
c'est qu'on n'a même pas quelque chose où on se dit cet outil-là est très bien pour de l'assi-high,
mais il est aussi bien pour mon poste de dev.
C'est-à-dire qu'on a un outil...
Et d'ailleurs, à l'heure actuelle, l'outil encore très utilisé pour faire ce système de pipeline
et de création de X-step, c'est McFile.
Et je pense que c'est...
Pour ceux qui me connaissent, ils savent que j'ai une haine viscérale de McFile
parce que pour plein de raisons, on prend encore à discuter.
Mais à l'heure actuelle, en fait, l'outil un peu standard qui est en même temps du code
parce qu'on peut faire des bout de shell, script, des trucs pas interdits,
même à l'intérieur, même utiliser des générateurs de McFile, il y a plein de choses.
Alors actuelle, en fait, le standard qu'on a, c'est McFile.
C'est, à mon avis, la chose la plus...
qui peut-être a changé, en fait, l'un de moi.
Si jamais je vois demain une évolution dans ce qui serait possible,
je ramien que demain apparaissent un standard, mais vraiment, enfin, un standard.
Au moins un outil à peu près standardisé qui peut tourner sur n'importe quel CI
qu'on soit sur Travis, GitLab, drone, or whatever,
et qui arrive à standardiser ce processus de création
et qui soit auditable, aussi bien sûr en ma machine de dev que sur la CI.
Il est pas besoin de faire un pouce dégueulasse et de faire des amènes dans Git
parce qu'on s'est planté...
Il y a un nouveau challenge pour la payeCube.
Tout le temps que tu me te recordes, c'est pour un mot magique qui est arrivé.
Maintenant, c'est Qverditis.
Non, mais pour le coup, tu disais la portabilité, faire exécuter ça en local,
ou en remote, concours, je ne veux pas prêcher pour mon église,
mais concours permet de faire ce genre de choses-là
et de tester son fichier de la même manière qui serait exécutée en remote.
Ah voilà, donc c'était encore la dernière évolution.
C'est un concours, peut-être un néo-concours,
et il y a à la fois la notion de pipeline et de répétabilité.
Donc voilà, on arrive déjà à une petite heure là-dessus.
Donc, on va arrêter maintenant.
On va vous retrouver une prochaine fois, sans doute, pour des heures série
ou pour le même format.
On espère même encore avoir de nouveaux intervenants.
Donc, Lucay, qui nous a rejoint là,
pourra revenir si jamais il a encore envie de parler de mon sujet.
De Monoripo et de Askel.
Du Askel, on peut faire venir des gens.
Oui, on avait aucun problème.
Il y avait de gestion de dépendance.
Je sais que tu as un...
Oui, j'ai un petit outil de gestion de dépendance en Askel
qui résout pas mal les problèmes dont j'ai parlé.
Alors, ça, c'est moi qui prêche pour ma propre paroisse.
Avec un vrai langage de programmation,
on va avoir un langage de programmation futuriste
pour vérifier plein d'invariants.
La finalité, c'est que si jamais on décrit une infrastructure
qui n'est pas valide, par exemple,
tu me demandes de lancer un script,
mais tu m'as pas dit comment on installe les binaires dans le script,
ça compile pas tout simplement.
C'est magique.
Donc, si jamais on mettra peut-être le lien,
déjà, redonne le nom du...
Deptrak D E P T R A C K
et sur GitHub,
et vous cherchez mon nom, mon prénom et vous trouverez.
Parfait.
Super.
Donc, merci à vous d'avoir écouté ce nouveau numéro de DevOps
et puis, on se retrouve une prochaine fois,
même lieu, même endroit.
Eh bien, à la prochaine.
Salut.
Au revoir.
Merci pour l'invitation. Au revoir.