Dans notre environnement micro-service constitué de beaucoup de projets différents, il est fréquent de retrouver certains besoins en termes de tests unitaires. Lors de notre passage à Junit 5, nous en avons profité pour mettre au propre nos outils de test pour pouvoir les Open Sourcer.

On est prêts à faire mille fois une requête, mais on n’aime pas faire les choses 1000 fois.

Le respect de ce mantra passe par l’automatisation (ansible, script, pipeline…) mais aussi par bien choisir ses outils au départ afin d’éviter certaines déconvenues (comme de devoir le changer rapidement).

Cet article, va vous présenter le process de décision technique en place dans l’équipe, comment on prend le temps de poser le besoin avant de déployer un outil, afin de trouver le plus adapté à nos usages.

Comme beaucoup d’autres équipes, nous avons été confrontés à la maintenance de legacy peu documenté et, force est de constater que cela coûte cher. C’est pourquoi, pour tous nos services, nous avons mis en place une javadoc et une documentation d’API REST générées à partir du code, lors du build. C’est la partie documentation REST que l’on présente ici avec un module Maven qui génère un fichier Swagger.

Au long de ma carrière, j’ai eu l’occasion de connaître des modes de travail différents. Des équipes auto-gérées et des équipes procédurières, avec ou sans lead, avec ou sans process.