Less - Intégration continue - Historique des versions

Fabrice Aimetti le 9 juillet 2025 à 08:51

2025-07-09T08:51:25Z

← Version précédente		Version du 9 juillet 2025 à 08:51
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 ~~l’andon~~ deviendra rouge.		<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”.

Fabrice Aimetti le 6 décembre 2021 à 18:36

2021-12-06T18:36:42Z

← Version précédente		Version du 6 décembre 2021 à 18:36
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''.

Fabrice Aimetti le 6 décembre 2021 à 18:36

2021-12-06T18:36:07Z

Fabrice Aimetti le 13 mai 2020 à 15:44

2020-05-13T15:44:52Z

← Version précédente		Version du 13 mai 2020 à 15:44
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]]

Fabrice Aimetti le 26 février 2019 à 12:21

2019-02-26T12:21:53Z

← Version précédente		Version du 26 février 2019 à 12:21
Ligne 1 :		Ligne 1 :
	[[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/>

Fabrice Aimetti : /* À faire et à ne pas faire */

2018-11-24T10:48:59Z

À faire et à ne pas faire

← Version précédente		Version du 24 novembre 2018 à 10:48
Ligne 269 :		Ligne 269 :
	'''À 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 ? ~~Ce n’est~~ pas ça.		'''À 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.

Fabrice Aimetti : /* À faire et à ne pas faire */

2018-11-24T10:47:57Z

À faire et à ne pas faire

← Version précédente		Version du 24 novembre 2018 à 10:47
Ligne 267 :		Ligne 267 :
	À la place...		À 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 - 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 ? Ce n’est pas ça.		'''À 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.

Fabrice Aimetti : /* À faire et à ne pas faire */

2018-11-24T10:47:31Z

À faire et à ne pas faire

← Version précédente		Version du 24 novembre 2018 à 10:47
Ligne 263 :		Ligne 263 :
	'''À FAIRE - Associez qualité et code pour favoriser une intégration optimiste''' - Comment passer d’une politique pessimiste d’intégrations différées suite à revues de code à une politique optimiste d’intégrations au plus tôt ? Mettez en place une culture autour de l’artisanat logicielle (consultez le manifeste du [http://manifesto.softwarecraftsmanship.org/#/fr-fr Software Craftsmanship] pour en savoir plus - NdT), du développement piloté par les tests et du ''refactoring'' pour du code propre, autour de la programmation en binôme ou en groupe pour faire-de-la-revue-tout-en-codant, et autour des outils de vérification de code automatisée. Et si les revues de code sont toujours souhaitées, faites-les sur un cycle davantage espacé sur des petits lots de code déjà enregistrés.		'''À FAIRE - Associez qualité et code pour favoriser une intégration optimiste''' - Comment passer d’une politique pessimiste d’intégrations différées suite à revues de code à une politique optimiste d’intégrations au plus tôt ? Mettez en place une culture autour de l’artisanat logicielle (consultez le manifeste du [http://manifesto.softwarecraftsmanship.org/#/fr-fr Software Craftsmanship] pour en savoir plus - NdT), du développement piloté par les tests et du ''refactoring'' pour du code propre, autour de la programmation en binôme ou en groupe pour faire-de-la-revue-tout-en-codant, et autour des outils de vérification de code automatisée. Et si les revues de code sont toujours souhaitées, faites-les sur un cycle davantage espacé sur des petits lots de code déjà enregistrés.

	'''À NE PAS FAIRE - N’ayez pas une politique du type “Interdiction de planter la compilation” ; et ne faites PAS de reproches et ne blâmez PAS 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 …		'''À NE PAS FAIRE - N’ayez pas une politique du type “Interdiction de planter la compilation” ; et ne faites PAS de reproches et ne blâmez PAS 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 - 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.

Fabrice Aimetti : /* À faire et à ne pas faire */

2018-11-24T10:46:44Z

À faire et à ne pas faire

← Version précédente		Version du 24 novembre 2018 à 10:46
Ligne 263 :		Ligne 263 :
	'''À FAIRE - Associez qualité et code pour favoriser une intégration optimiste''' - Comment passer d’une politique pessimiste d’intégrations différées suite à revues de code à une politique optimiste d’intégrations au plus tôt ? Mettez en place une culture autour de l’artisanat logicielle (consultez le manifeste du [http://manifesto.softwarecraftsmanship.org/#/fr-fr Software Craftsmanship] pour en savoir plus - NdT), du développement piloté par les tests et du ''refactoring'' pour du code propre, autour de la programmation en binôme ou en groupe pour faire-de-la-revue-tout-en-codant, et autour des outils de vérification de code automatisée. Et si les revues de code sont toujours souhaitées, faites-les sur un cycle davantage espacé sur des petits lots de code déjà enregistrés.		'''À FAIRE - Associez qualité et code pour favoriser une intégration optimiste''' - Comment passer d’une politique pessimiste d’intégrations différées suite à revues de code à une politique optimiste d’intégrations au plus tôt ? Mettez en place une culture autour de l’artisanat logicielle (consultez le manifeste du [http://manifesto.softwarecraftsmanship.org/#/fr-fr Software Craftsmanship] pour en savoir plus - NdT), du développement piloté par les tests et du ''refactoring'' pour du code propre, autour de la programmation en binôme ou en groupe pour faire-de-la-revue-tout-en-codant, et autour des outils de vérification de code automatisée. Et si les revues de code sont toujours souhaitées, faites-les sur un cycle davantage espacé sur des petits lots de code déjà enregistrés.

	'''À 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 …		'''À NE PAS FAIRE - N’ayez pas une politique du type “Interdiction de planter la compilation” ; et ne faites PAS de reproches et ne blâmez PAS 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 - 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.

Fabrice Aimetti : /* Exemple de système d’intégration continue */

2018-11-24T10:44:28Z

Exemple de système d’intégration continue

← Version précédente		Version du 24 novembre 2018 à 10:44
Ligne 249 :		Ligne 249 :
	Les changements d’interface sont un problème assez répandus dans les gros systèmes. Beaucoup de composants utilisent des interfaces et doivent être modifiés en conséquence - ce qui rend impossible de le faire graduellement, c’est bien ça ? Pas tant que ça. En fait, un changement d’interface dans une API (interface de programmation applicative - NdT), est assez répandue et pour laquelle il existe une solution bien connue :		Les changements d’interface sont un problème assez répandus dans les gros systèmes. Beaucoup de composants utilisent des interfaces et doivent être modifiés en conséquence - ce qui rend impossible de le faire graduellement, c’est bien ça ? Pas tant que ça. En fait, un changement d’interface dans une API (interface de programmation applicative - NdT), est assez répandue et pour laquelle il existe une solution bien connue :

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

	=== À faire et à ne pas faire ===		=== À faire et à ne pas faire ===

← Version précédente		Version du 6 décembre 2021 à 18:36
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 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]]:

Less - Intégration continue - Historique des versions

Fabrice Aimetti le 9 juillet 2025 à 08:51

Fabrice Aimetti le 6 décembre 2021 à 18:36

Fabrice Aimetti le 6 décembre 2021 à 18:36

Fabrice Aimetti le 13 mai 2020 à 15:44

Fabrice Aimetti le 26 février 2019 à 12:21

Fabrice Aimetti : /* À faire et à ne pas faire */

Fabrice Aimetti : /* À faire et à ne pas faire */

Fabrice Aimetti : /* À faire et à ne pas faire */

Fabrice Aimetti : /* À faire et à ne pas faire */

Fabrice Aimetti : /* Exemple de système d’intégration continue */

Fabrice Aimetti : /* À faire et à ne pas faire */

Fabrice Aimetti : /* À faire et à ne pas faire */

Fabrice Aimetti : /* À faire et à ne pas faire */

Fabrice Aimetti : /* À faire et à ne pas faire */

Fabrice Aimetti : /* Exemple de système d’intégration continue */