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

''Construire'' un système implique construire les composants séparément et, lorsqu’ils sont finis, de les assembler ensemble. Faire ''grandir'' un système implique de le nourrir et le faire évoluer en un plus grand système (voir grandir versus construire).

Est-ce possible avec de gros systèmes ayant du code déjà existant ? Cette question nous est posée fréquemment. Dans presque tous les cas, la réponse est oui. Si vos développeurs ou vos architectes ne peuvent pas le faire ou clament que c’est impossible, vous pouvez interprétez cela comme un signe d’un manque de compétence.

Les gens font des erreurs. C’est normal. Un filet de sécurité lean du type arrêtez-les-machines est nécessaire pour les détecter au plus tôt. Les développeurs corrigent une anomalie avant qu’elles n’affectent les autres. Ce filet de sécurité, un système de type ''andon'', dans la terminologie Toyota, est un système d’intégration continue.

Un système d’intégration continue (Voir système d’intégration continue) est à l’écoute d’un système de gestion de configuration logicielle. Lorsqu’un développeur y enregistre son code, le système d'intégration continue prend tout le code, le compile, exécute quelques tests, l’installe, et exécute quelques tests supplémentaires. Tout cela se déroule vite ; l'Extreme Programming recommande que cela se déroule en moins de dix minutes. Si un développeur casse la compilation, le système d’intégration continue fera une requête au système de gestion de configuration logicielle et trouvera qui a fait le changement. Il lui enverra un courriel disant : “Tu as cassé la compilation, répare-la !”. Corriger la compilation cassée devient la priorité numéro une parce que cela impacte tout le monde.

Les obstacles pour étendre un système d’intégration continue sont liés à l’augmentation du nombre de personnes, de la quantité de code et de tests produits. Premièrement, la probabilité de casser la compilation s’accroît avec le nombre de personnes enregistrant du code. Deuxièmement, une augmentation de la taille du code conduit à un ralentissement de la compilation et de la boucle de retours d’informations du système d’intégration continue. Ces différents éléments peuvent mener à un échec en continu de la compilation (Voir les dynamiques des compilations cassées).

Les solutions sont simples :

Le diagramme ci-dessous vous donne un exemple de système d’intégration continue comportant plusieurs étapes. Dans cet exemple, chaque composant a un système d’intégration continue exécutant des tests unitaires, de l’analyse statique ainsi que des indicateurs de couverture de code. Une compilation réussie promeut alors le composant et déclenche ensuite les systèmes d’intégration continue au niveau ''feature'' qui eux-mêmes exécutent des tests de plus haut niveau. Une compilation quotidienne exécute les tests systèmes comme par exemple des tests de performance.

Un système d’intégration continue peut effectivement inclure du management visuel - qui est l’un des principes lean. Lorsque la compilation plante, un signal visuel indique son échec - autrement dit un système ''andon'' (dans la terminologie Toyota). Ce signal n’est pas à l’attention des manageurs pour qu’ils punissent le développeur responsable de l’échec de la compilation ; il est pour les développeurs afin de voir l’état de la compilation. Que vont-ils faire de cette information ? Enquêter sur ce qui se passe ou sur ce qui retarde l’intégration à l’échec de la compilation. Si plus tard, le signal visuel indique que l’échec est toujours présent, des personnes supplémentaires pourront chercher pourquoi cela n’a pas été corrigé.

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 est cassée. 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/>

<br/>

<br/>

<br/>

Voici un petit message d’avertissement de Jeffrey Liker à propos du management visuel [[http://www.amazon.com/Toyota-Culture-Heart-Soul-Way/dp/0071492178 LH08]]: