« Less - Intégration continue » : différence entre les versions
De Wiki Agile
| Ligne 46 : | Ligne 46 : | ||
Fractionner les changements en petits incréments, les intégrer quotidiennement à minima, et avoir la discipline de ne pas casser la compilation, tout cela est fait par chaque développeur individuellement. Chaque développeur doit être en capacité de travailler en petits incréments et pouvoir conserver sa propre copie du système (ou une partie du système) opérationnelle à tout instant. | Fractionner les changements en petits incréments, les intégrer quotidiennement à minima, et avoir la discipline de ne pas casser la compilation, tout cela est fait par chaque développeur individuellement. Chaque développeur doit être en capacité de travailler en petits incréments et pouvoir conserver sa propre copie du système (ou une partie du système) opérationnelle à tout instant. | ||
Adopter l’intégration continue exige un ''changement de comportement''. Nous avons travaillé au sein | Adopter l’intégration continue exige un ''changement de comportement''. Nous avons travaillé au sein d'une organisation sur plusieurs gros produits avec un très bon outil de compilation automatisée mais les développeurs n’intégraient pas leur code fréquemment. En effet, partout le message “TU ne casseras PAS le fruit de la compilation” était proclamé haut et fort, en clouant au piloris, par exemple, les personnes qui auraient osé casser la compilation. Et qu’est-ce qui devait arriver ? Les développeurs retardaient leur intégration par peur de casser la compilation. En dépit d’un indicateur toujours au vert (toujours passant) de la compilation automatisée, ils faisaient l’exact inverse d’une démarche d’intégration continue. | ||
Le développement piloté par les tests (ou TDD pour l’acronyme en vo - NdT) avec un ''refactoring'' (acte de remanier le code en vue de l’améliorer - NdT) constant aide beaucoup. Lorsqu’un développeur développe son code par des tests unitaires, il s’assure que sa copie locale est toujours en état de marche. Tous les tests passent tout le temps. En théorie, il est donc capable d’intégrer son code à chaque tour de cycle de TDD (environ toutes les dix minutes [^2]) ; en pratique, il intègre tous les deux tours de cycle. | Le développement piloté par les tests (ou TDD pour l’acronyme en vo - NdT) avec un ''refactoring'' (acte de remanier le code en vue de l’améliorer - NdT) constant aide beaucoup. Lorsqu’un développeur développe son code par des tests unitaires, il s’assure que sa copie locale est toujours en état de marche. Tous les tests passent tout le temps. En théorie, il est donc capable d’intégrer son code à chaque tour de cycle de TDD (environ toutes les dix minutes [^2]) ; en pratique, il intègre tous les deux tours de cycle. | ||
