0%
Automatiser ce qu'on refait à la main

Introduction

Le vocabulaire de l'intégration continue, et le critère pour choisir quoi automatiser.

10-15 min

Sur un dépôt sans intégration continue, la qualité repose sur une phrase que personne n'a écrite : « avant de pousser, lance les tests ». Elle tient quelques semaines. Puis un vendredi soir, quelqu'un pousse un correctif d'une ligne sans les lancer, parce qu'une ligne ne casse rien. Le lundi, la branche principale est rouge, trois personnes ont déjà tiré dessus, et il faut une demi-journée pour distinguer le commit fautif des commits qui n'ont fait que travailler par-dessus. Le coût réel n'est pas le test manquant, c'est le délai entre l'erreur et sa découverte.

L'intégration continue attaque exactement ce délai. Elle déplace la vérification du poste du développeur vers une machine neutre qui l'exécute à chaque poussée, sans exception, sans dépendre de la discipline de personne. Elle apporte trois choses qu'aucune convention d'équipe ne donne : la reproductibilité, parce que l'environnement est décrit dans un fichier versionné plutôt que dans un poste de travail ; la trace, parce que chaque exécution laisse un journal daté et rattaché à un commit précis ; et la contrainte, parce qu'un résultat rouge peut bloquer une fusion, ce qu'un rappel oral n'a jamais fait.

Commentaires

Les commentaires sont alimentés par GitHub Discussions

Connectez-vous avec GitHub pour participer à la discussion

Lien copié !