J’ai déjà eu l’occasion d’écrire des articles sur les outils qui permettent de détecter les vulnérabilités des dépendances ou qui permettent de mettre à jour automatiquement les dépendances.
J’ai aussi eu l’occasion d’en discuter, voire d’en débattre avec d’autres développeurs. Une des objections qui revient souvent est que ces outils sont attirants mais inutilisables dans la vraie vie, personne n’est assez fou pour mettre à jour automatiquement ses dépendances.
Il se trouve que je le fais depuis plus d’un an, je vais donc aujourd’hui expliquer comment cela se passe concrètement.

Avant Propos

La gestion des dépendances est avant tout une question de gestion des risques. En particulier deux d’entre eux. Le premier est celui de connaître une panne à cause d’une régression ou d’un bug. Le second est celui d’avoir une attaque informatique ou une fuite de données à cause d’une vulnérabilité exploitée par un hacker. Il est moins fréquent que ce dernier arrive, mais son impact est considérable. Le premier a un impact moindre, bien qu’important. Heureusement, certaines conditions permettent de réduire la probabilité qu’il survienne, je vais vous en présenter quatre.

Langage Compilé

La première chose qui m’aide est que j’utilise Go, un langage compilé. Il y a plusieurs avantages à utiliser un langage compilé, en comparaison avec un langage interprété. L’un des principaux avantages est que les langages compilés s’exécutent généralement plus rapidement que les langages interprétés, car le code est traduit directement en langage machine. Langage que l’ordinateur peut exécuter directement.
L’autre avantage est que la phase de compilation détecte des erreurs, par exemple l’utilisation du mauvais type de données. Par conséquent, ces erreurs ne surviennent pas au runtime car elles sont identifiées avant cela. Dans le cadre de la mise à jour de dépendances cela est diablement utile !

Tests & Observabilité

Deux autres aspects sont cruciaux, les tests et l’observabilité. Actuellement nous avons une couverture d’environ 55% sur nos tests unitaires. C’est toujours trop peu à mon avis, mais cela assure toutefois un bon filet de sécurité. Des bugs triviaux sont ainsi évités en lançant systématiquement ces tests sur nos pipelines de CI/CD.
D’autre part, nous avons un environnement de recette solide. C’est-à-dire que cet environnement de test réplique fidèlement l’environnement de production, il est stable et il reçoit un trafic suffisant. Ainsi, des bugs plus complexes seront découverts sur cet environnement.
Enfin l’observabilité n’a pas été négligée. Nous avons des metrics sur nos différentes briques d’infras, des metrics métier et des alertes de configurées. Si une de ces metrics se met à dépasser le seuil défini, nous sommes immédiatement notifiés.

Continuous Delivery

Autre point important, nous livrons fréquemment en production. Quel est l’intérêt ? En déployant fréquemment les changements apportés sont plus petits et plus faciles à gérer. De plus, en cas de problème, il est plus facile de trouver d’où vient le problème car les changements apportés sont moins nombreux et plus récents.
Typiquement, nous déployons en production trois fois par semaine. Techniquement nous pourrions le faire plus souvent, mais comme nous sommes deux développeurs sur cette stack, le nombre de changements ne justifie pas de déployer plus souvent.

Facilité de rollback

Dernière chose importante, nous sommes capables de rollback rapidement. Le fait de pouvoir effectuer un rollback, c’est-à-dire annuler un déploiement, permet en cas de problème de revenir à la version précédente de l’application, qui était fonctionnelle. Effectuer ce rollback rapidement est donc crucial pour maintenir la disponibilité et la qualité de l’application.
Concrètement, nous sommes en mesure de rollback en moins de cinq minutes. Ceci est rendu possible principalement par l’utilisation de tags de release sur notre repo. Par le passé nous avons utilisé une branche de release, mais comme cela rendait les rollbacks plus lent nous avons changé pour les tags.

Si tu es arrivé jusqu’ici, merci beaucoup d’avoir lu cet article !
Pense à t’abonner à la mailing list pour ne rater aucun article, le formulaire se trouve en bas de page.
Photo de couverture par Bernd Dittrich.