Automatisation des mises à jour de dépendances : Leçons apprises avec Renovate et Yarn

Aujourd’hui la mise à jour des dépendances de nos applications est primordiale dans leur maintenance quotidienne.
Que ce soit pour de nouvelles fonctionnalités ou encore pour maintenir des applications sécurisées.
Mais qu’on se le dise, mettre à jour c’est chronophage …

C’est pour cela que des outils d’automatisation ont vu le jour.

Certifié ISO 27001, la sécurité chez ekino est un sujet primordial à tous les niveaux, et en particulier en ce qui concerne celle des projets de nos clients. La mise à jour régulière de ceux-ci est obligatoire pour gérer au plus vite toute faille de sécurité exploitable.

Nous utilisons plusieurs solutions, telles que Dependabot ou Renovate, et c’est de cette dernière que j’ai choisi de vous parler aujourd’hui.

Problématique rencontrée avec Yarn et Renovate

Lors de l’implémentation de Renovate, nous l’avons configuré pour effectuer les mises à jour de tout ce qui touche à du JavaScript.

A la suite du merge des premières merge requests ouvertes par Renovate, nous avons rencontré un problème spécifique lié aux mises à jour du fichier yarn.lock. La pipeline de build passait en erreur lors de l’installation des dépendances frontend du projet.

En effet, Renovate effectue des mises à jour automatiques dans ce fichier.
Mais cela pose un problème lorsque nous utilisons la commande yarn install –immutable pour maintenir des dépendances maîtrisées historiquement par les développeurs.

Pour comprendre le fonctionnement de cette option –immutable il faut se pencher sur le fonctionnement de la commande yarn install.

Celle-ci gère l’installation des dépendances à partir du fichier de référence package.json. Grâce à lui, Yarn installe les dernières versions des dépendances possibles puis le fichier yarn.lock sera ensuite actualisé, ou créé si inexistant.

Le problème ici est la montée en version systématique des dépendances lors de l’installation. Cela empêche de savoir ce que l’on installe réellement, l’option –immutable répond à cette problématique en bloquant toute mise à jour du fichier yarn.lock.

Remise en question de l’approche

Nous avons décidé de changer notre approche en considérant que les développeurs gèreront désormais les mises à jour des versions en fusionnant ou non les dépendances mises à jour par Renovate.

Cette approche permettra à toute l’équipe d’être au courant de la disponibilité et la validation des mises à jour des dépendances de manière unitaire sur le projet.

Dans ce contexte, il était nécessaire de retirer l’option –immutable pour éviter l’erreur suivante :

Solution adoptée et résultats

Pour résoudre ce problème, nous avons modifié notre processus d’installation des dépendances.

Lorsque la commande yarn install est lancée, nous avons retiré l'option –immutable (anciennement –frozen-lockfile).

Youpi cela a fonctionné sur notre machine et nous commitons en pensant bien évidemment que tout est réglé. SPOILER : C’est faux !!!
La CI nous rappelle à l’ordre avec la même erreur. Mais pourquoi ?

Lorsque Yarn est lancé celui-ci est capable de déterminer seul s’il est utilisé dans un environnement CI ou non. Yarn utilise un paquet nommé ci-info qui se base sur les variables d’environnement (exemples: CI, BUILD_ID) pour déduire s’il s’agit d’un environnement CI.

Pourquoi, nous parle-t-il de détection d’environnement alors que le problème avec Yarn n’est pas résolu ? J’y viens !

Dans la documentation de Yarn relative à la commande install il y a un passage concernant –immutable :

If the –immutable option is set (defaults to true on CI), Yarn will abort with an error exit code if the lockfile was to be modified (other paths can be added using the immutablePatterns configuration setting). For backward compatibility we offer an alias under the name of –frozen-lockfile, but it will be removed in a later release.

Vous avez trouvé le problème ?! Et oui par défaut l’option –immutable est activée lorsque Yarn est utilisé dans une CI.

Donc dans notre environnement CI, nous avons défini une variable nommée YARN_ENABLE_IMMUTABLE_INSTALLS avec la valeur false.

Cette solution a permis de stabiliser notre processus de mise à jour des dépendances et d’éviter les erreurs de pipelines.

En conséquence, les mises à jour automatiques des dépendances sont devenues plus fluides et moins sujettes à des conflits, améliorant ainsi notre flux de travail et notre productivité.

Automatisation des mises à jour de dépendances : Leçons apprises avec Renovate et Yarn was originally published in ekino-france on Medium, where people are continuing the conversation by highlighting and responding to this story.