« Less - Intégration continue » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 211 : | Ligne 211 : | ||
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 | '''à 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 | '''à 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 | '''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 | ||
| Ligne 242 : | Ligne 242 : | ||
<blockquote>Ce n’est pas parce qu’il y a représentation visuelle qu’il s’agit de management visuel. Il est relativement facile de mettre en place de belles zones d’affichage qui seront là pour faire jolies. Le véritable défi est de les rendre “utilisables”. Parmi les gens qui visitent le site de Toyota, un certain nombre d’entre eux évoquent la différence entre leur approche et celle de Toyota. Nous entendons régulièrement des commentaires comme “Maintenant je vois, ce qui est affiché par Toyota permet vraiment d’orienter les actions au quotidien”. C’est là en effet toute la différence, et Toyota suggèrerait que si cela ne sert pas à orienter les actions au quotien alors autant s’en débarrasser. | <blockquote>Ce n’est pas parce qu’il y a représentation visuelle qu’il s’agit de management visuel. Il est relativement facile de mettre en place de belles zones d’affichage qui seront là pour faire jolies. Le véritable défi est de les rendre “utilisables”. Parmi les gens qui visitent le site de Toyota, un certain nombre d’entre eux évoquent la différence entre leur approche et celle de Toyota. Nous entendons régulièrement des commentaires comme “Maintenant je vois, ce qui est affiché par Toyota permet vraiment d’orienter les actions au quotidien”. C’est là en effet toute la différence, et Toyota suggèrerait que si cela ne sert pas à orienter les actions au quotien alors autant s’en débarrasser. | ||
</blockquote> | </blockquote> | ||
Sur les produits de taille importante, il s’avère encore plus difficile de fractionner de gros en petits changements. Les développeurs veulent quelques fois restructurer ou ré-architecturer leur système existant et sont convaincus que cela doit être fait en un seul gros changement. Mais nous n’avons pas encore vu de gros refactoring qui ne pourraient être fait graduellement. À chaque fois, après discussion avec les développeurs, nous avons trouvé des moyens de fractionner ce gros refactoring qui-ne-pouvait-pas-l-être. | Sur les produits de taille importante, il s’avère encore plus difficile de fractionner de gros en petits changements. Les développeurs veulent quelques fois restructurer ou ré-architecturer leur système existant et sont convaincus que cela doit être fait en un seul gros changement. Mais nous n’avons pas encore vu de gros refactoring qui ne pourraient être fait graduellement. À chaque fois, après discussion avec les développeurs, nous avons trouvé des moyens de fractionner ce gros refactoring qui-ne-pouvait-pas-l-être. [http://www.amazon.com/Refactoring-Large-Software-Projects-Restructurings-ebook/dp/B0014ELAZA RL06]. | ||
Les changements d’interface sont un problème assez répandus dans les gros systèmes. Beaucoup de composants utilisent des interfaces et doivent être modifiés en conséquence - ce qui rend impossible de le faire graduellement, c’est bien ça ? Pas tant que ça. En fait, un changement d’interface dans une API (interface de programmation applicative - NdT), est assez répandue et pour laquelle il existe une solution bien connue : | Les changements d’interface sont un problème assez répandus dans les gros systèmes. Beaucoup de composants utilisent des interfaces et doivent être modifiés en conséquence - ce qui rend impossible de le faire graduellement, c’est bien ça ? Pas tant que ça. En fait, un changement d’interface dans une API (interface de programmation applicative - NdT), est assez répandue et pour laquelle il existe une solution bien connue : | ||
| Ligne 310 : | Ligne 310 : | ||
L’intégration continue dans les développements à grande échelle | L’intégration continue dans les développements à grande échelle | ||
* [http://link.springer.com/chapter/10.1007%2F978-3-540-24853-8_8 “Scaling Continuous Integration ,” par Owen Rogers] (aussi présent sur: exortech.com/blog/wp-content/uploads/2008/05/scaling-ci-3.pdf) dans ''Extreme Programming and Agile Processes in Software Engineering 2004 Conference Proceedings | * [http://link.springer.com/chapter/10.1007%2F978-3-540-24853-8_8 “Scaling Continuous Integration ,” par Owen Rogers] (aussi présent sur: exortech.com/blog/wp-content/uploads/2008/05/scaling-ci-3.pdf) dans ''Extreme Programming and Agile Processes in Software Engineering 2004 Conference Proceedings''. | ||
Notes | Notes | ||
| Ligne 318 : | Ligne 318 : | ||
# Pour être plus précis, évitez les branches ayant une durée de vie de plus de quelques heures. L’utilisation des branches est devenue plus facile avec les systèmes distribués de contrôle de version comme Git et Mercurial. Avoir une utilisation mesurée de branches ayant des durées de vie brèves peut s’avérer utile … mais c’est une arme à double tranchant qui peut facilement être mal utilisée [[http://martinfowler.com/bliki/FeatureBranch.html Fowler09]]. | # Pour être plus précis, évitez les branches ayant une durée de vie de plus de quelques heures. L’utilisation des branches est devenue plus facile avec les systèmes distribués de contrôle de version comme Git et Mercurial. Avoir une utilisation mesurée de branches ayant des durées de vie brèves peut s’avérer utile … mais c’est une arme à double tranchant qui peut facilement être mal utilisée [[http://martinfowler.com/bliki/FeatureBranch.html Fowler09]]. | ||
# Astuce : créez donc une branche de livraison en dehors de ligne principale juste avant la livraison, non au démarrage de la livraison (une ligne de livraison). | # Astuce : créez donc une branche de livraison en dehors de ligne principale juste avant la livraison, non au démarrage de la livraison (une ligne de livraison). | ||
# Tiré d’un article dénommé ''Continuous Integration and Automated Builds at Enterprise Scale'' qui auparavant était disponible sur [blog.aspiring-technology.com/file.axd?file=Continuous+Integration+at+Enterprise+Scale.pdf blog.aspiring-technology.com/file.axd?file=Continuous+Integration+at+Enterprise+Scale.pdf]. Malheureusement ce lien est mort. Si quelqu’un | # Tiré d’un article dénommé ''Continuous Integration and Automated Builds at Enterprise Scale'' qui auparavant était disponible sur [blog.aspiring-technology.com/file.axd?file=Continuous+Integration+at+Enterprise+Scale.pdf blog.aspiring-technology.com/file.axd?file=Continuous+Integration+at+Enterprise+Scale.pdf]. Malheureusement ce lien est mort. Si quelqu’un connaît un nouveau lien pour ce document, dites-le nous. | ||
