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

De Wiki Agile
Ligne 166 : Ligne 166 :
'''Paralléliser''' - en relation avec l’ajout de matériel, se trouve la parallélisation et la compilation distribuée. Cela nécessite souvent de revoir la conception les scripts de compilation, de changer les outils, ou même de construire de nouveaux outils. Par conséquent, cela demande plus d’effort qu’ajouter simplement du nouveau matériel. Un gros produit télécom a obtenu un gain de son temps de compilation en distribuant la compilation de chaque composant sur du matériel dédié.
'''Paralléliser''' - en relation avec l’ajout de matériel, se trouve la parallélisation et la compilation distribuée. Cela nécessite souvent de revoir la conception les scripts de compilation, de changer les outils, ou même de construire de nouveaux outils. Par conséquent, cela demande plus d’effort qu’ajouter simplement du nouveau matériel. Un gros produit télécom a obtenu un gain de son temps de compilation en distribuant la compilation de chaque composant sur du matériel dédié.


'''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 5O%. 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 on 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 on 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 incompatbles 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.
'''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 incompatbles 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.