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

De Wiki Agile
Ligne 206 : Ligne 206 :
'''À ce qui est fait par un développeur''' - les développeurs pratiquant l’intégration continue doivent vérifier leurs changements avant d’enregistrer. Par conséquent, ils doivent être capables de travailler avec un sous-ensemble du système, souvent un composant, et être capables d’exécuter des tests unitaires dessus. Prenez bien cela en considération lorsque vous automatisez votre compilation.
'''À ce qui est fait par un développeur''' - les développeurs pratiquant l’intégration continue doivent vérifier leurs changements avant d’enregistrer. Par conséquent, ils doivent être capables de travailler avec un sous-ensemble du système, souvent un composant, et être capables d’exécuter des tests unitaires dessus. Prenez bien cela en considération lorsque vous automatisez votre compilation.


'''À mettre l’accent sur le composant ou la fonctionnalité''' - un système d’intégration continue à plusieurs étapes traditionnel est structuré autour des composants. Les compilations de bas niveau compilent un composant, le niveau suivant un sous-système, et le plus haut niveau compile l’ensemble du produit. Avec des équipes organisées autour des composants, l’équipe est donc aux petits soins pour son système d’intégration continue [AKB04 (originally at: http://www.cmcrossroads.com/articles/agilemar04.pdf)]; Mais où mettre les tests d’acceptation de haut niveau, et qu’en est-il des équipes feature ? Une alternative est de structurer votre système d’intégration continue autour des fonctionnalités. Lorsque quelqu’un enregistre son code, tous les systèmes d’intégration continue associés aux fonctionnalités se déclencheraient. Les tests sont maintenant exécutés en parallèle, mais le même composant est compilé plusieurs fois.
'''À mettre l’accent sur le composant ou la fonctionnalité''' - un système traditionnel d’intégration continue à plusieurs étapes est structuré autour des composants. Les compilations de bas niveau compilent un composant, le niveau suivant un sous-système, et le plus haut niveau compile l’ensemble du produit. Avec des équipes organisées autour des composants, l’équipe est donc aux petits soins pour son système d’intégration continue [AKB04 (originally at: http://www.cmcrossroads.com/articles/agilemar04.pdf)]; Mais où mettre les tests d’acceptation de haut niveau, et qu’en est-il des équipes feature ? Une alternative est de structurer votre système d’intégration continue autour des fonctionnalités. Lorsque quelqu’un enregistre son code, tous les systèmes d’intégration continue associés aux fonctionnalités se déclencheraient. Les tests sont maintenant exécutés en parallèle, mais le même composant est compilé plusieurs fois.


Un groupe produit distribué, avec lequel nous avons travaillé, mélange les deux approches. À bas niveau, le système d’intégration continue est organisé autour des composants, et le résultat déclenche les systèmes d’intégration continue des différentes fonctionnalités qui exécutent les tests d’acceptation de haut niveau en parallèle.
Un groupe produit distribué, avec lequel nous avons travaillé, mélange les deux approches. À bas niveau, le système d’intégration continue est organisé autour des composants, et le résultat déclenche les systèmes d’intégration continue des différentes fonctionnalités qui exécutent les tests d’acceptation de haut niveau en parallèle.