Combien de développeurs avant que l'intégration continue devienne effective pour nous?


34

Il y a une surcharge liée à l'intégration continue, par exemple, configuration, reconversion, activités de sensibilisation, arrêt de la correction de "bugs" qui se révèlent être des problèmes de données, séparation forcée des styles de programmation, etc.

À quel moment l'intégration continue est-elle rentable?

EDIT: Ce sont mes conclusions

La configuration était CruiseControl.Net avec Nant, en lecture de VSS ou de TFS.

Voici quelques raisons d'échec, qui n'ont rien à voir avec la configuration:

Coût de l’enquête : le temps consacré à rechercher si une lumière rouge est due à une véritable incohérence logique dans le code, à la qualité des données ou à une autre source telle qu’un problème d’infrastructure (par exemple, un problème de réseau, un dépassement du délai de lecture du contrôle de source, un serveur tiers est en panne, etc., etc.)

Coûts politiques liés à l'infrastructure : j'ai envisagé d'effectuer un contrôle "d'infrastructure" pour chaque méthode du test. Je n'avais pas de solution au délai d'attente, sauf pour remplacer le serveur de construction. Les tracasseries administratives ont fait obstacle et il n'y a pas eu de remplacement du serveur.

Coût de la fixation des tests unitaires : Un voyant rouge dû à un problème de qualité des données peut indiquer un test unitaire mal écrit. Ainsi, les tests unitaires dépendants des données ont été réécrits afin de réduire les risques de feux rouges dus à de mauvaises données. Dans de nombreux cas, les données nécessaires ont été insérées dans l'environnement de test pour pouvoir exécuter avec précision ses tests unitaires. Il est logique de dire qu'en rendant les données plus robustes, le test le devient davantage s'il dépend de ces données. Bien sûr, cela a bien fonctionné!

Coût de la couverture, c'est-à-dire l'écriture de tests unitaires pour du code déjà existant : le problème de la couverture de tests unitaires se posait. Il y avait des milliers de méthodes qui n'avaient pas de tests unitaires. Donc, il faudrait un nombre considérable de jours-hommes pour les créer. Comme il serait trop difficile de fournir une analyse de rentabilisation, il a été décidé que les tests unitaires seraient utilisés pour toute nouvelle méthode publique. Ceux qui n'avaient pas de test unitaire ont été qualifiés de «potentiellement infrarouge». Un point intéressant à retenir ici est que les méthodes statiques étaient un point discutable dans la façon dont il serait possible de déterminer de manière unique comment une méthode statique spécifique avait échoué.

Coût des versions sur mesure : les scripts Nant ne vont que très loin. Elles ne sont pas très utiles pour, par exemple, les versions dépendantes du CMS pour EPiServer, CMS ou tout déploiement de base de données orientée interface utilisateur.

Ce sont les types de problèmes rencontrés sur le serveur de build lors des tests hebdomadaires et des builds QA pendant la nuit. Je pense que ceux-ci ne sont pas nécessaires en tant que chef de build, ils peuvent effectuer ces tâches manuellement au moment de la publication, en particulier avec un groupe composé d’un seul homme et une petite compilation. Ainsi, les constructions en une étape n'ont pas justifié l'utilisation de CI dans mon expérience. Qu'en est-il des constructions plus complexes à plusieurs étapes? Celles-ci peuvent être difficiles à construire, surtout sans script Nant. Ainsi, même après en avoir créé un, ils n’avaient plus de succès. Les coûts liés à la résolution des problèmes liés à la lumière rouge ont dépassé les avantages. Finalement, les développeurs ont perdu tout intérêt et ont mis en doute la validité du feu rouge.

Après avoir bien essayé, je pense que l'IC coûte cher et qu'il y a beaucoup de travail en attente au lieu de simplement faire le travail. Il est plus rentable d’employer des développeurs expérimentés qui ne gênent pas les grands projets que d’introduire et de maintenir un système d’alarme.

C'est le cas même si ces développeurs partent. Peu importe si un bon développeur s'en va, car les processus qu'il suivrait lui permettraient de rédiger des spécifications, des spécifications de conception, de respecter les consignes de codage et de commenter son code afin qu'il soit lisible. Tout cela est passé en revue. Si cela ne se produit pas, son chef d'équipe ne fait pas son travail, ce qui devrait être repris par son responsable, etc.

Pour que CI fonctionne, il ne suffit pas d’écrire des tests unitaires, d’essayer de maintenir une couverture complète et d’assurer une infrastructure opérationnelle pour des systèmes volumineux.

En bout de ligne: on peut se demander si corriger autant de bogues avant la publication est même souhaitable du point de vue des entreprises. CI nécessite beaucoup de travail pour capturer une poignée de bogues que le client pourrait identifier dans UAT ou la société pourrait être payée pour être corrigée dans le cadre d’un contrat de service client lorsque la période de garantie expirait.


13
Cela peut être bénéfique même pour une équipe de 1. Surtout si vous avez une longue suite de tests, il est bien mieux d’obtenir automatiquement les résultats d’une construction et d’une exécution de test du jour au lendemain que de le faire manuellement tout le temps.
SK-logic le

3
@Carnotaurus, un clone local du référentiel git distant supprime le délai d'attente du contrôle de code source. Problèmes de réseau - pour la construction du produit? Maintenant, vraiment ...

3
La lumière rouge @Carnotaurus en raison de la qualité des données ou de l’infrastructure est un code de tests fragiles . Voir aussi : Gestion de la charge de la maintenance du test unitaire
k3b

1
Plus un test dépend d'aspects externes, plus il est fragile. Exemple: Si un test réussit uniquement si le client XY est dans la base de données, le test est fragile, à moins que la configuration du test ne garantisse l'existence de cette condition préalable en insérant les données elle-même, si nécessaire.
k3b

6
"Conclusion: pourquoi fabriquer des produits qui fonctionnent lorsque nous pouvons faire payer par quelqu'un d'autre pour le réparer, parce que ce n'est pas comme s'ils s'attendaient à ce que le logiciel fonctionne en premier lieu"? Cela ne correspond peut-être pas à la définition légale, mais cela me semble une fraude.
Chris Pitman

Réponses:


43

La mise en place d'un moteur CI s'apparente à la configuration d'une alarme incendie dans une maison.

Dans mon esprit, les avantages ne sont pas liés à de nombreux développeurs, mais à une base de code volumineuse. Le moteur CI effectue activement tout le travail ennuyeux que vous ne voulez pas faire vous-même, et le fait à chaque fois.

Si vous cassez un module distant que vous n'avez pas touché depuis longtemps, on vous le dit immédiatement. Non seulement sur le plan de la compilation, mais aussi du point de vue des fonctions si vous avez configuré des tests unitaires.

Notez également que si vous laissez le moteur CI effectuer tout le travail fastidieux, y compris la configuration des installateurs, vous n’aurez pas à le faire manuellement. Vous pouvez simplement vérifier votre source et attendre que le produit fini soit construit à l'emplacement standard. (EDIT: le moteur de configuration fonctionne également dans un environnement bien défini, en évitant toute configuration spécifique au développeur et en garantissant sa reproductibilité)

Cela fait également partie de l’assurance qualité.


EDIT: Après avoir écrit ce qui précède, j'ai déjà utilisé l'outil de construction Maven pour Java. Cela nous permet essentiellement de conserver la configuration complète du CI dans le projet (avec pom.xml), ce qui simplifie grandement la maintenance de l'installation du CI et / ou la migration vers un autre moteur de CI.


1
@Carnotaurus, dans ce cas, la lumière rouge est également utilisée pour les erreurs transitoires. Cela ressemble à une limitation du moteur CI que vous utilisez.

2
@Carnotaurus, dans mon expérience, le travail effectué pour documenter minutieusement chaque aspect de tout ce qui concerne, par exemple, faire un communiqué puis le faire plusieurs fois, est plus grand que la capture du flux de travail dans un script fourmi ou maven pouvant ensuite être exécuté par un robot n'importe quel nombre de fois. Ledit robot fonctionne également dans une salle blanche afin de garantir la reproduction des constructions.

1
Notez que la rupture que je recherche n’est pas l’échec des tests unitaires, mais que les programmes que nous livrons peuvent toujours être construits. Ce n'est plus aussi important puisque nous avons migré vers des artefacts maven au lieu de tout compiler pour chaque version, mais il est toujours important de savoir que la construction est entièrement fonctionnelle. Nous avons également besoin de la partie Déploiement continu.

2
@Carnotaurus: Je ne parle pas d'un système d'alarme. Si les tests échouent, le correctif n’est pas (du tout) intégré dans le référentiel principal, ce qui garantit que chaque fois que vous extrayez / clonez votre copie, vous obtenez une copie de travail complète et pouvez commencer à travailler immédiatement. Maintenant, je conviens avec vous que les tests peuvent être difficiles à écrire et à maintenir ... mais j'ai travaillé avec et sans test, et je constate une nette amélioration de la qualité avec eux. La question est donc: automatisée ou non? D'après mon expérience, le test manuel prend autant de temps que l'écriture du script d'automatisation (mais je travaille dans une grande entreprise avec des outils pour cela).
Matthieu M.

5
" C’est quand même beaucoup de travail de capturer une poignée de bugs que l’entreprise serait payée pour la corriger dans le cadre d’un contrat de service client " - dans ce cas, vous n’avez pas l’intérêt économique de produire des logiciels avec le moins de bugs possible, et dans ce cas, tout cela ne vous concerne pas.

33

Ce n'est pas le nombre de développeurs, mais le nombre d'étapes nécessaires pour passer de 1 à n (inclus), où 1 et n sont ...

1: Vérification du code
et
n: avoir des paquets installables \ déployables

Si n <2 vous n’avez peut - être pas besoin de CI
, vous avez besoin de CI

Mise à jour
À la lecture de vos conclusions, je ne peux que conclure que vous avez abordé CI de manière erronée et pour de mauvaises raisons.


1
+1 - J'ai beaucoup de choses que je pourrais ajouter à ce qui précède - mais c'est très proche de la raison pour laquelle j'aime CI ... non seulement pour ce qu'il fait, mais aussi pour ce que vous devez faire pour le réaliser. travail (ces exigences étant des choses que vous devriez vraiment faire de toute façon).
Murph

2
@murph: Oui, et cela apporte peu d'avantages tels que 1) sachant que le contenu de votre référentiel sera construit, 2) construire en un seul clic, 3) être capable de publier une version à un moment donné et bien plus encore
Binary Worrier

Il est donc juste de dire que cela dépend de la complexité de ce qui doit être publié, mesuré par le nombre d'étapes à suivre pour le déploiement comme étant capable de "tester" des couches séparées?
CarneyCode

1
@Carnotaurus: Désolé, mais je ne suis pas sûr de savoir ce que vous essayez de dire. CI n'a rien à voir avec les tests. Oui, vous pouvez - et devriez - exécuter des tests unitaires dans le cadre de la construction, mais ils ne doivent pas dépendre de tout ce qui n’est pas configuré dans le cadre du test. Cependant, CI effectue des tests d'aide. L'un des nombreux avantages de CI est qu'il permet à une équipe d'assurance qualité de récupérer immédiatement et sans faille les nouvelles modifications de code. IC = La capacité à libérer immédiatement
Binary Worrier

1
@BinaryWorrier - Je pense que l'étape 1 vérifie le code;)

10

Cela peut valoir la peine, même pour une équipe de 1. Cela est particulièrement vrai lorsque vous développez du code multiplateforme et que vous devez vous assurer que vos modifications fonctionneront sur les deux plates-formes. Par exemple, le compilateur C ++ de Microsoft est plus tolérant que GCC. Par conséquent, si vous développez sous Windows mais que vous devez également prendre en charge Linux, le fait de disposer d'un système de CI vous avertit lorsque votre version de Linux devient une aide précieuse.

Certains systèmes CI sont assez faciles à configurer, les frais généraux ne sont donc pas si importants. Essayez Jenkins ou Hudson par exemple.


Je n'avais pas envisagé un scénario multi-plateforme. Si différents compilateurs sont nécessaires pour créer différentes versions, il y a de fortes chances que CI soit un vote positif.
CarneyCode

4

Comme vous le dites, il y a des frais généraux de mise en place et de fonctionnement.

Mais la question de savoir où se situe le seuil de rentabilité ne dépend pas du nombre de personnes que vous avez dans votre équipe, mais plutôt de la longueur de votre projet.

Cela dit, vous pouvez utiliser une partie des coûts d’installation dans tous vos projets futurs. Ainsi, à long terme, les frais généraux peuvent s’approcher de zéro.


La longueur du projet (taille du projet) est donc importante pour vous, CI? J'ai trouvé que les fausses alarmes étaient très coûteuses.
CarneyCode

Oui, vous devez avoir le temps de rembourser les coûts d'installation et d'apprentissage. En théorie, avec le temps, vous devriez apprendre à éliminer les fausses alarmes.
Stephen Bailey le

Oui, c'est de la théorie
CarneyCode

Eh bien non, sa pratique. Au fil du temps, vous notez quels tests sont fragiles et quels tests ne le sont pas, et vous ne vous inquiétez pas trop si vos tests fragiles se cassent s'ils ne se cassent pas plusieurs fois de suite. Vous écrivez des tests plus isolés et plus robustes à mesure que vous apprenez comment, et vous laissez la couverture héritée se développer avec le temps au lieu de tout faire en même temps. En pratique, CI n’est pas une solution miracle, c’est un changement de processus qui prend du temps et conduit finalement à un logiciel moins bogué.
philosodad

3

J'ai installé Jenkins cette semaine pour construire un petit projet .NET sur lequel je travaille. Je l'ai intégré à mon contrôle de code source Git afin qu'il déclenche une construction à chaque commit. J'ai intégré les tests unitaires dans la construction. J'ai intégré l'analyse statique sous la forme de violations FxCop et StyleCop.

Maintenant, chaque fois que je m’enregistre, il vérifie tout mon code, le construit, incrémente le numéro de version dans tous les assemblys, le teste, l’analyse pour détecter les violations FxCop et StyleCop, archive la construction et enregistre les résultats dans plusieurs graphiques. J'ai une visibilité dans le temps des résultats des tests et des violations.

Faire cela à partir de zéro prend environ une heure (peut-être une journée avec Google si vous ne l'avez pas encore fait). Cela ne coûte rien car tous les outils sont disponibles gratuitement.

Si, au fur et à mesure que le projet se construit, je dispose d’une infrastructure de grande qualité qui évoluera avec elle sans frais. Si ou quand de nouveaux développeurs rejoignent le projet, je peux obtenir une visibilité totale de leur travail et de leur impact sur le projet sans frais.

Donc, le seul scénario dans lequel je peux voir que CI ne vaut pas la peine, est soit pour un projet qui prendra environ un jour et ne sera jamais revisité, soit dans un langage où il n'y a pas d'outils existants / gratuits disponibles et le coût de leur acquisition. est disproportionnée au travail.


Comme je l'ai dit, ce sont les tests unitaires couvrant le code existant qui représentent un coût important. De plus, nous ne parlons pas non plus d'une équipe composée d'un seul homme ... J'apprécie toutefois le fait que Jenkins soit au courant.
CarneyCode

1
Pour ce que cela vaut, j'ai tiré un avantage considérable de l’exécution d’un serveur CI sans aucun test - uniquement de la confiance dans les versions propres et de la disponibilité des packages de déploiement.
Murph

1

Si vous pouvez vérifier tous les aspects de votre projet après chaque modification, vous n'avez pas besoin de CI.

Dans tous les autres cas, c'est un gain net.


Je pense que c'est de là que je viens aussi. C'est beaucoup moins cher aussi.
CarneyCode

Qu'entendez-vous par vérification dans ce cas? S'il est automatisé, se produit aussi souvent que possible et aide à identifier les erreurs mentales, alors je suis tout à fait d'accord. :-)
William Payne

1

Les frais généraux sont minimes. Je dirais que pour un homme, ce serait utile. Une fois que vous atteignez deux, c'est inestimable.

Je conviens que pour les projets one man, si vous avez une "construction / vérification en une étape", l'intégration continue est peut-être acceptable dans un système formel (CC, Hudson, TeamCity, etc.).


Vous voulez dire sans CI?
CarneyCode

1

Il est difficile de répondre à la question sur un nouveau projet.

Sur un projet existant, c'est beaucoup plus facile à voir. Si vous trouvez un bogue critique au niveau du développement de la chaîne d'approvisionnement, vous savez que ce problème existe le plus tôt possible. Le coût de la réparation est maintenant le plus bas. Si ce problème existe dans tous les environnements supérieurs au développement, votre coût est plus élevé.

Maintenant, la direction peut décider de publier avec un bogue, mais c'est un risque pour l'entreprise. Au moins maintenant, il peut être atténué par cette évaluation des risques, plutôt que par des appels téléphoniques tardifs / des paniques qui, si elles étaient facturées à un taux horaire, finissent par coûter extrêmement cher.

Une autre chose à considérer en termes de coût. Quel est votre département QA? Est-ce un test manuel? Si vous choisissez CI, vous pourrez peut-être réduire les coûts généraux d'assurance qualité en automatisant ces scripts sur votre boîte de dev. Vous pourrez peut-être réduire le nombre de personnes chargées de l’assurance qualité qui soutiennent votre projet en les associant à la phase d’IC.


1
Remplacer un test de régression manuel par certains tests automatisés d'interface utilisateur prend un peu de temps et de compétences. Dans une entreprise, un type a écrit environ 40% des tests et a quitté l'entreprise. Plusieurs années plus tard, les tests n'ont toujours pas été écrits. Je parie que c'est typique.
CarneyCode

Non, ce n'est pas typique.
quant_dev

Je n'ai pas vu beaucoup de contre-preuves
CarneyCode

Si vous écrivez des tests d'intégration / d'acceptation dans un DSL en langage naturel comme Gherkin, vous pouvez facilement traduire le test automatisé en manuel. Donc, je ne vois pas cela comme un problème.
Mike Cornell

@Carnotaurus - Je pense que c'est typique. Je l'ai vu deux fois aussi. Les tests automatisés de l'interface utilisateur sont difficiles.
Rocklan

1

CI vaut toujours toujours la peine: le sentiment de sécurité qu’il vous procure vous permet de travailler plus rapidement que cela n’aurait été possible autrement. Le problème que vous avez semble tourner autour des tests unitaires. Je conviens que les tests unitaires sont très coûteux, mais je pense aussi que ce sont la moins mauvaise des options (pour beaucoup de choses). Personnellement, et pour les types de systèmes sur lesquels j'ai tendance à travailler, je jure que des tests au niveau du système fonctionnent sur une combinaison de cas pathologiques réels et (éventuellement synthétiques); Il coûte moins cher que les tests unitaires et pénètre dans les recoins difficiles à atteindre de votre univers conceptuel: les "Unknown Unknowns" de Donald Rumsfeld.


J'aime la partie sur les tests d'interface utilisateur au niveau du système. Une grande partie des tests est perdue dans le brouillard des tests unitaires de qualité et de couverture douteuses.
CarneyCode

La couverture est une question de psychologie humaine également; nous avons une tendance innée à rédiger des tests pour les cas sur lesquels nous avons déjà réfléchi. Il est pour cette raison que d'être certifié à un niveau élevé de SIL, les tests unitaires doivent être écrits par une équipe distincte de celle qui a développé le système testé, et même alors, il qui existe de nombreux cas et situations évidentes pour tout le monde que en rétrospective. Un contrôle rigoureux de la couverture du code est nécessaire; mais extraordinairement difficile et coûteux.
William Payne

... D'où l'avantage que vous obtenez en jetant la plus sale ordure que vous pouvez trouver dans le système au plus haut niveau et en voyant ce qui se passe ... :-)
William Payne

1
+1 - Totalement d'accord. Certaines parties d'un système ne sont tout simplement pas testables par unité (c'est-à-dire les arêtes comme dans la base de données). Bien sûr, vous pouvez vous moquer de la base de données, mais cela laisse le code qui parle à la base de données non testé. À un moment donné, vous devez écrire des tests réels qui intègrent vos systèmes et dialoguent avec d’autres systèmes. Lorsque vous faites cela, vous trouvez toujours des bugs que vous avez manqués dans le monde propre et confortable du test unitaire et du framework moqueur (LINQ to SQL vient à l’esprit).

En fait, j'ai récemment découvert une approche
William Payne

0

Toujours l'utiliser, quelle que soit la taille de l'équipe. Si ce n'est que vous, par exemple, qui sait, vous pourriez coder à partir de votre ordinateur portable chez starbucks, puis continuer à partir de votre système plus costaud à la maison?

Les frais généraux ne sont vraiment pas si mauvais.


0

Une. Oui, un seul suffit pour commencer à utiliser l'intégration continue.


0

Ce n’est pas une question de combien de développeurs, mais de

une. Combien de temps vous gagnez en automatisation et à quelle fréquence.

  • Gain de temps pour la construction après les intégrations, l'exécution de tests automatisés et la création de configurations * fréquence d'enregistrement = pourcentage de temps gagné.

b. Combien de versions / branches / produits que vous avez.

  • Si vous avez un développeur travaillant sur deux branches différentes, le gain de temps est doublé, car chaque branche nécessiterait une construction, des tests et un conditionnement.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.