GitHub Dependabot en action | Meilleure programmation

J’ai utilisé cet outil génial sur 20 projets open-source au cours des deux dernières années. Voici mon avis

Problèmes typiques Ça dépend les solutions vont de la mise à jour des dépendances directes en amont lorsqu’elles reçoivent une version de correctif à la propagation des vulnérabilités de sécurité que vos projets en amont ont déjà corrigées. Si vous disposez d’un minimum de temps et que vous n’avez pas toute une équipe de personnes pour gérer les dépendances, Dependabot est une solution pour vous.

Si vous avez plus de 10 à 20 dépendances dans un projet avec plus de 30 à 50 000 lignes de code, vous devez prendre au sérieux les dépendances open source. Les prendre au sérieux est également proportionnel au nombre de référentiels dont vous disposez.

Mais ne tenez pas compte de cette dernière ligne : vous devez prendre les dépendances open source au sérieux, quoi qu’il arrive. Si vous voulez lire mon avis détaillé à ce sujet, veuillez lire l’article suivant :

Assurez-vous d’avoir suffisamment de couverture de tests automatisés. C’est la première chose et la plus importante car chaque fois qu’il y a un nouveau changement en amont n’importe où dans votre arbre de dépendances, Dependabot crée une demande d’extraction dans votre référentiel. Cela fonctionne de la même manière pour les référentiels publics et internes.

Super, et maintenant ? Souvent, il y a plus d’un PR de Dependabot, il est donc recommandé de reporter au moins 15 à 30 minutes pour réviser le code de chaque modification entrante. La première chose à laquelle vous devez prêter attention est le journal des modifications qui fait partie de la description. Cela devrait vous donner une première idée de savoir si ce changement casse votre projet.

Je recommanderais également de lire le diff complet du changement en amont car il vous offrira deux avantages. Tout d’abord, vous vous familiariserez avec les choses dont vous dépendez. La seconde est que vous saurez précisément ce qui a été changé, donnant un aperçu de ce qui pourrait avoir causé la casse potentielle. Je l’ai appris à la dure, donc vous n’avez pas à le faire.

Une couverture de test unitaire supérieure à 70 % est recommandée avant d’intégrer Dependabot. Plus la couverture de test est importante, plus les chances de détecter un problème lors d’une bosse de dépendance sont grandes. Vous pouvez suivre la couverture du code avec des services tels que codecov.io. Il automatise le signalement des changements de couverture par le biais de commentaires de demande d’extraction.

Habituellement, Dependabot fournit plus d’une demande d’extraction à chaque fois qu’il s’exécute. Je recommande de les fusionner séquentiellement – l’un après l’autre. Cela vous donnera l’assurance qu’il n’y a pas de conflit de dépendance global. Plus vous avez de couverture de test unitaire, plus vous accepterez ces changements avec confiance.

L’écrasement est le meilleur moyen de fusionner car chaque bosse de dépendance apparaît comme un seul commit dans l’arborescence source. Super, vous avez fusionné un PR parmi tant d’autres. Maintenant, que faire des autres bosses de dépendance ? Dependabot détecte généralement les changements dans la branche principale en amont et essaie de recréer ou de rebaser automatiquement une demande d’extraction. Cependant, je ne trouve pas que cela se produise assez rapidement, alors je mets à jour la branche manuellement.

Je n’ai pas encore trouvé d’API REST publique GitHub simple pour l’automatiser. Mais je ne me plains pas encore beaucoup; il ne faut pas plus de 1 à 2 heures par semaine pour maintenir toutes les dépendances à jour partout.

À quelle fréquence devez-vous le programmer pour qu’il s’exécute ? Ma recommandation sera un cycle quotidien : cela garantira que les vulnérabilités de sécurité sont corrigées assez rapidement et répartissent votre temps de révision du code uniformément sur la semaine. Si le projet en amont change plus fréquemment que vous ne parvenez à modifier les versions, n’ayez crainte : Dependabot est assez intelligent pour gérer même cela.

Alors, quelle couverture de test unitaire le projet doit-il avoir pour être prêt pour ce type d’automatisation ? C’est si difficile à dire. Par exemple, je suis responsable de la maintenance d’un relativement grand Fournisseur Terraform avec 10 millions de téléchargements. Il a une couverture de test unitaire de 90% avec toutes les contributions externes. Une fois que Dependabot a introduit une modification du SDK en amont, les tests unitaires ont très bien réussi.

Quelques jours plus tard, j’ai vu un rapport de bogue indiquant que la dernière version de la version s’était écrasée avec un défaut de segmentation. Heureusement, je publie le projet presque toutes les deux semaines, et il est simple de diviser en deux les changements apportés aux candidats les plus probables. Si vous relâchez si souvent, votre surface de changement est généralement petite. Il est apparu immédiatement que la raison du crash s’est produite après avoir examiné le diff dans le changement en amont – mon exception de pointeur null préférée, où les développeurs oublient de programmer de manière défensive et ne vérifient pas si les objets sont correctement initialisés. J’ai immédiatement annulé la bosse et créé une nouvelle version après la réussite des tests d’intégration. La morale de l’histoire:

Si vous dépendez d’autres projets avec une couverture de test unitaire inférieure, vous devez espérer le meilleur et planifier le pire. Une couverture de 90 % ne peut pas vous sauver de situations comme celle-ci. Ce qui vous fera économiser, c’est la vitesse à laquelle vous pouvez faire une nouvelle version en toute confiance.

Le Dependabot est excellent pour l’écosystème open source car il le rend plus sécurisé et dynamique. Chaque projet avec lui est vivant (ou semble vivre en surface). Commencez à l’utiliser dès maintenant.