« Less - Intégration continue » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (5 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Nicolas Mereaux]] | |||
[[Category: Portail LeSS]] | [[Category: Portail LeSS]] | ||
[[Category: Portail Equipe de développement]] | [[Category: Portail Equipe de développement]] | ||
[[Catégorie:Tests]] | |||
[[Catégorie:TDD]] | |||
Auteur : The LeSS Company B.V.<br/> | Auteur : The LeSS Company B.V.<br/> | ||
Source : [http://less.works/less/technical-excellence/continuous-integration.html Continuous Integration - Large Scale Scrum (LeSS)]<br/> | Source : [http://less.works/less/technical-excellence/continuous-integration.html Continuous Integration - Large Scale Scrum (LeSS)]<br/> | ||
| Ligne 63 : | Ligne 66 : | ||
'''''Note'' : L'intégration continue et le développement itératif et incrémental dans Scrum ont la même stratégie. Toutefois, l'intégration continue est sur une maille plus fine qu'une itération Scrum. Les deux permettent de réduire la variabilité, et le risque en travaillant par petits lots -- itérativement.''' | '''''Note'' : L'intégration continue et le développement itératif et incrémental dans Scrum ont la même stratégie. Toutefois, l'intégration continue est sur une maille plus fine qu'une itération Scrum. Les deux permettent de réduire la variabilité, et le risque en travaillant par petits lots -- itérativement.''' | ||
[[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”. | [[File:Xcontinuous-integration-chicken.png|border|270px|left|un poulet en plastique|link=]] 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”. | ||
Le poulet en plastique ne peut passer à grande échelle sur de gros produits. Ceci dit, cette histoire permet très clairement de se rappeler que l’intégration continue ''est une pratique de développeur''. | Le poulet en plastique ne peut passer à grande échelle sur de gros produits. Ceci dit, cette histoire permet très clairement de se rappeler que l’intégration continue ''est une pratique de développeur''. | ||
| Ligne 87 : | Ligne 90 : | ||
''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). | ''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). | ||
[[Fichier:Xcontinuous-integration-grow-versus-bolt-fr.png|border|centré|Grandir vs construire]] | [[Fichier:Xcontinuous-integration-grow-versus-bolt-fr.png|border|centré|Grandir vs construire|link=]] | ||
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. | 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. | ||
| Ligne 127 : | Ligne 130 : | ||
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. | 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. | ||
[[Fichier:Xcontinuous-integration-system-fr.png|cadre|centré|Système d'intégration continue]] | [[Fichier:Xcontinuous-integration-system-fr.png|cadre|centré|Système d'intégration continue|link=]] | ||
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. | 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. | ||
| Ligne 145 : | Ligne 148 : | ||
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 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). | ||
[[Fichier:Xcontinuous-integration-causal-loop-ci-number-of-people-fr.png|cadre|centré|Boucle causale]] | [[Fichier:Xcontinuous-integration-causal-loop-ci-number-of-people-fr.png|cadre|centré|Boucle causale|link=]] | ||
Les solutions sont simples : | Les solutions sont simples : | ||
| Ligne 192 : | Ligne 195 : | ||
Un système d’intégration continue est comparable à la culture “arrêt de la ligne de production” de Toyota. Lorsqu’une anomalie est détectée, Toyota arrête la ligne de production, et la première priorité est de corriger l’anomalie et sa cause racine. Est-ce qu’un système d’intégration continue en plusieurs étapes est en contradiction avec ce principe lean ? Non. Une attitude arrêt-de-la-ligne-de-production est absolument nécessaire, mais cela ne signifie pas que vous devriez arrêter aveuglément tous les travaux. Même Toyota ne fait pas ça [[http://www.amazon.com/Toyota-Way-Fieldbook-Jeffrey-Liker/dp/0071448934 LM06a]]. | Un système d’intégration continue est comparable à la culture “arrêt de la ligne de production” de Toyota. Lorsqu’une anomalie est détectée, Toyota arrête la ligne de production, et la première priorité est de corriger l’anomalie et sa cause racine. Est-ce qu’un système d’intégration continue en plusieurs étapes est en contradiction avec ce principe lean ? Non. Une attitude arrêt-de-la-ligne-de-production est absolument nécessaire, mais cela ne signifie pas que vous devriez arrêter aveuglément tous les travaux. Même Toyota ne fait pas ça [[http://www.amazon.com/Toyota-Way-Fieldbook-Jeffrey-Liker/dp/0071448934 LM06a]]. | ||
<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 | <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. | ||
</blockquote> | </blockquote> | ||
Un système d’intégration continue à plusieurs étapes fonctionne de la même manière. Vous identifiez le problème au plus tôt et travaillez à sa résolution, mais vous ne voulez pas qu’il affecte tout le monde. Et c’est seulement si le problème s’avère vraiment sérieux que vous allez “arrêter la ligne de production”. | Un système d’intégration continue à plusieurs étapes fonctionne de la même manière. Vous identifiez le problème au plus tôt et travaillez à sa résolution, mais vous ne voulez pas qu’il affecte tout le monde. Et c’est seulement si le problème s’avère vraiment sérieux que vous allez “arrêter la ligne de production”. | ||
| Ligne 229 : | Ligne 232 : | ||
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. | 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. | ||
[[Fichier:Xcontinuous-integration-scaled-system-example-fr.png|border|centré|Exemple à grande échelle d'intégration continue]] | [[Fichier:Xcontinuous-integration-scaled-system-example-fr.png|border|centré|Exemple à grande échelle d'intégration continue|link=]] | ||
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é. | 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é. | ||
| Ligne 237 : | Ligne 240 : | ||
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/> | 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/> | ||
[[Fichier:Xcontinuous-integration-andon-skeleton.jpg|andon-skeleton.jpg|border]]<br/> | [[Fichier:Xcontinuous-integration-andon-skeleton.jpg|andon-skeleton.jpg|border|link=]]<br/> | ||
<br/> | <br/> | ||
[[Fichier:Xcontinuous-integration-andon-red-green.jpg|andon-red-green.jpg|border]]<br/> | [[Fichier:Xcontinuous-integration-andon-red-green.jpg|andon-red-green.jpg|border|link=]]<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]]: | 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]]: | ||
| Ligne 269 : | Ligne 272 : | ||
'''À 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. É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 - 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. É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 ? | '''À 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 ? Ne réfléchissez pas de cette manière. | ||
'''À FAIRE - Utilisez du management visuel pour montrer l’état de la compilation''' - Utilisez de vieux ordinateurs ou des ordinateurs dont personne ne veut et suivez ‘tout ce qu’il se passe’ montrant où en est l’état de la compilation. | '''À FAIRE - Utilisez du management visuel pour montrer l’état de la compilation''' - Utilisez de vieux ordinateurs ou des ordinateurs dont personne ne veut et suivez ‘tout ce qu’il se passe’ montrant où en est l’état de la compilation. | ||
