Par Maxime Ancellin.
Aujourd’hui, j’ai l’occasion de faire mon premier « blog post » !
Notre sujet du jour sera la gestion des dépendances automatisée et ses cas d’usage.
Il est vrai que les cas d’application sont ce qui est le plus intéressant à voir quand on parle d’un outil ou d’une technologie.
Nous connaissons tous plusieurs outils qui nous aident au quotidien.
En revanche, nous n’avons pas tous les mêmes besoins, c’est là que l’expérience entre en jeu pour déterminer ce qui nous correspond le mieux.
Cette publication est donc basée sur un retour d’expérience et remit en forme pour s’adapter à un billet de blog.
Au travers de ce sujet, nous souhaitons répondre aux questions suivantes:
Si vous vous posez ces questions, vous êtes au bon endroit !
Avant de commencer, qu’est-ce qu’on appelle une dépendance ?
Dans nos métiers techniques, nous travaillons avec de nombreux concepts et outils.
Lors d’un projet, on pourrait recoder l’ensemble des élément nécessaire à son bon fonctionnement, mais cela serait fastidieux et très difficile à maintenir dans le temps (beaucoup de code et connaissance à gérer).
Pour pallier à cela, on utilise tout un ensemble de ressources qui sont partagées par des entreprises ou la communauté et que l’on peut inclure/utiliser dans nos projets.
C’est donc cela qu’on appelle des dépendances.
La plupart des langages/technologies récentes utilisent des gestionnaires de dépendances afin d’orchestrer les différentes ressources et leurs versions.
On peut facilement citer :
Concernant les dépendances, il en existe une infinité.
Voici un exemple de packages particulièrement populaires :
Les solutions évoquées ci-dessus sont très liées à l’environnement du monde du développement.
Avec la méthodologie DevOps, le monde de l’infrastructure s’en rapproche de plus en plus.
Les solutions permettant de déployer les infrastructures “As Code” utilisent également les mêmes principes.
C’est le cas de :
Voici une petite illustration qui schématise comment cela fonctionne dans le cadre d’un projet applicatif.
Les dépendances ont de nombreux d’avantages et permettent de grandement simplifier notre travail.
Mais elles créent également une vraie problématique dans le maintien à jour et la correction des failles de sécurité des packages que l’on utilise.
On peut utiliser les outils (npm, pip, etc…) pour les mettre à jour, mais cela implique une démarche manuelle.
Dans un univers avec de nombreux projets Git et de micro-services, cela représente beaucoup de travail pour maintenir l’ensemble des éléments à jour.
C’est ici que notre sujet commence.
Pour répondre à cette problématique, il existe des outils permettant de faire ce travail à votre place.
De nombreuse solution sont présente sur le marché, mais nous allons ici parler uniquement des deux principaux.
Ce sont les deux solutions largement adoptées par la communauté.
En effet, elles permettent une installation rapide et ne demandent pas forcément de configuration.
C’est un outil spécifiquement conçu pour être utilisé dans le cadre d’une utilisation avec GitHub, en mode SaaS (Software as a Service).
Avec cette intégration directe à GitHub, DependaBot offre une solution clé en main pour la gestion des dépendances, permettant ainsi une optimisation du flux de travail, une plus grande efficacité et une sécurité renforcée.
La force de DependaBot est sa grande simplicité et son intégration très rapide à vos projets GitHub.
Tout comme DependaBot, il est conçu pour être utilisé en mode SaaS sur GitHub (pour la version Mend.io).
Il existe également en version Open Source et permet d’héberger soi-même Renovate via un conteneur dans une pipeline de CI/CD, sur un orchestrateur de conteneurs ou une installation sur une machine via NPM.
Cela permet donc une meilleure confidentialité et une maîtrise plus fine de la gestion des credentials.
Les forces de Renovate :
Cependant, il peut être plus complexe à configurer, mais offre une grande liberté.
Vous l’aurez compris, c’est Renovate l’outil que je recommande pour répondre à notre problématique.
Sa grande flexibilité, le fait de pouvoir l’héberger soi-même et d’avoir le code Open Source sont très clairement des avantages.
Voici comment il fonctionne :
Comme évoqué précédemment, le temps consacré à la gestion manuelle des packages n’est pas du temps où nous pouvons effectuer des tâches à valeur ajoutée.
Néanmoins, nous sommes contraints d’effectuer ces tâches pour des raisons de Sécurité ou de Dette technique, ou alors les ignorer (Évidemment, je ne recommande pas, l’offuscation est rarement la bonne solution.)
D’un point de vue de la sécurité, cela nous permet de suivre les mises à jour en continu.
Par conséquent, on peut même demander à Renovate de merger automatiquement les nouveaux « patch » afin de garantir que les correctifs soient bien appliqués.
Attention, cela peut engendrer de la casse si les évolutions de vos dépendances ne sont pas fiables.
Maintenant, que l’on n’a plus besoin de passer sur chaque projet pour lancer nos commandes permettant la mise à jour des packages, on peut se consacrer à la production de code.
De plus, avec une bonne chaîne de CI/CD, nous pouvons également nous assurer que les évolutions n’introduiront pas de régression.
Cela signifie que la dette technique sur les packages ne devrait plus s’accumuler, voire même finir par être résorbée.
Attention, lors de la mise en place, il est fort possible d’avoir beaucoup de « Pull Requests » générées.
Il faut pouvoir absorber la charge de travail ou alors préférer activer les niveaux/fonctionnalités de Renovate de manière progressive.
Si vous souhaitez intégrer Renovate (ou DependaBot pour GitHub) sur vos projets, vous pourrez trouver la marche à suivre sur les liens ci-dessous.
Maintenant que votre Bot Renovate est configuré sur votre instance Git.
Nous allons voir comment le configurer pour des usages standard.
Vous avez dû le remarquer, mais suite à l’intégration de l’outil, une Pull Request a été faite sur l’ensemble de vos « repository Git » afin d’ajouter un fichier renovate.json qui intègre la configuration à appliquer sur votre repo.
Le fichier créé par Renovate est la configuration de base.
Vous pouvez retrouver les informations relatives à celle-ci sur la page presets de leurs GitHub.
Comme je l’évoque plus haut, il n’est pas toujours évident d’absorber l’ensemble des « Pull Request » qui seront proposés par Renovate lors de la mise en place de celui-ci.
Nous avons donc la possibilité d’activer les fonctionnalités que l’on souhaite.
Par exemple, ci-dessous, nous activons uniquement la prise en charge des Dockerfile
{
"enabledManagers": [
"dockerfile"
]
}La liste des managers est disponible sur la documentation.
Vous pouvez également, ajouter un certain nombre d’automatisations comme assigner des personnes pour la relecture, merger automatique certaines mise à jour.
Voici un exemple de configuration étendu.
{
"packageRules": [
{
"matchManagers": ["github-actions"],
"commitMessageTopic": "Chore(ci): {{depName}} update",
"automerge": true,
"automergeType": "pr-comment",
"automergeComment": "LGTM !"
}
]
}Si dessus, nous définisson une configuration particulière pour les « Pull requests » sur la partie « GitHub actions ».
Nous avons défini les éléments suivants:
github-acitonsChore(ci): {{depName}} updateLGTM !Vous pouvez retrouver l’ensemble des configurations de Renovate sur la documentation officielle.
Evidemment, on n’a pas envie de faire notre configuration sur l’ensemble de nos projets Git.
On retomberait dans une certaine mesure dans le cas où il est compliqué de gérer l’ensemble des dépendances sur tous les projets Git.
Pour cela nous pouvons créer dans un projet Git, un ensemble de configurations partagées (un peu comme celle fourni par Renovate).
Cela nous permettra depuis les autres projets d’utiliser une seule et même configuration et donc de travailler sur un seul fichier pour tous nos projets.
On pourra alors utiliser la configuration ci-dessous (dans le cas où nous sommes sur GitLab):
{
"extends": [
"gitlab>MonOrganisation/mon-super-projet/renovate-bot//configurations/fichier-de-configuration-sans-extention"
]
}Vous pouvez trouver les autres configurations dans la section
config-presetsde la documentation.
Dans le prochain article, nous verrons comment utiliser Renovate dans un flux GitOps et automatiser les mises en staging/production.