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

[[File:Xcontinuous-integration-chicken.png|border|270px|left|un poulet en plastique]] James Shore, développeur agile et auteur de ''The Art of Agile Development'' [SW07] insiste sur le fait qu’il s’agit d’une pratique de développeur. Dans un très bon article intitulé ''Continuous Integration on a Dollar a Day'' [Shore06], James Shore explique comment faire de l’intégration continue avec un vieil ordinateur, un poulet en plastique, une clochette et un automate de compilation. La vieille machine de développement est utilisée comme machine d’intégration. Le poulet en plastique est le ''témoin d’intégration'' — seule la personne ayant le poulet en plastique peut intégrer son code. La clochette annonce une intégration réussie. Mais l’étape la plus importante dans cette description de l’intégration continue consiste à réunir tous les développeurs dans une seule pièce et de les faire se mettre d’accord pour “qu’à partir de maintenant, notre code qui est en gestion de configuration compilera toujours avec succès et passera les tests”.

[[Fichier:Xcontinuous-integration-grow-versus-bolt-fr.png|border|centré|Grandir vs construire]]

[[Fichier:Xcontinuous-integration-system-fr.png|cadre|centré|Système d'intégration continue]]

[[Fichier:Xcontinuous-integration-causal-loop-ci-number-of-people-fr.png|cadre|centré|Boucle causale]]

'''Ajouter du matériel''' - la manière la plus facile d’accélérer la compilation est d’acheter davantage de matériel. Ajouter deux ou trois ordinateurs de plus, davantage de mémoire, ou une connection réseau plus rapide, devrait permettre de résoudre le problème. Mettre à jour le matériel existant demande un investissement en argent et un minimum d’effort, ce qui en fait le meilleur choix et le plus facile. Un produit télécom a pu être compilé avec un gain en terme de vitesse de 50% sur un disque RAM - et cela avec une simple agumentation mémoire.

'''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.

'''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.

'''Gérer les dépendances''' - une cause assez répandue de la lenteur des compilations est la non gestion des dépendances. Exemples : les fichiers d’en-tête peuvent inclure plusieurs autres fichiers d’en-tête, ou bien plusieurs cycles de liens peuvent être nécessaire pour résoudre les dépendances de liens cycliques (type de lien récursifs - NdT). Pour un produit multimédia, nous avons passé plusieurs heures à ré-ordonner les dépendances des liens - divisant ainsi le temps de moitié. Réduire les dépendances permet d’accélèrer la compilation et par effet de bord d’améliorer la structure de votre produit.

<blockquote>Toyota a développé un système qui permet aux problèmes d’être identifiés et remontés sans qu’il soit nécessaire d’arrêter la ligne de production. Lorsqu’un problème est identifié et que la corde est tirée, l’alarme résonne et une lumière jaune s’allume. La ligne de production continue jusqu’à la fin de la zone de travail - le point de la “position fixe stop” … la ligne de production s’arrêtera lorsque la position fixe sera atteinte et que l’andon deviendra rouge.

'''à 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 capable de travailler avec un sous-ensemble du système, souvent un composant, et être capable 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.

'''à 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

==== Exemple de système d’intégration continu ====

[[Fichier:Xcontinuous-integration-scaled-system-example-fr.png|border|centré|Exemple à grande échelle d'intégration continue]]

Après les lampes à lave, les gens ont commencé à brancher toutes sortes d’éléments pour visualiser le résultat de la compilation, comme des guirlandes lumineuses de Nöel, des sirènes, des squelettes animés qui crient lorsque la compilation. Même si cela est moins amusant, un simple moniteur avec une page web présentant un gros cercle de couleur rouge ou vert (un ''écran rouge-vert'') est plus facilement reproductible. Les écrans rouge-vert sont en train de devenir la norme dans les systèmes d’intégration continue à grande échelle. Certaines versions incluent un signal jaune pour indiquer que “la compilation qui était plantée a été corrigée”. Un gros cercle de couleur tout simple - visible de loin - est un élément clé, mais l’affichage peut être enrichi de textes ou de diagrammes chiffrés, tel que la durée de compilation ou le taux de couverture de test. L’information n’a pas à se limiter aux informations de compilation [Rogers08].<br/>

[[Fichier:Xcontinuous-integration-andon-skeleton.jpg|andon-skeleton.jpg|border]]<br/>

[[Fichier:Xcontinuous-integration-andon-red-green.jpg|andon-red-green.jpg|border]]<br/>

<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.

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].

Chaque étape peut être faite indépendamment et à différents moments. Pour les APIs publiques, il est impossible de savoir s’il y a encore des utilisateurs pour l’ancienne interface. Il s’avère donc difficile e supprimer l’ancienne interface. Mais la plupart des interfaces concernées ne font pas partie de l’API publique, donc n’oubliez pas de supprimer celles qui sont obsolètes. Nous avons vu plusieurs produits se retrouver avec trois voire quatre interfaces systèmes ou interfaces de journalisation parce que les anciennes n’avaient jamais été supprimées.

'''À NE PAS FAIRE - N’ayez pas une politique du type “Interdiction de planter la compilation” ; et ne faites PAS de reproches et ne faites PAS honte à qui que ce soit en cas de plantage de la compilation''' - si vous faites ce genre de choses, cela engendrera de la peur et les gens vont éviter de faire de l’intégration. Alors une fois de plus, une intégration longtemps différée engendrera de nombreux problèmes qui resteront cachés. À la place …

'''À FAIRE - Rendez facile le fait d’échouer rapidement, de stopper et de corriger, et d’apprendre des ‘erreurs’''' - créez un système d’intégration continue aussi rapide que l’éclair qui donne de rapides retours d’informations en cas d’échec de la compilation plante. Éliminez les barrières qui empêchent les gens de pratiquer le “stopper et corriger”. Créez un environnement offrant une sécurité personnelle où les gens peuvent admettre les problèmes et apprendre à s’améliorer.

'''À FAIRE - “stoppez et corrigez” en cas d’échec de la compilation''' - “Nous sommes trop occupés à gérer les problèmes pour corriger la compilation qui s’est plantée.” Devons-nous vous le répéter en articulant mot par mot ? Ce n’est pas ça.