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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.