« Less - Intégration continue » : différence entre les versions
De Wiki Agile
| Ligne 102 : | Ligne 102 : | ||
'''Capacité à fractionner des gros changements''' - fractionner des gros changements en petits changements, tout en conservant dans un état opérationnel les anciennes fonctionnalités, est une compétence qui doit être apprise. Les meilleurs développeurs sont ceux qui, dans cette perspective du fractionnement, intègrent le plus fréquemment. Le développement piloté par les tests, en cycles courts de 10 minutes, est une très bonne technique pour arriver à cela. | '''Capacité à fractionner des gros changements''' - fractionner des gros changements en petits changements, tout en conservant dans un état opérationnel les anciennes fonctionnalités, est une compétence qui doit être apprise. Les meilleurs développeurs sont ceux qui, dans cette perspective du fractionnement, intègrent le plus fréquemment. Le développement piloté par les tests, en cycles courts de 10 minutes, est une très bonne technique pour arriver à cela. | ||
'''Vitesse d’intégration''' - plus l’intégration des changements prendra du temps dans le dépôt de code, moins les développeurs le feront fréquemment. Les changements sont lotis dans un souci d’efficacité. L’effort d’intégration est impacté par le surcoût du processus (le coût de transaction), tel que les approbations et les revues nécessaires avant que les développeurs soient autorisés à intégrer. Il faut réduire ce surcoût ou trouver des manières créatives de faire les choses différemment. Par exemple, nous avons travaillé avec un groupe produit de 40 personnes dans lequel le message | '''Vitesse d’intégration''' - plus l’intégration des changements prendra du temps dans le dépôt de code, moins les développeurs le feront fréquemment. Les changements sont lotis dans un souci d’efficacité. L’effort d’intégration est impacté par le surcoût du processus (le coût de transaction), tel que les approbations et les revues nécessaires avant que les développeurs soient autorisés à intégrer. Il faut réduire ce surcoût ou trouver des manières créatives de faire les choses différemment. Par exemple, nous avons travaillé avec un groupe produit de 40 personnes dans lequel le message de réservation (check-in en anglais dans le texte pour les lecteurs plus habitués avec ce terme - NdT) devait mentionner la personne qui avait revu le code. Le résultat ? Les développeurs ont loti beaucoup de changements pour rendre les revues de code plus “efficaces” et cela a eu comme conséquence de retarder l’intégration - une optimisation locale. La solution ? Les revues de code peuvent être faites à la place sur du code intégré - ce qui a pour effet de ne pas retarder l’intégration. | ||
'''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. | '''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. | ||
