Transcription

• Speaker #0

  Bonjour et bienvenue dans Nom d'un Pipeline, le podcast destiné à tous ceux qui sont passionnés par le monde du développement, du CI-CD et du DevOps. A chaque épisode, nous allons plonger au cœur des mécanismes et subtilités des processus de développement qui façonnent notre quotidien technique. Nous allons décrypter, partager et explorer tout ce qui a trait à l'intégration et à la livraison continue. Je suis Julien Donjou, CEO de Mergify, et avec des invités experts, des visionnaires et des professionnels du terrain, je serai votre guide dans cette aventure. Que vous soyez un spécialiste cherchant à approfondir ses connaissances ou simplement que de comprendre les coulisses de ce monde fascinant, vous êtes au bon endroit. Alors, mettez votre CI en pause, assurez-vous de ne pas être en plein déploiement et préparez-vous pour ce nouvel épisode de Nom d'un Pipeline. Eh bien, bonjour et bienvenue à tous sur ce nouvel épisode de Nom d'un Pipeline où on va encore parler de CI-CD aujourd'hui avec notre nouveau invité, Stéphane. Salut Stéphane !

• Speaker #1

  Bonjour Julien.

• Speaker #0

  On ne se connaît pas encore beaucoup, on a un petit peu discuté avant rapidement et tout, mais c'est vrai que des fois je connais les gens depuis plus longtemps et toi non, tout nouveau. Je suis content justement de te connaître et peut-être qu'on va commencer par ça. Est-ce que tu veux te présenter et nous dire un peu qui tu es, ce que tu as fait dans la vie ?

• Speaker #1

  Effectivement, j'ai fait un parcours assez classique d'école d'ingénieur, les mines de Douai à l'époque, il y a une vingtaine d'années. Et puis ça faisait très longtemps que je voulais être développeur, ça faisait dix ans que je codais chez moi. Et donc après j'ai fait un certain nombre d'éditeurs, je n'ai fait que des éditeurs de logiciels, toujours dans un contexte plutôt business, B2B. Donc dans les RH, dans la gestion des achats, ce genre de choses. Et puis j'ai progressé, au bout d'une dizaine d'années, je suis passé sur la partie management. Et là, ça m'a permis, je suis notamment rentré chez Talonsoft, qui est une société qui a été intégrée au sein de Cégid il y a quelques années. Et après, j'ai fait un projet très intéressant au sein de Cégidim. Et il y a maintenant... un peu moins de 8 ans et sur lequel j'ai rencontré mon co-auteur, enfin celui qui est devenu mon co-auteur il y a 2-3 ans, Sylvain Assemat, qui m'a rejoint d'ailleurs en tant que CPO au sein de ma société actuelle. Et là actuellement, je suis CTO depuis 2 ans, je suis dans la société depuis 5 ans et je m'occupe des équipes R&D et des équipes infra pour notre soft. l'ensemble de nos solutions.

• Speaker #0

  Tu as dit co-auteur, du coup, tu es auteur.

• Speaker #1

  Brièvement. Oui, tout à fait. C'était un sujet qu'on a voulu traiter un peu avant. Quand je suis arrivé dans ma société, je me suis rendu compte qu'il y avait beaucoup de choses techniques qui n'étaient pas toujours bien expliquées aux CEOs. J'avais du mal à présenter en profondeur avec des schémas. de bien comprendre pourquoi chaque élément était logiquement relié au précédent. Des trucs un peu comme je donne sur cet exemple-là, mais pourquoi mettre du chaos engineering ? C'est vrai que c'est quelqu'un qui est CEO et qui ne connaît pas forcément la technique, qui ne comprend pas forcément l'enchaînement de ce que ça permet de faire ou de ce que ça permet de ne pas faire. Donc en fait, on avait fait tout un diagramme et puis au fur et à mesure des discussions, ça s'est transformé en un bouquin. Je ne suis même pas su s'arrêter parce qu'au départ c'était 300 pages.

• Speaker #0

  C'est un pavé du coup.

• Speaker #1

  700 pages, c'est un vrai pavé. C'est quoi le titre ?

• Speaker #0

  Un peu de promo quand même. Quel est le titre du livre ?

• Speaker #1

  Un peu de promo, oui. Le titre s'appelle Les clés d'un projet ciel sas durable Durable, pas forcément au sens écologique du terme, mais au sens qui va durer dans le temps, qu'on ne va pas devoir refaire tous les deux ans. Le sous-titre est le plus intéressant, c'est Aligner l'architecture, l'usine logicielle et l'organisation L'usine logicielle, c'est quelque chose qui, depuis très longtemps, m'intéresse. Pour mon premier cours que j'ai donné à l'école des mines de Douai, trois ans après que je suis sorti, c'était sur l'usine logicielle, ça commençait à peine.

• Speaker #0

  Voilà pourquoi je suis en train de faire un programme en ficelle. C'est assez rare de trouver des gens qui... prennent le temps de faire ça.

• Speaker #1

  Tu l'as écrit ?

• Speaker #0

  Le tout premier a 10 ans, en 2014, et le dernier est sorti, je crois, en 2017. Et celui de 2014 est ressorti en 2019, pour avoir tout l'historique. Donc, j'ai réédité chez un éditeur. Donc, je vais rester à longtemps. J'ai arrêté depuis. Ça prend beaucoup de temps.

• Speaker #1

  Python, ça prend beaucoup de temps.

• Speaker #0

  Moi, je ne faisais pas 700 pages. Je pense qu'il y en avait 200 ou quelques. C'est déjà bien, 200 ou 700 pages. Je pense que c'est une bonne lecture de vacances. C'est vrai, 350 chacun.

• Speaker #1

  On était deux, donc ça va.

• Speaker #0

  Ok, super. Et du coup, c'est quoi ton scope aujourd'hui chez Asis ? Alors, ça va de où à où ? En CTO, c'est large.

• Speaker #1

  Oui, tout à fait. Disons qu'il y a... On a trois produits principaux. Et donc, je m'occupe de... Ils ont chacune une à trois équipes de développement. Donc, on est basé en feature team, c'est classique. Parfois, un peu des plateformes team, quand il y a des choses un peu techniques. Donc, ça doit faire à peu près six équipes. On doit être une trentaine. Et après, il y a une partie plutôt ops, qui est composée à la fois de gens qui sont, j'appelle ça des admins sys-sass. c'est pas forcément très très mais on devait faire la distinction avec nos admin 6 plutôt sur le on-premise et les sre qui sont plutôt classiques d'ailleurs à ce propos pour expliquer le terme admin 6 ça on cherchait un peu la distinction quand je explique la distinction je dis souvent que les gens qui sont admin 6 sur l'on-prem chez nous sont comme des électriciens en fait qui travaillent sur 220 volts qui sont capables de réparer une maison donc en l'occurrence le on-premise chez le client et nos on-premise nos admins SASS en fait sont plutôt des électriciens qui interviennent sur du 20 000 volts et quand ils font sauter les plombs en fait ça fait sauter tout le patelin c'est un petit peu ça le niveau de respect en termes de métier ils font quand même la vie d'une admin 6 mais on dit pas des vases maintenant ouais alors en fait si si en fait On distingue parce qu'il y a encore beaucoup d'opérations. On est sur un monolithe qui a évolué vers les microservices. Il y a toute la partie nouvelle qui a beaucoup d'automatisation. Et puis après, on a encore des vieux middleware qu'il faut parfois gérer manuellement. Et donc, les SRE sont plutôt orientés aux automatisations et les ADM6 sont la dénomination qu'on entendait. Donc,

• Speaker #0

  tu travailles encore un peu à l'ancienne, tu veux dire, sur certains aspects de par l'existant.

• Speaker #1

  ils font parfois des batchs mais ils ne font pas de terraform pas d'antibold, ce genre de choses alors que les SRE sont beaucoup branchés sur la partie de la science code et on a aussi également un ingénieur logiciel qui travaille sur un produit qu'on appelle Castle en interne qui fait la colle avec l'ensemble des produits nous permettant d'avoir une espèce de tour de contrôle pour piloter et avoir orchestré l'ensemble des outils sur lesquels on intervient. Notre particularité, c'est au sein d'Assis, mais qui est assez classique chez des éditeurs de logiciels, c'est qu'on a beaucoup de tenants. On a plus de 1000, donc ça fait tout de suite beaucoup de complexité. On ne peut pas la gérer. C'est difficile à... J'explique souvent qu'on ne peut pas se baser comme master data management sur... sur les clés de configuration qui sont mises dans un outil. On n'a pas encore du Kubernetes, mais si on avait du Kubernetes, on aurait du Helm, puis on aurait encore d'autres choses sur l'observabilité, etc. Donc, on a fait le choix de d'abord poser les choses dans un outil web collaboratif pour savoir le patrimoine de toutes les applications, savoir où sont les backups,

• Speaker #0

  où sont les tests de normes,

• Speaker #1

  et les utiliser à travers cette plateforme web. En fait, la société est née en 1987 et il y a eu un rachat de code source d'une application qui était développée à Nantes. Mais en gros, on a du code de 1990 et on voit parfois encore du code source qui a parfois encore 20 ans qui marche. Et en fait, la stratégie qu'on a mis en place, c'est de... C'est ce que j'ai dit, mais on avait voulu tout refaire. Enfin, ce n'est pas de moi qui avait voulu tout refaire. Avec Sylvain, on a été en charge d'un projet de refonte de 12 à 13 millions de lignes.

• Speaker #0

  Le mot est lâché, quoi. Tu as dit que le mot est lâché.

• Speaker #1

  C'est assez impressionnant. Voilà, c'est ça. Exactement. Ça ne fait pas rêver, mais le sujet était super sympa. Et là, on avait vraiment les moyens de nos ambitions. On avait mis 3000 jours sur le... uniquement la partie tooling pour mettre en place toute l'architecture des microservices, c'était l'objectif. Et là, chez Asis, on est dans une société où on n'avait pas forcément les moyens de tout réécrire. On avait 30 ans d'âge, donc plus de 2 millions de lignes de code, et au total 4 millions dans tout le logiciel. Et donc le choix, ça a été de faire de l'innovation en venant grappiller le monolithe petit à petit. J'aime bien les images. Souvent, quand j'explique aux gens, je leur explique que c'est comme un kebab et puis on va tirer les microservices avec la raclette. Et à la fin, il n'y aura plus que le trognon.

• Speaker #0

  J'ai faim maintenant. Merci pour les analogies.

• Speaker #1

  Il faut un peu de temps.

• Speaker #0

  C'est l'hiver midi, ça y est. Du coup, tu me dis que vous avez changé pas mal de niveaux. Déjà, peut-être la question, si on revient un peu au sujet méta de ce podcast, c'est le CICD. Toi quand tu as commencé il y avait déjà des trucs, parce que le projet date de manière générale des années 80-90, bon ça n'existait pas trop le CSI déjà à l'époque, il y avait peut-être des gens qui avaient des buildbots, ou ça pouvait s'appeler différemment à l'époque, parce que c'est quand même pas tout jeune le principe 2, mais tu arrives il y a quoi, ça évolue comment ? Jad tu peux faire des sciai en kobol ? Alors, kobol c'était un

• Speaker #1

  CGDIM donc... C'était assez simple. On a laissé de côté et on a tout repris. Vraiment, même quasiment, c'était peut-être une erreur, mais sans discussion avec l'équipe. C'est une espèce de start-up à l'intérieur de l'entreprise. Finalement, il n'y a pas eu trop de sujets. On est parti sur les technologies du moment. On a été très vite sur Kubernetes, etc. Là-dessus, on a pris l'état de l'art. Au sein d'Assis, la différence, c'est que... Quand je suis arrivé, un an avant, il n'y avait même pas de...

• Speaker #0

  Dans quelle année là ?

• Speaker #1

  On est en 2019, je pense qu'en 2018, il n'y avait pas encore fait de vie de migration. C'est vrai que... CVS guide direct. Ah bah du CVS. Ouais, tout à fait. Donc ça, ça a été... Moi, je ne l'ai pas connu ce chantier-là, mais après, il y avait un embryon de Jenkins. Mais bon... paramétrer entièrement à la main, pas forcément bien maîtrisé. Et donc, l'idée, ça a été de créer un premier microservice, parce que là, ce n'était pas forcément très connu, et de tout de suite partir sur du... Alors, Jenkins, ça s'appelle le Jenkins file, mais en gros, un descripteur. Et ce descripteur, de le mettre dans un git et d'y faire référence, ce qui fait que tous nos microservices depuis... s'appuie sur très peu de confus, enfin très peu de ces deux lignes en fait de code chez nous pour pour faire un nouveau microservice et avoir son pipeline parce qu'ils sont entièrement homogénés et là le choix que j'ai pris parce que en fait je vais faire un petit aparté mais on est très orienté test enfin moi j'ai pris ça de CGD, on a tout fait en TDD, BDD et du cucumber notamment. Et quand il s'agit de créer les pipelines, moi aussi je me suis posé la question, finalement, comment on teste ? Il y avait des gens de Nantes, d'ailleurs, je crois qu'ils avaient fait quelque chose qui s'appelait Jenkins Unit, ou quelque chose comme ça, qui permettait de faire des tests au sein de Jenkins. Mais finalement, j'ai pris le parti plutôt de faire un petit peu comme en cucumber, plutôt du comportemental. Et on a créé un petit produit fictif qui est décomposé en microservices, mais il n'y a rien dedans spécial. C'est ce microservice que, dès qu'on fait un changement sur le pipeline, on le rebuild entièrement. On rebuild tous les microservices. Ça nous permet de nous garantir qu'on n'a pas cassé une étape en.NET, en Java ou en un autre langage puisque la particularité, c'est qu'il y a du... Il y a du multilangage en fait. Il y avait plusieurs R&D quand je suis arrivé.

• Speaker #0

  Des produits qui se parlent entre eux ?

• Speaker #1

  Maintenant, le produit se parle entre eux avec des approches de bus de messages. On est sur Oracle d'infrastructure, donc ce n'est pas hyper connu.

• Speaker #0

  D'accord, ils ont un bus de messages. Je ne connais ça du tout.

• Speaker #1

  C'est plus robuste. Oracle, en fait, c'est un... Ils sont arrivés très tardivement, ils ont un peu raté le virage du cloud, ils ont laissé ça à Amazon et Google et finalement ils sont revenus dans le match vers 2019. On a une base de Nenoracle et on a de l'adhérence là-dessus donc ça a été un choix plutôt économique. Voilà. Et petite... Donc ça, c'était sur la CI. Et sur la CD, en fait, on est parti sur du Docker Compose parce que le gap, il était... Quand on arrive dans une équipe comme ça, il faut réussir à transformer les gens vers du DevOps. À une époque, même quand je suis arrivé, au début où j'arrivais, on envoyait des bouts. programme aux clients sans traçabilité. On était vraiment assez loin d'une usine classique et on avait très peu de SaaS également. C'était beaucoup de premise et un des premiers chantiers, ça a été de déployer toutes les deux semaines notre logiciel sur tous les tenants et de mettre en place beaucoup de tests à travers on a écrit.

• Speaker #0

  C'est une emploi de tests avec tout le temps. quand tu dis plusieurs tenants du coup c'est vous avez c'est quand c'est mutualisé en termes de déploiement ce que tu parles de on prem aussi donc ça entre tu as du sas ou c'est réalisé ou c'est alors

• Speaker #1

  on a les deux en fait on a on a dû mutualiser donc une fin une stack plusieurs machines enfin gère plusieurs instances d'applications et puis donc il y a pour répondant à pas mal de tenants et après on a aussi des stacks dédiés où là l'ensemble de la machine l'ensemble de la partie authentification de base de données etc est propre au client en fait du coup ça revient ça c'est quasiment la même chose du coup d'un point de vue logique ouais

• Speaker #0

  t'as plus de c'est juste que tu partages ou pas les stacks finalement oui ok tu n'es pas sur ce que c'est des stacks au niveau hardware derrière

• Speaker #1

  Alors non, c'est de la vertu, ça ressemble à de l'EC2 de CI, et on a fait le choix, qui est assez classique maintenant, de mettre les bases de données en pass, ça nous évite pas mal de gestion, surtout que les bases de données Oracle... Ok,

• Speaker #0

  j'imagine, tu as tout prêt en fait, ce qui n'est pas plus mal au final si tu ne veux pas t'embêter. Ok, du coup tu peux déployer toutes les deux semaines tu disais ?

• Speaker #1

  Oui, c'est ça. À travers l'outil dont on a parlé, qui s'appelle Kassal, on a vraiment géré, vu qu'on n'est pas encore en multitenant sur l'ensemble, notamment les monolithes, c'est très difficile de les mettre en multitenant. Ça n'a pas été prévu au départ, c'est très compliqué. Le choix a été d'industrialiser et surtout de visualiser tous les sprints. pour que l'on soit sûr que tous les tenants soient à jour. On a une petite interface graphique qui nous permet à la fois de commander, le fait de dire je veux qu'il soit mis à jour et on a la restitution avec une petite part de progression sur un outil qui nous restitue c'est bon,

• Speaker #0

  je suis à jour Est-ce que votre but, c'est d'aller plus loin dans les fréquences de déploiement ou d'un point de vue business, c'est good enough, et d'un point de vue tech aussi ?

• Speaker #1

  Pour nous, pour l'instant, c'est suffisant parce qu'on est les seuls sur notre marché, le marché où on est sur ce qu'on appelle la gestion des temps des activités. C'est assez confidentiel, c'est un morceau des SIRH. Et aujourd'hui, on est parmi les meilleurs, je pense, sur la partie SaaS. La plupart de nos concurrents nous font payer les messages.

• Speaker #0

  Ce n'est pas de l'abonnement, du coup, c'est limite encore de la licence ?

• Speaker #1

  Oui, c'est ça, c'est de l'hébergement. Alors qu'il y a 10 SaaS, mais en fait, dans les faits, c'est de l'on-premise qui a été posé dans l'architecture sur un hébergeur. Et donc déjà, ça, c'est pas mal. Et on a toujours le problème de faire tourner nos end-to-end. C'est assez classique, ils sont volumineux. On a l'équivalent de 25 heures de test manuel. C'est 600 ou 650 tests auto qui font 3-4 minutes. je n'ai pas fait le calcul mais on doit être à peu près à cet ordre là et donc ça on a une ferme de Selenium etc mais on n'a pas forcément la capacité à déployer toutes les 3 minutes un nouveau parce que je n'ai pas forcément expliqué quelque chose c'est que même en microservice c'est recommandé pour les déployer indépendamment nous on a fait le choix de toujours packager l'ensemble du monolithe plus les microservices Merci

• Speaker #0

  et de tester l'ensemble en fait et pas de se dire tiens je vais déployer c'est un compromis qui est aussi pas déconnant dans le sens où sur le papier, sur le principe tu peux déployer un seul microservice etc mais maintenant t'es jamais sûr et certain que t'as pas des régressions, des incompatibilités avec les données bah faut tester quoi dans tous les cas faut tester toute la stack pour assurer que bon c'est le problème du microservice c'est que tu pars du principe que du coup tu passes des contrats entre tes différents services sur leur interface, comment ils vont communiquer entre eux etc mais bon Tu n'es jamais à l'abri d'avoir un contrat qui est rompu ou une partie du contrat qui n'est pas documentée. J'ai eu souvent ce genre de conversation avec des ingés où on me dit que c'est bon, on a du déjà nos schémas, on valide tout, on peut modifier les trucs, mais ce que tu ne valides pas, c'est le comportement d'une API, par exemple, et des effets de bord qu'elle peut avoir ou pas, des bugs que tu peux introduire comme ça, et du coup, des changements. Donc, ce n'est pas évident. Je pense que la théorie fait que tu peux déployer ces microservices indépendamment, mais en pratique...

• Speaker #1

  c'est pas plus mal de tout tester et c'est difficile d'ailleurs vous avez fait plusieurs repos pour ces différents services où vous avez ouais c'est ça en fait c'est un choix aussi structurant et peut-être un peu clivant c'est que du fait qu'on voulait avoir des librairies un petit peu homogènes pour pour gérer chaque typologie de microservice par exemple un Spring Boot en Java il y a un code qui fait le code la CI-CD,.NET Core 8, il a sa propre bibliothèque de CI-CD. En fait, l'idée, c'était de déclencher, en fait, à un, une modification de logiciel d'un morceau de repository, en fait, à un commit, on associe une pipeline. On ne voulait pas forcément gérer le fait de dire, tiens, si on modifie tel morceau de code, on va déclencher tel morceau de code. de pipeline, etc. En fait, c'est très homogène. Alors par contre, ce qu'on a fait au tout début et ça, ça nous a sauvé, c'est qu'on a été très strict sur la convention de nommage. Tous nos repositories sont en cinq, avec le produit, le domaine, le sous-domaine, la technologie et on a un outil qui nous descend tous nos repos et ce qui fait que sur n'importe quel outil de machine de développeur, c'est toujours sur le même répertoire et organisé de la même façon et tout le monde a toujours tout. Ce qui fait que On retrouve quelque part le fait d'avoir un petit monorepo. Après, les outils de refactoring transprojés sur un monorepo, à part du grep ou l'équivalent ou du replace, on n'a pas forcément. On a ce compromis-là qui est intéressant. Pour moi, lorsque les gens font commit, ça peut arriver, les développeurs n'étaient pas forcément hyper habitués à Git, ils peuvent faire des bêtises.

• Speaker #0

  en fait quand ils se trompent sur un repo ou ils font un mauvais merge ce que j'allais te demander c'est comment tu gères son CI intermodule, intercomposant c'est à dire est-ce que tu en as un ou est-ce que chaque composant se teste individuellement est-ce que tu as un grand orchestrateur qui vérifie que tout fonctionne du coup c'est au déploiement on disait parce qu'à ce moment là si tu testes tout peut-être c'est là où tes tests end-to-end aussi interviennent où ils sont sur tous les composants derrière mais comment tu organises tout ça au quotidien du coup ?

• Speaker #1

  Oui, chaque microservice ou chaque artefact, chaque librairie a son propre cycle de vie avec une versionning SAMVER classique sur ton GIF. En fait, Castle et notre outil viennent modéliser chaque produit en disant que ce produit est composé de ce microservice, ce microservice, ce microservice. Et potentiellement, on ne l'a pas encore fait, mais pour la test end-to-end, de faire des grappes en disant que cette grappe end-to-end ne peut porter que sur tout cet objectif. trois microservices parce que ça fait un domaine en fait. Et d'essayer de statistiquement entre guillemets, de se dire je peux catcher beaucoup de problèmes au moment des tests unitaires, du premier niveau de microservices pour créer l'artefact, l'artefact version on appelle ça, et après il y a la création d'un produit, on appelle ça product version, qui là lui va être mieux testé, c'est là où on va tester l'intégration.

• Speaker #0

  L'idée c'est d'avoir des packs... Ça je ne le fais pas encore à ce niveau-là.

• Speaker #1

  Si, si. Ok,

• Speaker #0

  je ne fais pas l'optimisation. D'accord,

• Speaker #1

  ça c'est pas grave. Là c'est l'optimisation. Et donc Castle nous donne tous les produits. Et après, Castle est lui-même en micro-service, donc il y a une partie produit qui nous sécurise cette partie construction d'un package. avec tous les composants et après ce qui va se passer c'est que cette partie là va être envoyé côté plutôt micro déploiement et c'est là où par exemple chaque microservices on va scanner l'ensemble de ces clés de config si c'est sur une spring boot un application point yaml si c'est je suis un setting ce qu'il va scanner l'ensemble de ces clés et il va dire au moment du déploiement voilà il ya une nouvelle clé et cette nouvelle clé il va falloir la renseigner sur les tenants, tous les tenants, avant de pouvoir déployer ou ce genre de choses. En fait, on est très assisté pour arriver à gérer cette complexité, qui est la complexité, c'est mig... 20-30 microservices par produit, fois des centaines de tenants, fois plein de...

• Speaker #0

  C'est une grosse matrice,

• Speaker #1

  voilà.

• Speaker #0

  Du coup, pour les tests, tu ne les fais pas forcément plus tard. C'est vrai que ta feedback loop pour les développeurs, ils peuvent très bien détecter des problèmes plus tard une fois que le code est émergé, etc. Enfin, c'est un compromis, ce n'est pas inacceptable, mais ça permet d'avoir aussi des développeurs qui vont assez vite. Du coup, la latence pour corriger des problèmes éventuels peut être un petit peu plus longue derrière.

• Speaker #1

  le temps que tu t'en rends compte ouais c'est exactement ça donc il y a des chantiers d'optimisation un peu partout à mener on en a prévu mais voilà on préfère avoir une boucle de 5 minutes pour se dire bon et dans les faits on a peu de choses qui sont pas détectées qui sont détectées très tard parce que les produits sont très gros donc statistiquement là aussi il y a peu de chances que enfin ça arrive évidemment mais je Au final, on les corrige en une heure ou deux maximum à la fin. Et ça ne bloque pas les autres développeurs.

• Speaker #0

  Tu as de la QI en plus ? Tu as des humains en plus qui testent maintenant ? Ou c'est juste que tu les testes ? C'est l'Union M9 ?

• Speaker #1

  Oui, on a mis ça en place. Non, non, non, c'est l'Union M9. Parce qu'en fait, un petit point de particularité, c'est que la GTA s'adresse à l'ensemble des collaborateurs. C'est un des logiciels B2B qui est le plus... communément utilisés parce que ça fait notamment la pause de congé et dans une société privée, à moins d'être tout seul ou très peu, mais en général elle est prise en charge par un logiciel et donc en fait ça nous fait quand même au total plus d'1,5 million d'utilisateurs réellement et donc on ne peut pas se permettre que tout soit ok par Selenium et qu'on s'aperçoive qu'il y a un énorme carré bleu c'est un peu débile mais qui empêcherait de saisir ou qui ferait bizarre sur la plateforme qui est réservée à...

• Speaker #0

  C'est logique,

• Speaker #1

  après je pense que tu as une dernière phrase.

• Speaker #0

  Je suis à 100% sûr. Ça reste acceptable si tu fais des déploiements de manière assez régulière, mais espacée aussi. Sur les... Là, vous avez fait pas mal de trucs, du coup, le découpage et compagnie, tu parlais d'optimisation, il vous reste beaucoup de choses encore à ton sens pour améliorer, ou vous êtes assez content de ce que vous faites ? là où vous en êtes au niveau CI, dans vos différents modules, sur le monolithe qui en reste du coup, de ce que je comprends, et c'est encore à découper,

• Speaker #1

  c'est classique j'imagine. En fait, il y a plein de sujets, en plus c'est en mon dada, donc c'est vrai que régulièrement j'ai des nouvelles idées sur cette partie-là, mais on a un gros enjeu de cartographie, puisqu'on a découpé couper les premières parties périphériques. Et puis, quand on arrive au centre du monolithe, c'est là qu'il faut découper de façon chirurgicale. Et comme on est en présence de milliers de fichiers, il y a un des produits, notamment, tout était à la racine. On ne pouvait même pas dire qu'il y avait des packages. On ne sait même pas le volume de tel domaine. Est-ce qu'on a des badgeuses ? Combien ça représente chez nous, le volume de code de badgeuse ? On ne le savait pas forcément. Et donc, on a fait des petits outils. pour classifier et cartographier l'ensemble du logiciel. Et après, sur la partie déploiement...

• Speaker #0

  L'idée, c'est vraiment d'assister au maximum nos équipes. Pour un exemple tout bête, on a des plages de maintenance pour upgrader nos stacks. C'est important comme logiciel, mais on peut se permettre qu'une heure, pendant une heure, à une date bien définie, ne soit pas forcément disponible. Voilà, les gens sont... C'est disponible de 24 sur 24, mais deux heures par tous les trimestres, on s'autorise des plages de maintenance. Tout ça, il faut le faire en conjonction avec nos clients. Sinon, après, ils ont des tas de remontées clients où ils disent que ça ne marche pas, etc. Donc, il faut qu'ils prévoient en interne. Tout ça, on l'a codé pour que ce soit un parcours fluide où nos calculs de SLA, on les capture depuis un certain nombre d'outils. On a beaucoup de choses en interne. Et là, notre gros sujet, c'est de gérer maintenant finement le multitenant. Puisque la caractéristique, c'est quand on a du monotenant avec du multitenant, il faut réussir sur des opérations toutes bêtes, du style j'ai 10 tenants qui tournent sur une stack. Je mets à jour vers la dernière version. Ça, c'est assez facile de migrer les parties monolithes. et l'ensemble des microservices sur la dernière version mais lorsque l'on a encore un ou deux clients qui ne sont pas encore réceptifs à ce qu'on mette à jour tout de suite et qui préfèrent attendre d'autres clients à ce moment là ça devient compliqué parce qu'il faut potentiellement recréer une application avec l'ancienne version bouger les tenants et tout ça c'est si on le faisait manuellement ce serait très compliqué on automatise beaucoup ces parties là multi tenancy une application la démulti tenancy mais ça a un impact direct du coup en terme de si pour vous ou pas vraiment parce que c'est vraiment plus côté côté applications architecture du coup si je comprends bien ouais c'est bon sur le déploiement sur la partie cd Donc là, du coup, on a pris une approche GitOps parce que c'est tellement compliqué que le risque, si c'est buggé, en fait, on ne le voit pas. En fait, on a deux étapes. On a une première étape qui consiste à faire l'action qui génère tous les fichiers de conf Git. Alors là, c'est du Docker Compose, mais demain, ce sera 162 du cube. Et après, il y a l'application, le script qui va réellement appliquer. Donc on a quand même cette sécurité. Au cas où on a un bug dans le logiciel, on va pouvoir directement modifier le résultat. Et après, de...

• Speaker #1

  de revenir sur le git et de dire maintenant je corrige le logiciel et je régénère en fait t'arrives quand même à faire évoluer je trouve pas mal le système de manière générale même si t'as beaucoup de trucs plus ou moins anciens, d'architecture etc t'arrives quand même petit à petit à incorporer à bouger vers du cube par exemple ce genre de choses ça prend du temps c'est sûr mais c'est quand même assez cool et comment vous vous êtes organisé du coup en interne d'un point de vue c'est bête mais si ICD tu parlais de sysadmin, de devob, etc. Mais la partie CI, du coup, c'est les devs qui s'en occupent à proprement parler ? Comment c'est dispatché ?

• Speaker #0

  C'est ça, en fait. On a un fonctionnement qui s'appelle en initiative, en gros, on a les user stories, le niveau issue, et puis il y a des épiques. Lorsqu'on a un chantier suffisamment grand, on fait une initiative et à ce moment-là, c'est pris en charge par les développeurs. qui vont améliorer une partie de la CI la CI commune ou la CI spécifique pour du Java, du.NET etc et donc il y a quand même une appropriation par l'ensemble des développeurs de cette partie là, la CD c'est plus compliqué parce que ça me parait un peu plus complexe ok,

• Speaker #1

  du coup c'est des gens comme tu disais tout à l'heure qui s'en occupent ça ne me parait pas non plus déconner dans le sens où d'abord trop d'autres problématiques et que ça peut être plus du coup ça veut dire aussi que de ton point de vue du coup les développeurs font pas forcément le run de l'application à proprement parler et que la main se passe entre les deux ouais alors on a de toute façon un

• Speaker #0

  support en fait qui est plutôt fonctionnel et puis après il y a des mécanismes d'escalade techniques où l'avantage en ça c'est qu'on peut récupérer les logs etc on a du Prometheus, du Grafana et du Loki, mais bon, je ne l'ai pas précisé, mais à 6, on est 200, ça commence à devenir une organisation où il peut y avoir un peu plus de latence que sur un SaaS.

• Speaker #1

  D'ailleurs, tu parlais de stack un peu technique, c'est quoi du coup le reste de votre stack ? On n'en a pas parlé au niveau, je ne sais pas, Git, c'est quoi du GitHub, du Google Cloud, j'imagine ?

• Speaker #0

  Ouais, alors on a fait, non on a fait un choix, alors c'est pas le mot qui a fait le choix, mais je le trouve vraiment intéressant, on a utilisé du github,

• Speaker #1

  c'est vrai qu'on en a parlé,

• Speaker #0

  comme le,

• Speaker #1

  la première personne que je connais utilisait ça,

• Speaker #0

  github, et en fait c'est ça, comme le T, et le gros avantage en fait ça a été fait par un certain nombre d'acteurs, dont des gens qui, enfin comme DigitalOcéan, enfin des acteurs de cloud qui veulent avoir une partie github mais qui veulent pas, avoir la... on va dire le fait que par exemple GitLab c'est assez gros il faut quand même des grosses machines là c'est vraiment écrit en Go alors ça a été écrit avant en je sais plus quel langage mais enfin là c'est écrit en Go et c'est très rapide ça demande très peu de mémoire nous on tourne sur du T3 Small en Amazon ça marche très très bien et le gros avantage qu'il a c'est qu'il a du Swagger nativement ils ont démarré avec OpenAPI Swagger Ça nous permet du coup de le piloter. Et on envisage même de l'utiliser. On a des problématiques de paramétrage, parce qu'on est sur du projet Ciel. Tout ça, on l'explique aussi dans le livre. On veut même servir de guide comme étant le back-end, l'espace de stockage de nos gestions, de branches de paramétrage, puisque le paramétrage, c'est un peu du code. Et donc, l'idée, c'est de ne pas réinventer un gestion de source à nous. du fait qu'il est petit et multitenant parce que c'est un clone de GitHub donc on peut gérer des organisations qui sont des tenants etc. ça va nous permettre de l'opérer relativement facilement.

• Speaker #1

  Ouais, donc la partie CI aussi est faite par Githy ? Ouais. Ouais ok. Donc ouais tu te modifies tout avec Github. Ouais c'est ça ouais. Je pense que beaucoup de gens le connaissent pour pas Githy parce que c'est beaucoup moins populaire que GitHub ou que GitLab. Et du coup, le W2CI, c'est ça. Donc le RAS de Workhouse, tu n'as pas besoin de pas grand-chose, c'est parce que c'est un jumel que tu peux tout faire avec la CICD que tu as intégrée, que tu peux déployer avec, etc.

• Speaker #0

  C'est ça. En fait, on pilote, par exemple, dans GitOps, c'est assez classique, c'est même ce qui est recommandé, le workflow d'acceptation d'une modification est géré par l'acceptation d'une pull request. Tout ça, on le déclenche par notre outil et on watch.

• Speaker #1

  est-ce que c'est pas un problème sujet un petit peu connexe je connais pas du coup la plateforme de CSI par exemple mais pour trouver des ressources ou trouver même des humains pour gérer tout ça vous avez des gens en interne qui sont auto-formés j'imagine parce que c'est dur de recruter des gens qui sont experts en

• Speaker #0

  Git TCI ouais c'est sûr le fait qu'il y ait les API Swagger non et qu'ils écrivent dans leur langage de leur choix, en l'occurrence, c'est en Java, ça simplifie beaucoup de choses parce que les API sont vraiment très claires. Moi, je les trouve même plus claires que celles de GitHub. Donc, ça se fait relativement facilement. Et comme on a très peu de tringleries dans les logiciels puisque le choix était de porter la complexité beaucoup dans Castle, qui est la partie web, ça nous a permis de faire beaucoup de tests dans cette application. Et donc la partie réellement de code, même dans Jenkins, on a peut-être 2000 lignes ou 3000 lignes de Jenkins file, enfin de morceaux de Jenkins file, et dans Githy on a très peu de code en fait. Donc ça c'est vraiment la clé, c'est qu'on peut tester 90 ou 95% de la CI sans avoir besoin d'être... Pour le coup c'est plutôt pratique. Ouais c'est super pratique, parce que des fois attendre la CI-CD pendant 4-5 minutes...

• Speaker #1

  Tu vois quand tu sais débugger des GitHub Action, c'est assez pénible. Il n'y a pas trop d'outils. C'est un problème de fond que personne n'a vraiment résolu pour l'instant. Débuguer les CI de manière générale, ce n'est pas toujours évident. Tu n'as pas trop de moyens de faire ton lettre en local non plus. Tu ne peux pas débuguer rapidement. La feedback loop est souvent très longue et frustrante pour les devs. Ce n'est pas idéal.

• Speaker #0

  C'est ça qui a conduit au choix de Kassal et de ce fameux pet store dont je parlais au début, c'est-à-dire ce petit programme qui nous permet de voir...

• Speaker #1

  Oui,

• Speaker #0

  effectivement,

• Speaker #1

  c'est un bon mot. On a fait un bon tour, j'ai l'impression, de toute votre affront en termes de CICD. Est-ce que tu penses qu'on a raté quelque chose autour de tout ça, qu'on n'a pas parlé et qu'il faudrait qu'on en parle ?

• Speaker #0

  Non, non, non, je pense que c'est un peu abstrait comme ça, mais je pense qu'on a... fait le tour et que voilà ça a permis de voir peut-être une façon un peu différente de celle qu'on peut voir plus classiquement lorsque les développeurs peuvent démarrer voilà avec les outils

• Speaker #1

  Mais ouais, vous avez quand même réussi à bouger dans le 21ème siècle, donc c'est plutôt cool. Et puis vous avez encore pas mal de taffes, mais bonne direction de manière générale du projet, j'ai l'impression. Donc félicitations. Et bien merci beaucoup Stéphane d'avoir partagé tout ça, c'était super intéressant. Au plaisir.

• Speaker #0

  Avec plaisir. Et bien merci beaucoup et à très bientôt.

• Speaker #1

  Au revoir.

• Speaker #2

  Et voilà, c'est la fin de cet épisode. Un grand merci à vous de nous avoir écouté aujourd'hui dans cette exploration du monde fascinant du DevOps. Si ce podcast vous a plu, n'hésitez pas à le partager, voire à me laisser un avis, voire à me laisser 5 étoiles sur votre plateforme de podcast préférée. Ça m'aiderait énormément et ça fait toujours plaisir. Restez connectés pour encore plus de découvertes, d'astuces, de témoignages inspirants dans les prochains épisodes. Et d'ici là, gardez vos pipelines fluides et votre CI bien adapté. A très bientôt pour une nouvelle aventure au cœur du CI-CD.