Les bienfaits de l’intégration continue

tvbChez TalentSoft, nous avons mis en place notre serveur d’intégration il y a maintenant 2 ans. Je n’avais jamais pris le temps d’en parler sur ce blog car il m’avait toujours semblé raisonnable, et plutôt anodin, de capitaliser sur nos tests unitaires, ainsi que sur nos tests d’intégration pour en tirer le maximum.

Seulement voila, je viens d’avoir une discussion avec un ami, consultant chez un gros compte, qui ne parvient pas à faire passer l’idée d’écrire des tests unitaires et de les déployer sur un serveur d’intégration. Les raisons invoquées sont que cela est trop coûteux et qu’il n’y a pas le temps de réaliser ces tests. Ahah! Facile! Qui peut prétendre avoir le temps de prendre le temps sur un projet informatique de nos jours?

En fait, je ne réalisais pas avant cette conversation qu’il était encore nécessaire de prouver l’efficacité d’un serveur d’intégration.

Pour la R&D de TalentSoft, les bénéfices ne sont plus à prouver et sont constatés par chaque développeur plusieurs fois par mois. Dans le bureau, ça donne ça:

  • Clément: le « nightly » est rouge ce matin, c’est ton « commit », Julien, qui a créé une régression dans la page d’administration.
  • Julien: ok  je corrige, on valide et je « commit ».
wtf

Je corrige mon bug…

Qui plus est, sans cette solution, la société aurait déjà perdu tous ses clients puis fermé ses portes. Chez nous, le serveur d’intégration n’est qu’un maillon d’une chaîne Qualité plutôt réfléchie, et qui garantit un taux d’anomalie en production très faible.

Il va de soi qu’écrire des tests unitaires est difficilement valorisable sans la mise en place d’un serveur d’intégration.

  • Pourquoi?
  • Car cela sous entend que le jeu des tests est manuel. or, ça prend du temps si on joue tous les tests unitaires du produit…
  • Pas grave, je ne vais jouer que les tests unitaires qui concernent mon code…
  • Euh oui… bonne idée… ah non! imagine que ta modification de code impacte une classe (située fonctionnellement) à l’autre bout de l’appli?
  • ah oui…
  • et tu vas passer plus de temps à filtrer tous les classes clientes de ta classe pour finalement ne jouer…
  • ok, je joue tout!

Petit aparté: Ouais… bon, on ne va pas rentrer dans les détails, dans cet article, de ce que devraient être de bons tests unitaires sur le code que je modifie. Car en vérité,  je ne devrais pas avoir besoin de lancer les tests unitaires d’autres classes pour constater que la classe que j’ai modifiée plante lamentablement. Si j’ai une couverture (fonctionnelle) de 100% du code modifié, je vérifie donc tous mes contrats publics et je n’ai pas besoin que des composants externes valident mon code interne. D’où le terme test unitaireMais il y a théorie et pratique. Enfin passons!

Le principal intérêt des tests unitaires, conjointement avec le serveur d’intégration (Je ne parle pas dans cet article de l’intérêt des tests unitaires en utilisant TDD dans la qualité du développement) est le timing de l’identification des anomalies et des régressions et donc du timing de résolution.

  • Ah bon? Quel timing?
  • Eh bien… bien avant la release, enfin au plus tard le lendemain une fois que le commit a été autorisé.
  • oui enfin, moi je peux trouver le bug encore avant en testant manuellement avant le commit justement.
  • Bravo! D’un autre côté, le serveur d’intégration ne t’autorise pas à être moins regardant sur ton travail. Mais c’est un filet de sécurité supplémentaire. Aussi, la semaine prochaine, tu vas reprendre cette classe pour y coder une évolution. Tu vas jouer de nouveau entièrement ton cahier de test manuellement (oui on considère que le développeur mutualise ses tests, c’est un développeur consciencieux).
  • Bah oui.
  • Ok. Et la semaine d’après tu vas corriger une anomalie signalée par le client. On ne discute pas de comment elle a pu arriver en production 🙂 Tu vas rejouer tout ton cahier de test?
  • Euh, ça prend combien de temps de mettre en place ton serveur de test?

Bon, ça ne prend pas énormément de temps de mettre en place un tel serveur. Environ une semaine pour avoir une solution clé en main pour l’équipe de développement, c’est à dire: faire la chose proprement. Après, il ne faut pas se leurrer, une ressource sera consommée de temps à autre pour la maintenance du serveur, les évolutions, les mises à jour… mais ça peut rester vraiment léger pour garder une solution agréable et utile.

La valorisation des tests automatisés par un serveur, est un avantage indéniable dans les cycles de développement d’un produit. Chez TalentSoft, l’écriture des tests, unitaires et d’intégration, nous coûte en moyenne 20% de notre chiffrage de développement.

En contrepartie, on évite:

  • à une anomalie d’être corrigée 10 fois.
  • de perdre le temps de se remettre dans le projet quand une personne du support traite l’anomalie longtemps après que la fonctionnalité ait été codée (cas de la régression impactée par un composant transverse par exemple).
  • qu’une autre régression soit créée lors de la correction et ainsi de reperdre le temps d’un cycle de correction.
  • à des testeurs fonctionnels de devoir passer du temps à jouer des cahiers de tests détaillés. On préférera ne cibler que ce qui n’est pas couvert par nos tests automatisés…

En conclusion, on évite de perdre beaucoup de temps.

Advertisements

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s