|

Quand personne ne répare la CI, ce n'est pas un bug. C'est un choix.

J’ai connu des équipes dans lesquels, quand on arrivait le matin, on pouvait constater que la branche principale était cassée depuis plusieurs jours. La CI (eg. l’intégration continue) échouait en continu, et personne dans l’équipe ne semblait s’en inquiéter.

Quand on vit cette situation, ce n’est plus un problème technique, c’est un problème de culture.

Ce billet a été initialement publié sur LinkedIn
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.

Quand une CI cassée devient la norme (et ça arrive plus souvent qu’on ne le croit), c’est que l’équipe a progressivement appris à l’ignorer. J’en ai déjà parlé plusieurs fois, mais ce que l’on tolère devient un standard.

Une pipleine rouge que personne ne corrige, c’est un signal silencieux envoyé à toute l’équipe: “ce n’est pas grave”. Et ce signal s’installe durablement.

Pourtant, une intégration continue est le filet de sécurité collectif. C’est ce qui garantit que le code partagé est dans un état stable et déployable à tout moment. Laisser ce filet trouvé, c’est avancer sans protection en espérant que rien ne tombe.

Le problème n’est pas la CI qui casse, cela peut arriver et c’est presque normal et rassurant. Ce qui est inquiétant, c’est l’absence de réaction. Une branche principale cassée devrait déclencher une mobilisation immédiate, pas une résignation silencieuse.

Restaurer l’état de la branche principale devrait être LA priorité numéro une de toute équipe. C’est une règle simple, mais elle en dit beaucoup sur la manière dont une équipe traite la qualité au quotidien.

Une CI verte en permanence, ce n’est pas du perfectionnisme. C’est l’assurance de travailler sereinement et de livrer avec un minimum de confiance.

Jérémy DECOOL

Jérémy DECOOL

Développeur depuis plus d'une décennie, je partage mes réflexions sur les bonnes pratiques de développement et d'architecture logicielle.