« Less - Intégration continue » : différence entre les versions
De Wiki Agile
| Ligne 204 : | Ligne 204 : | ||
* au nombre d’étapes | * au nombre d’étapes | ||
''' | '''À 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. | ||
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. | ||
''' | '''À choisir entre promotion automatique ou manuelle''' - laisser le système d’intégration continue à l’écoute de la ligne principale à chaque étape créé de la pagaille. Lorsqu’un développeur fait une erreur, toutes les étapes plantent les unes après les autres. Un système d’intégration continue de haut niveau se déclenche à l’annonce qu’un composant peut être utilisé. Ce type d’annonce s’appelle une ''promotion'' et s’effectue en étiquettant (ou en marquant) le composant. Promouvoir un composant peut se faire de manière automatique ou manuelle [http://damonpoole.blogspot.sg/2007/12/multi-stage-continuous-integration.html Poole08]. Avec une promotion automatique le système d’intégration continue bas niveau promeut un composant juste après l’arrivée de celui-ci. De manière générale, évitez la promotion manuelle où l’équipe décide quand le composant est “assez bon”. | ||
''' | '''À choisir entre déclenchement évènementiel ou temporel''' - chaque système d’intégration continue est déclenché soit par un événement ou à un moment précis. Les systèmes d’intégration continue bas niveau sont toujours déclenchés par un événement - l’enregistrement du code. Pour les systèmes d’intégration continue de haut niveau, le déclencheur est soit la promotion d’un composant ou un moment donné précis. Le déclenchement par promotion est plus rapide, mais pour des compilations qui prennent du temps, cela ne vaut pas le coup de faire des efforts supplémentaires dans des actions de configuration et de maintenance. Une compilation haut niveau quotidienne pourrait s’avérer suffisante [http://www.odd-e.com/material/2008/crosstalk/200805-Vodde.pdf Vodde08]. Par exemple, un groupe produit distribué avec lequel nous avons collaboré, travaille avec des systèmes d’intégration continue bas niveau déclenché par code, un système d’intégration continue plus haut niveau déclenché par promotion, et une compilation quotidienne exécutant les tests qui dure huit heures. | ||
''' | '''Au nombre d’étapes''' - la taille du produit et la présence de code déjà existant déterminent le nombre de niveaux nécessaires pour les systèmes d’intégration continue. Les étapes habituelles sont | ||
* ''l’échelon composant rapide'' - correspond à un système d’intégration continue bas niveau très rapide pour avoir des retours d’informations rapides. Il exécute les tests unitaires, la couverture de code, l’analyse statique et les indicateurs de complexité | * ''l’échelon composant rapide'' - correspond à un système d’intégration continue bas niveau très rapide pour avoir des retours d’informations rapides. Il exécute les tests unitaires, la couverture de code, l’analyse statique et les indicateurs de complexité | ||