« Less - Intégration continue » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (2 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 66 : | 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 90 : | 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 130 : | 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 148 : | 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 195 : | 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 232 : | 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 240 : | 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]]: | ||
