L'intégration Continue

Buts et Intérêts

L'intégration continue peut être mal perçue dans le monde de l'entreprise. Il arrive que certains développeurs sont réticents à la mettre en place car ils pensent que c'est une perte de temps, que cela va rallonger la phase de développement. Il est vrai que c'est une contrainte assez forte car il faut respecter le cycle et écrire des tests. Mais cette contrainte apporte 2 grandes valeurs :

Réduction des risques

La réduction des risques est l'un des points importants du pourquoi de l'intégration continue. Comme nous l'avons vu au début, plus on découvre les erreurs tard plus cela a un coût important. Cette réduction de risques se traduit par plusieurs facteurs :

Le découplage de l'IDE permet d'éviter le problème classique du "il marche sur ma machine". En utilisant le serveur d'intégration continue, cela assure qu'il n'y a que ce que l'on a besoin pour le build.

La découverte des défauts au plus tôt se traduit par les tests de non-régression, la fréquence de builds qui doit être assez élevée. La couverture du code aide aussi à la découverte des erreurs au plus tôt. Cela permet de savoir si les développeurs ont bien écrits les tests correspondants à leur code source.

L'intégration continue apporte une meilleure visibilié du projet de part les feedbacks que le serveur d'intégration remonte.

L'intégration continue apporte aussi une plus grande qualité au projet à l'aide des outils d'inspection de code.

Non-Évènement

"I Build So Consistently."

Cette citation nous montre clairement que la philosophie de l'intégration continue est vraiment de construire constamment. Et derrière cette citation se cache en fait un moyen mnémotechnique pour savoir comment automatiser son processus d'intégration. Derrière cette citation se cache les mots suivants :