« Less - Intégration continue » : différence entre les versions
De Wiki Agile
| Ligne 168 : | Ligne 168 : | ||
'''Changer les outils''' - mettre à jour les outils dans leur dernière version ou remplacer un outil lent par un outil rapide permet d’accélérer grandement la compilation. Il nous est arrivé, en changeant simplement de compilateur, de diminuer le temps de compilation de 50%. Une problématique assez répandue que nous avons pu constater est l’utilisation d’un outil lent, IBM Rational ClearCase pour ne pas le nommer. À chaque fois qu’un groupe produit a changé de ClearCase pour Subversion - très bon système open-source de gestion de configuration logicielle (ou GCL) - ce groupe a … ''premièrement'' accéléré la compilation (nos clients ont eu un gain de 25 à 50%) ; ''deuxièmement'', permis d’économiser une somme substantielle avec le coût des licences ; et ''troisièmement'', amélioré la vie des développeurs, notamment dans les groupes avec lesquels nous avons travaillé et pour qui ClearCase était l’outil de développement qu’ils détestaient le plus. Certaines personnes mal informées ont argumenté en disant que Subversion n’est pas adapté pour le développement de gros produits. Mais nous l’avons vu en action dans des groupes produits de 400 personnes répartis à travers le monde. De manière plutôt ironique, les soi-disants fonctionnalités à grande échelle de ClearCase telles que le support multi-sites, ont rendu l’intégration continue impossible car elles forçaient les utilisateurs à avoir une appropriation individuelle du code. | '''Changer les outils''' - mettre à jour les outils dans leur dernière version ou remplacer un outil lent par un outil rapide permet d’accélérer grandement la compilation. Il nous est arrivé, en changeant simplement de compilateur, de diminuer le temps de compilation de 50%. Une problématique assez répandue que nous avons pu constater est l’utilisation d’un outil lent, IBM Rational ClearCase pour ne pas le nommer. À chaque fois qu’un groupe produit a changé de ClearCase pour Subversion - très bon système open-source de gestion de configuration logicielle (ou GCL) - ce groupe a … ''premièrement'' accéléré la compilation (nos clients ont eu un gain de 25 à 50%) ; ''deuxièmement'', permis d’économiser une somme substantielle avec le coût des licences ; et ''troisièmement'', amélioré la vie des développeurs, notamment dans les groupes avec lesquels nous avons travaillé et pour qui ClearCase était l’outil de développement qu’ils détestaient le plus. Certaines personnes mal informées ont argumenté en disant que Subversion n’est pas adapté pour le développement de gros produits. Mais nous l’avons vu en action dans des groupes produits de 400 personnes répartis à travers le monde. De manière plutôt ironique, les soi-disants fonctionnalités à grande échelle de ClearCase telles que le support multi-sites, ont rendu l’intégration continue impossible car elles forçaient les utilisateurs à avoir une appropriation individuelle du code. | ||
'''Construire incrémentalement''' - vous devez compiler uniquement les composants ayant changé et exécuter les tests associés. Facile en théorie ; difficile en pratique. Les dépendances entre les composants, les changements dans les interfaces ou les binaires | '''Construire incrémentalement''' - vous devez compiler uniquement les composants ayant changé et exécuter les tests associés. Facile en théorie ; difficile en pratique. Les dépendances entre les composants, les changements dans les interfaces ou les binaires incompatibles sont quelques-unes des choses qui font que compiler uniquement ce qui a changé est une proposition qui s’avère difficile. Pour les mêmes raisons, trouver tous les tests associés aux composants ayant changés peut être difficile. Les compilations incrémentales sont rarement fiables à 100%, et pour empêcher la corruption de la compilation incrémentale, c’est une bonne idée de continuer à avoir une compilation quotidienne correcte. | ||
'''Déploiement continu''' - sur de gros produits embarqués, cela prend énormément de temps de déployer ou d’installer un logiciel ; un produit télécom de radio communication sur lequel nous avons travaillé a mis plus d’une heure à se déployer. Ce n’est pas quelque chose d’inhabituel. Les tests vont plus vite lorsque le déploiement est fait de manière incrémentale - car seuls les composants ayant changé sont déployés. Les changements doivent être chargés, ce qui peut être fait en redémarrant le système. Toutefois, démarrer un gros système prend du temps, par conséquent certains systèmes sont mis à jour dynamiquement - une fonctionnalité importante dans les télécoms et dans les autres industries où le temps d’indisponibilité s’avère très cher. Le déploiement incrémental - et tout spécialement la mise à jour dynamique - demande des changements dans le système, mais cela rend cette option difficile. | '''Déploiement continu''' - sur de gros produits embarqués, cela prend énormément de temps de déployer ou d’installer un logiciel ; un produit télécom de radio communication sur lequel nous avons travaillé a mis plus d’une heure à se déployer. Ce n’est pas quelque chose d’inhabituel. Les tests vont plus vite lorsque le déploiement est fait de manière incrémentale - car seuls les composants ayant changé sont déployés. Les changements doivent être chargés, ce qui peut être fait en redémarrant le système. Toutefois, démarrer un gros système prend du temps, par conséquent certains systèmes sont mis à jour dynamiquement - une fonctionnalité importante dans les télécoms et dans les autres industries où le temps d’indisponibilité s’avère très cher. Le déploiement incrémental - et tout spécialement la mise à jour dynamique - demande des changements dans le système, mais cela rend cette option difficile. | ||
