Le code vert dans Jenkins est-il suffisant ?

Si vous n’êtes pas familier avec Jenkins, c’est un logiciel qui simplifie la construction d’un serveur d’intégration continue (CI) avec une interface Web. Jenkins extrait le code d’un référentiel de code source comme GitHub, puis construit ce code, le teste et fournit différents types de rapports – réussite/échec, couverture de code – à ce sujet. Jenkins n’élimine pas le besoin de créer des scripts pour des étapes individuelles, mais il offre un moyen plus rapide et plus robuste d’intégrer l’ensemble du pipeline d’outils de construction, de test et de déploiement.

Avant Jenkins, les développeurs devaient vivre la terrible expérience des builds nocturnes. La seule autre option qu’ils avaient était de construire et de tester soigneusement sur une machine locale avant de valider le code, ce qui a été fait de manière isolée sans les commits de quelqu’un d’autre. De toute évidence, il n’y avait aucune garantie que la construction survivrait à son engagement. Entrez Jenkins – une réponse directe à cette limitation.

Il est vraiment facile de démarrer avec Jenkins. Voici une courte liste des éléments de base dont vous avez besoin pour commencer :

• Implémentez le contrôle de version de votre choix, comme GitHub
• Écrivez des tests pour les éléments clés de votre base de code et traitez les tests comme du code de production.
• Obtenez un CI approprié (vous l’avez avec Jenkins) qui vous permettra d’exécuter des tests à chaque enregistrement dans le référentiel, et déploiera également vos builds.
• Considérez les différents composants de votre logiciel comme des blocs de construction qui doivent s’adapter et fonctionner ensemble pour devenir quelque chose de significatif. Il ne suffit pas qu’un morceau de code spécifique fonctionne bien par lui-même. Il doit bien s’intégrer à tout le reste grâce à l’intégration continue.

Jenkins vous donne un retour rapide (relativement parlant) sur les builds cassés, ce qui est très bien mais seulement si ces bogues sont détectés et traités immédiatement. Habituellement, ces bogues sont balayés sous le tapis parce que votre objectif est de respecter les délais de déploiement. Toute l’équipe doit s’engager pour une qualité élevée et comprendre l’importance de résoudre les problèmes immédiatement et de réduire au minimum les doutes techniques.

Tests logiciels automatisés

Voici maintenant la mouche proverbiale dans la pommade. Le problème avec les bogues dans les logiciels, c’est qu’ils cachent d’autres bogues qui cachent d’autres bogues, etc. Au fur et à mesure que les bugs s’accumulent, il devient plus difficile de les tester et de les trouver, ce qui entraîne de mauvaises surprises. Mais si divers types de tests automatisés utiles sont exécutés dans votre pipeline d’intégration continue, vous saurez quoi corriger dès qu’un test échoue. Tous les tests ne peuvent pas être automatisés et il faut du temps pour automatiser ce qui peut l’être, mais cela vous aide à développer des logiciels de manière durable et à maintenir la dette technique au minimum.

Désormais, lorsque nous parlons de CI et de livraison continue, il ne suffit pas simplement d’automatiser les tests et de les alimenter dans Jenkins. Ce que vous devez également faire, c’est créer les bons types de tests conviviaux et aider à répondre aux attentes des clients – essentiellement, concevoir et automatiser les bons types de tests. L’écriture de tests qui examinent le code à différents niveaux est souvent ignorée, tandis que les tests incomplets sont abandonnés et ne sont jamais réécrits.

Alors, que devrais-tu faire? Passez beaucoup de temps à rédiger des tests réels, complets et utiles. L’effort supplémentaire portera ses fruits plus tard et vous fera gagner du temps sur le débogage des problèmes qui auraient pu être détectés par les tests. Vous pourriez passer le temps de débogage à écrire du code pour de nouvelles fonctionnalités à la place.

Réfléchissez stratégiquement pour identifier le type de test qui vous donnera les meilleurs résultats. Les tests unitaires doivent être écrits pour vérifier votre implémentation des fonctions, les tests d’intégration pour faire fonctionner différents composants ensemble, tandis que les tests d’acceptation valideront les exigences commerciales importantes. Même lorsque tous vos tests sont prêts, effectuez des tests exploratoires pour découvrir des problèmes que même Jenkins (automatisation) pourrait manquer. Construire un logiciel de haute qualité est très complexe et le faire correctement est difficile mais impératif. L’utilisation des bons outils aide les programmeurs sur la bonne voie et soutient le processus de développement.

Une autre chose que je voudrais souligner est que plus il est facile de tester quelque chose, plus il est facile de déterminer sa qualité. Donc, si votre code est écrit d’une manière qui ne permet pas d’écrire des tests, il sera très difficile de tester et de supprimer les bogues.