Renovate pour mettre à jour vos projets en continu

J'ai déjà évoqué sur le blog la question des dépendances (ici, ici, ici et là), souvent pour pousser à réduire leur nombre, les choisir avec attention, et aussi qu'il fallait les suivre.

Autant sur mes projets personnels je fais totalement ce que je veux, et je peux tendre vers zéro dépendances, autant au travail c'est pas toujours aussi simple. Depuis plusieurs années maintenant je travaille avec du Renovate au quotidien, après avoir passé quelques années à me débrouiller dans mon coin. Je vous explique ma démarche, comment je m'en sers, et comment je suis tout ça.

Souvent c'est une seule personne qui gère…🔗

La gestion des dépendances dans les projets c'est souvent le dernier truc qui est pris en compte : c'est le truc qui coûte cher et qu'on priorise pas. Sauf que la gestion des dépendances, la majorité du temps, c'est 5-10min par semaine, aller 15-20min si votre périmètre est gros, et ça roule tout seul si on est régulier. Mais oui si on attend le "ticket technique de mise à jour" qui arrive tous les 3 ans, là c'est un calvaire : ça dure des jours, on sait pas trop ce qui change, on le voit après la mise à jour. Et comme on a pris 3 ans de mise à jour d'un bloc, aucune idée d'où viennent les changements, donc on peut y passer des jours pour comprendre pourquoi on a une erreur en particulier et on est clairement plus du tout volontaire pour prendre le ticket de mise à jour suivant…

La réponse à ça c'est souvent qu'une personne de l'équipe, pour qui ça tient à cœur, va prendre les 5 - 10 - 15 min chaque semaine, sans rien dire et faire le suivi des montées de versions. Il gère ça tout seul. Personne s'occupe de ce qu'il fait. Peu importe que ce soit un des devs de l'équipe ou le lead ou une personne un peu transverse à plusieurs équipes qui centralise la connaissance, c'est une personne seul face au sujet. Une personne sans qui rien n'est mis à jour quand il est absent. Une personne qui quittera un jour l'équipe (parce que c'est un prestataire, parce qu'il aura démissionné ou juste il sera passé dans l'équipe d'à côté), et il n'y aura plus personne pour suivre les mises à jour et on retombera dans le cercle vicieux du ticket de mise à jour technique au mieux annuel.

Comme personne ne suit les mises à jour : personne n'est capable de dire si c'est un gros effort, personne n'est capable de dire si ça coûte cher à l'équipe en vraie, personne n'est capable d'avoir de la sérénité sur le sujet, personne n'a de métrique, personne n'est capable d'évaluer comment on corrige une faille de sécurité. Aucun responsable (chef de projet, directeurs, etc.) ou métier (PO, PM, BA, etc.) n'a de vision là-dessus, donc impossible de faire de la priorisation. On ne peut pas vendre ce sujet comme une petite bande passante à dédier à l'équipe pour la mise à jour technique continue des projets.

Pour avoir été longtemps LA personne qui suivait les mises à jour, c'est fatiguant à la longue… Mais j'avais pris des habitudes, j'avais commencé à m'outiller (voir créer des outils), ça faisait partie de ma routine hebdomadaire, et ça fonctionnait (en apparence), donc personne ne s'en préoccupait.

Arrivé de Renovate🔗

Renovate (ou RenovateBot) c'est un bot qui va venir automatiser une bonne partie du travail de découverte des mises à jour, de suivi, très paramétrable. Concrètement l'idée c'est de le faire tourner une ou plusieurs fois par jour pour proposer des MR (Merge Request) sur votre projet de sorte à mettre à proposer des modifications de version. Comme ça vous en tant que développeur sur un projet, vous n'avez plus qu'à cliquer sur "Merge" et c'est fini, vous passez à autre chose (ou à la MR suivante).

Même s'il y a des alternatives (plus ou moins complète, plutôt moins que plus d'ailleurs), RenovateBot est vraiment l'outil qui est devenu le standard du marché. Il y a très peu d'effort pour la configuration initiale et vraiment ça fonctionne bien !

Le plus gros problème au début c'est souvent qu'on a des gens réfractaires : iels ne voient pas l'intérêt, iels ne veulent pas avoir à s'en occuper, iels ont peur d'être submergés (souvent parce qu'iels ne veulent pas s'en occuper, iles ont laissés trainer et iels savent que y'a du boulot pour rattraper le tir), iels n'ont pas confiance. Ensuite vous aurez surement une phase de rattrapage où vous aurez beaucoup de MRs (c'est normal).

Ensuite il faut que ça devienne un sujet d'équipe : la dette c'est un sujet commun à toute l'équipe, côté dev, mais aussi côté métier. Quand votre application sera tellement en retard qu'on ne pourra plus corriger de faille de sécurité (dans de plus en plus d'entreprise, ça peut vouloir dire ne plus avoir le droit de livrer en production, et c'est une bonne chose à mon sens tant que la discussion est possible je suis pour des règles de sécurités strictes personnellement), quand votre application ne pourra plus évoluer sans avoir des coûts démesuré, quand vous n'arriverez plus à recruter, car l'application sera trop ancienne technologiquement parlant, vous serez totalement bloqué côté tech, mais aussi côté métier. C'est pour ça que la dette c'est une affaire du quotidien, pas un truc qu'on fait quand on a le temps.

Quelques conseils pour que ça fonctionne chez vous🔗

Comme je disais : Renovate et plus généralement la dette, c'est un sujet d'équipe. Par contre je pense que pour lancer Renovate, il vaut mieux qu'il y ait une personne qui lance le mouvement, prenne le temps de lire la documentation, mette en place et dépile la première vague de MR, pour voir les principaux problèmes (souvent des histoires de proxy/registry interne à configurer, des configurations à ajuster pour mieux coller à votre réalité, trouver les bons compromis), et une fois que ça roule, là il faut diffuser à l'équipe. Pour moi c'est l'affaire de 2-3 semaines maximum pour arriver à atteindre un rythme de routine. Et quand je dis 2-3 semaines, ce n'est pas à faire que ça, c'est peut-être 2-3h le premier jour, puis 30-45min les jours suivants pour arriver à une dizaine de minutes / jours assez vite. Au début ça peut être décourageant, on merge 5 MR, 5 autres apparaissent, et ainsi de suite, ça semble être sans fin, et vous ne voulez pas décourager trop l'équipe, surtout si vous avez des réfractaires.

Quand vous diffusez à l'équipe, je vous conseille de partir sur un rôle tournant à la semaine : chaque semaine, une personne de l'équipe est responsable de suivre les MR Renovate et d'en merger un maximum pendant sa semaine, avant de passer la main. Pas besoin d'un système compliqué : une page dans confluence pour suivre qui l'ordre de qui a fait du Renovate, un tableau blanc dans le bureau et on change le rôle juste après le daily sur le premier jour sur site de la semaine, un message dans la conversation d'équipe pour dire qu'on passe la main, peu importe. Faites-en un rituel, faite en sorte que ça tourne, juste faite ça en bonne intelligence (si quelqu'un est absent la moitié de la semaine, n'hésitez pas à sauter son tour pour une semaine pour qu'il est pleinement le temps de prendre le rôle).

Note 1 : L'idée du rôle tournant fonctionne pour beaucoup de choses. Pour moi c'est un excellent moyen de partager la connaissance : Renovate, suivi des environnements de recette (s'assurer que rien n'est cassé et lever l'alerte au besoin), suivi de la production, mise en production. Toutes les tâches que vous estimez devraient pouvoir être prise par n'importe quel développeur de l'équipe peuvent devenir un rôle tournant de sorte que chacun soit obligé de savoir le faire. Ça n'empêche pas d'avoir des affinités sur certaines tâches qui peuvent conduire à plus d'expertise, simplement tout le monde sait se débrouiller un minimum et ne sera pas bloqué en cas d'urgence.

Note 2 : Trouvez un nom pour le rôle. Dans mon ancienne équipe on avait le rôle de "Renovate Manager" et de "Release Manager" (c'était dommage d'avoir les mêmes initiales mais bon), avoir un nom ça donne de l'importance au rôle à mon sens.

Au début vous allez avoir pas mal de MR à dépiler pour revenir à un état totalement à jour. C'est normal. Par contre assez vite je vous conseille de plafonner le nombre de MR maximum par dépôt de code, ça permet d'éviter d'être continuellement submergé, d'en perdre les MR fonctionnels et de saturer vos runner de CI à cause de MR Renovate, car ça crée de la frustration pour toute l'équipe (pousser un commit dans une MR et devoir attendre plusieurs minutes avant de voir le pipeline démarrer parce que tout est occupé par Renovate ça va pourrir le regard envers l'outil). En général on conseille 5 MR maximum, si comme moi vous avez un périmètre avec beaucoup de produits, vous voudrez peut-être mettre 3 (voir 2).

Si vos dépendances suivent le SemVer, vous pouvez prioriser les patchs sur les mineures, et les mineures sur les majeures. L'idée c'est déjà que c'est moins source d'erreur de prendre en compte un patch qu'une mineure, et de même entre mineures et majeures. Ensuite si mise à jour de sécurité il y a, ce sera généralement sous forme d'un patch, parfois une mineure, rarement une majeure. Par contre, par principe : ne faites pas confiance au SemVer des lib / outils interne d'entreprise, personnellement je mets la même attention pour chaque patch ou mineure qu'une majeure pour les lib interne, car dans les faits, le SemVer est rarement respecté…

Très vite je vous conseille de configurer Renovate pour aller chercher les changelog sur Github (il suffit de lui donner un token d'accès à Github). Si vous faites ça, vous aurez le changelog de quasi toutes vos dépendances directement dans la MR que fera Renovate, donc vous pourrez assez vite et facilement regarder ce qui a bougé entre la version que vous avez actuellement et celle que Renovate vous propose.

Je vous conseille d'ajouter un peu de délai sur la proposition d'une nouvelle version. 1 jour c'est bien, 2 ou 3 c'est plus serein, 7 jours (souvent conseillé) me parait beaucoup. Il faut savoir que ce n'est pas rare d'avoir des patchs qui se suivent (on a mal testé et on repousse un correctif dans la foulée le plus souvent) donc c'est aussi bien d'attendre au moins une journée pour encaisser des patchs "stables" plutôt que faire 3 mises à jour dans la même journée pour rien. En cas d'attaque par supply chain (souvent détecté dès la première journée ou à minima les premiers jours), on peut avoir l'alerte d'une version vérolée avant de l'avoir appliquée, elle sera généralement retirée avant que vous l'ailliez mergé et donc éviter le problème. Mettre 7 jours ça évite tout ça, mais ça veut aussi dire que vous mettez 7 jours à être informé d'un patch de sécurité, 7 jours c'est long en production si vous avez une faille énorme. Pour moi c'est une balance à faire, il faut y réfléchir, et tester.

Il vous faut une suite de test solide : si dès la MR sur Gitlab vous voyez que ça fonctionne bien, car le pipeline est entièrement vert, vous êtes serein pour merger la MR. Si au contraire quelque chose casse, vous pouvez regarder, et corriger sans trop vous casser la tête, car c'est bien isolé et vous n'avez pas d'urgence c'est cassé sur la MR, pas sur votre recette. Plus vous aurez de test, plus c'est évident que vous serez serein pour cliquer sur Merge les yeux fermés. Si vous loupez des choses : il vous manque des tests.

Si vous êtes assez serein grâce à votre harnais de test : allez jusqu'à faire de l'automerge. Vous laissez Renovate proposer des changements et votre CI les valider et les merger tout seul. Comme ça vous n'avez rien à faire du tout. Mon conseil c'est de commencer par les patchs des dépendances de développement (devDependancies côté npm) / test (scope test dans maven), ces dépendances qui sont nécessaires pour fabriquer / tester le produit mais sans le constituer. Normalement vous pouvez y aller les yeux fermés pour les patchs de dépendances de développement / test. Vous pouvez aussi automerge tous les patchs, voir toutes les mineures de développement / test, dans la même logique : si vous avez un assez bon harnais de test, il n'y a pas de raison que ça ne suffise pas.

Conclusion🔗

De mon expérience : ça marche vraiment bien !

Vous allez gagner en efficacité sur le sujet très vite, vous serez plus serein, vous allez être capable de très vite voir les mises à jour où vous avez besoin d'intervenir, voir prioriser sous forme d'un ticket à mettre sur vos sprints, car c'est trop gros pour être fait au fil de l'eau.

Ça donne de la visibilité sur le sujet, et ça permet d'en discuter avec les métiers et le pilotage. S'ils prennent le sujet en main, c'est la meilleure chose qui puisse arriver, car ça veut dire qu'ils comprendront l'enjeu et donc ils vont vous aider à faire en sorte que ça fonctionne.

Petite anecdote récente : cet été j'ai ajusté la configuration de Renovate dans mon équipe pour avoir toutes les mises à jour possible qui soit proposé. Quand il est rentré de vacances, mon N+2 (directeur du département) qui m'a envoyé un message pour savoir pouvoir d'un coup on avait 500 MRs en attente (au lieu de 5-10 habituelles). Une semaine plus tard, ma Product Manager m'a posé la même question. Ils ont vu un risque, ils ont compris pourquoi on avait ce changement dans les indicateurs, ils continuent de jeter un œil pour s'assurer qu'on dépile mais sans chercher. Pas de prise de tête sur cet événement, simplement une volonté de comprendre et de garantir qu'on avait pas de souci en vue. Meilleure chose dont on puisse rêver à mon sens sur ce genre de sujet !

Sources :

Crédit photo : Générée via Mistral AI avec le prompt suivant :

A Studio Ghibli-inspired illustration featuring a magical robot with wooden gears and glass-blown screens, sorting and automatically merging package update boxes (labeled with dependency names like 'react@18.2.0 → 18.3.0') on a wooden conveyor belt. The robot stamps the boxes with a glowing '✅ Approved' seal. Around the robot, a group of relaxed red pandas and axolotls (anthropomorphic developers) passively watch, some sipping tea, others reading scrolls (changelogs). Only 1 or 2 characters (a red panda and an axolotl) are in awe: one raising its arms in celebration, the other pointing at a box with a speech bubble saying 'Wow, il a tout géré seul !'. In the background, a wooden board displays a counter '50/50 ✅', and maple leaves fall gently. The scene is bathed in warm, golden afternoon light, with soft textures like wood, fabric, and fur. The atmosphere is cozy, immersive, and poetic, blending high-tech elements (floating code lines like fireflies, a wooden-framed hologram showing 'RenovateBot: 0 erreurs, 100% automatisé') with organic details.