« Less - Intégration continue » : différence entre les versions

'''Vitesse des cycles de retours d’informations''' - un développeur ne devrait intégrer que les changements qui ne cassent pas les tests existants. Idéalement, il fait tourner tous les tests avant l’intégration. Pour que cela soit possible, les tests doivent être exécutés très vite. Si les tests sont lents, le développeur retardera l’intégration pour “travailler plus efficacement”. Toutefois, exécuter tous les tests rapidement c’est difficile sur de gros systèmes. Par conséquent, les développeurs exécuteront uniquement un sous-ensemble des tests avant d’enregistrer et un système d’intégration continue exécutera les tests restants. Le système d’intégration continue agira comme un filet de sécurité en donnant au développeur des retours d’informations sur les tests qu’il n’a pas lui-même exécuté. Que se passe t’il quand le système d’intégration est lent ? Premièrement, il y aura beaucoup de changements pendant le premier cycle, augmentant la probabilité que le compilation casse. Deuxièmement, les développeurs n’intègrent pas leurs changements dans une compilation qui est cassée ; à la place, ils les lotissent. À la fin, quand la compilation est corrigée, tous les développeurs intègrent leurs changements lotis, cela ayant pour conséquence d’augmenter encore les probabilités de casser à nouveau la compilation. Par conséquent, le cycle filet de sécurité-retours d’informations se doit d’être rapide. Cela diminue la probabilité de casser la compilation et augmente la capacité d’enregistrer (check-in) plus fréquemment.

Sur de gros produits, cela prendra du temps d’apprendre à fractionner les changements, de simplifier le processus d’intégration, et de mettre en place un système d’intégration continue rapide et opérationnel …