Quels sont certains arguments contre l'utilisation de l'intégration continue?

Question

Je peux penser à de nombreuses bonnes raisons de l’utiliser; Cependant, quels sont ses inconvénients?

(Outre l'achat d'un autre serveur)

Quels sont les avantages d'utiliser une version quotidienne au lieu de cela?

Answer 1

(Il est intéressant de noter que par "intégration continue", je veux dire une intégration automatisée avec un processus de génération automatisé et automatiquement qui exécute des tests et < strong> automatiquement détecte la défaillance de chaque pièce.

Il est également intéressant de noter que "intégration continue". signifie simplement à un tronc ou un serveur de test. Cela ne veut pas dire "poussez tous les changements en direct".

Il existe de nombreuses façons de faire une mauvaise intégration continue.)

Je ne vois aucune raison de ne pas effectuer de test d'intégration continue. Je suppose que je suppose que "l'intégration continue" comprend les tests. Le simple fait de compiler ne signifie pas que cela fonctionne.

Si votre construction et / ou vos tests durent longtemps, l'intégration continue peut coûter cher. Dans ce cas, exécutez les tests relatifs à votre modification avant la validation (outils d'analyse de la couverture, tels que Devel :: CoverX :: Covered peut aider à découvrir quels tests vont avec quel code), faites vos tests d'intégration après la validation en utilisant quelque chose comme SVN :: Notify et avertit les développeurs en cas d'échec. Archivez les résultats du test en utilisant quelque chose comme Smolder . Cela permet aux développeurs de travailler rapidement sans avoir à regarder les suites de tests, tout en détectant les erreurs plus tôt.

Cela dit, avec un peu de travail, vous pouvez souvent accélérer votre processus de construction et de test. Il arrive souvent que des tests lents résultent du fait que chaque test doit faire trop de configuration et de démontage vers un système beaucoup trop couplé, ce qui nécessite la configuration de tout le système, juste pour tester un petit élément.

Le découplage est souvent utile, car il permet de diviser les sous-systèmes en projets indépendants. La portée plus petite facilite la compréhension et accélère la construction et les tests. Chaque commit peut faire une construction complète et tester sans déranger le programmeur. Ensuite, tous les sous-projets peuvent être rassemblés pour faire des tests d'intégration.

L’un des principaux avantages de l’exécution de la suite de tests à chaque validation, même si elle est postérieure à la validation, est que vous savez exactement ce qui a cassé la construction. Plutôt que "quelque chose que nous avons fait hier a cassé la construction", ou pire, quatre choses que nous avons faites hier ont cassé la construction de différentes façons et nous devons maintenant le démêler " c'est la "révision 1234 qui a cassé la construction". Il suffit d’examiner cette révision pour trouver le problème.

L’avantage de la construction quotidienne est qu’au moins vous savez qu’une construction et des tests complets et propres ont lieu tous les jours. Mais vous devriez le faire quand même.

Answer 2

Je ne pense pas qu'il y ait des inconvénients à cela. Mais pour les besoins de l’argumentation, voici l'article d'Eric Minick sur UrbanCode ("Il s’agit de tests non générés.") Il critique les outils basés sur Le travail de Martin Fowler en disant qu'ils ne laissent pas assez de temps pour les tests.

"Pour réussir réellement dans CI, Fowler affirme que la construction doit être auto-testée et que ces tests incluent à la fois des tests unitaires et des tests de bout en bout. Dans le même temps, la construction devrait être très rapide (idéalement moins de dix minutes), car elle devrait être exécutée à chaque commit. S'il existe un nombre important de tests de bout en bout, leur exécution au moment de la construction tout en maintenant l'ensemble du processus sous dix minutes est irréaliste.

Ajoutez à cela la nécessité de construire sur chaque commit, et les exigences commencent à se sentir improbables. Les options sont soit un retour plus lent, soit la suppression de certains tests. "

Answer 3

James Shore a publié une série d’articles de blog sur les dangers de penser qu’utiliser un outil de CI tel que CruiseControl impliquait une intégration continue:

• Pourquoi je n'aime pas CruiseControl
• L'intégration continue est une attitude et non un outil
• Intégration continue avec un dollar par jour

L'un des dangers de la configuration d'un serveur de CI est le déplacement d'objectifs, en pensant que l'important est de "garder la construction dépassée". au lieu de "veiller à disposer d'un logiciel de haute qualité". Ainsi, les gens cessent de se préoccuper du temps nécessaire aux tests. Ensuite, ils prennent trop de temps pour les exécuter tous avant l'enregistrement. Ensuite, la construction continue à se casser. Ensuite, la construction est toujours brisée. Donc, les gens commentent les tests pour faire passer la construction. Et la qualité du logiciel diminue, mais bon, la construction passe ...

Answer 4

Il y a généralement deux cas dans lesquels l'intégration continue n'a pas vraiment de sens. N'oubliez pas que je suis un ardent défenseur de l'IC et essayez de l'utiliser quand je le peux.

La première est que le roi n’a aucun sens. Je développe actuellement plusieurs petites applications internes. Les applications sont normalement très simples et le cycle de développement complet dure environ une semaine ou deux. Le fait de tout configurer correctement pour CI doublerait probablement ce montant et je ne reverrais probablement jamais cet investissement. Vous pouvez faire valoir que je vais le récupérer lors de la maintenance, mais ces applications risquent d'être rejetées au fur et à mesure de leur mise à jour. N'oubliez pas que votre travail consiste probablement à expédier des logiciels et non à atteindre une couverture de code à 100%.

L’autre scénario que j’ai entendu dire est que CI n’a aucun sens si vous ne faites rien avec les résultats. Par exemple, si votre logiciel doit être envoyé à l'AQ et que le personnel de l'AQ ne peut réellement examiner une nouvelle version que tous les deux jours, il est insensé de disposer de versions toutes les deux heures. Si d'autres développeurs ne vont pas examiner les métriques de code et essayer de les améliorer, cela n'a aucun sens de les suivre. Si ce n’est pas la faute de l’IC n’est pas une bonne technique, c’est un manque de volonté de votre équipe d’adhérer à l’IC. Néanmoins, la mise en œuvre d’un système de CI dans un tel scénario n’a aucun sens.

Answer 5

Lors du démarrage, il faut un certain temps pour tout configurer.

Si vous ajoutez des tests, une couverture, des inspections de code statique, des recherches en double, la construction et le déploiement de la documentation, cela peut prendre du temps (des semaines) pour réussir. Après cela, le maintien de la construction peut être un problème.

Par exemple, si vous ajoutez des tests à la solution, vous pouvez faire en sorte que la génération les détecte automatiquement en fonction de certains critères ou vous devez mettre à jour manuellement les paramètres de génération. La détection automatique est beaucoup plus difficile à obtenir. Même chose pour la couverture. Identique à la génération de documentation ...

Answer 6

La seule bonne raison de ne pas utiliser l'intégration continue vient du fait que votre projet a fonctionné au point où vos tests d'intégration n'ont détecté aucun défaut depuis longtemps et que leur exécution prend trop de temps. le temps que vous faites une construction. En d’autres termes: vous avez fait suffisamment d’intégration continue pour vous prouver que vous n’en avez plus besoin.