Combien de développeurs avant l'intégration continue devient efficace pour nous?
Il y a une surcharge associée à une intégration continue, par exemple, la mise en place, la ré-formation, les activités de sensibilisation, l'arrêt permettant de fixer des "bugs" qui s'avèrent être des problèmes de données, une séparation appliquée des préoccupations des styles de programmation, etc.
À quel moment l'intégration continue paie-t-elle pour elle-même?
Edit: C'étaient mes découvertes
La configuration était Cruisecontrol.net avec Nant, lecture de VSS ou TFS.
Voici quelques raisons de l'échec, qui n'ont rien à voir avec la configuration:
Coût de l'enquête: Le temps passé à étudier si un témoin rouge est dû 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, une question de réseau, une Lecture du délai d'attente à partir du contrôle de la source, le serveur tiers est en panne, etc., etc.)
Coûts politiques sur l'infrastructure: J'ai envisagé d'effectuer une vérification "d'infrastructure" pour chaque méthode dans le test de test. Je n'avais aucune solution au délai d'attente sauf pour remplacer le serveur de construction. Ruban rouge a eu lieu dans le chemin et il n'y avait pas de remplacement de serveur.
Coût des tests d'unité de fixation: Un voyant rouge due à un problème de qualité des données pourrait être un indicateur d'un test d'unité mal écrit. Ainsi, les tests d'unités de données dépendant des données ont été ré-écrits afin de réduire la probabilité d'un feu rouge en raison 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 d'unités. Il est logique de dire que, en apportant les données plus robustes, le test devient plus robuste s'il dépend de ces données. Bien sûr, cela a bien fonctionné!
Coût de la couverture, c'est-à-dire des tests d'unité d'écriture pour le code déjà existant: Il y avait le problème de la couverture des tests d'unité. Il y avait des milliers de méthodes qui n'avaient aucun test d'unité. Donc, une quantité importante de jours d'homme serait nécessaire pour les créer. Comme cela serait trop difficile à fournir une analyse de rentabilisation, il a été décidé que des tests unitaires seraient utilisés pour toute nouvelle méthode publique. Ceux qui n'ont pas eu de test unitaire ont été appelés "potentiellement infrarouge". Un point intestant ici est que les méthodes statiques étaient un point discutant de la manière 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 si loin. Ils ne sont pas aussi utiles pour, disons, des constructions dépendantes du CMS pour EpiServer, CMS ou tout déploiement de la base de données orienté UI.
Ce sont les types de problèmes survenus sur le serveur de construction pour les essais horaires et les constructions de QA de la nuit. Je dange que ceux-ci doivent être inutiles car un maître de construction peut effectuer ces tâches manuellement au moment de la sortie, en particulier, avec une bande d'un homme et une petite construction. Ainsi, des bâtiments à pas unique n'ont pas justifié l'utilisation de CI de mon expérience. Qu'en est-il des bâtiments plus complexes et multiset? Celles-ci peuvent être une douleur à construire, surtout sans script nant. Donc, même en avoir créé un, ceux-ci n'étaient pas plus réussis. Les coûts de la fixation des problèmes de lumière rouge l'emportent sur les avantages. Finalement, les développeurs ont perdu des intérêts et ont interrogé la validité de la lumière rouge.
Après avoir donné une foire, je pense que CI coûte cher et il y a beaucoup de travail autour des bords au lieu de simplement faire le travail. Il est plus rentable d'employer des développeurs expérimentés qui ne font pas gâcher de 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 part, car les processus qu'il suit garantiraient d'écrit des spécifications d'exigence, des spécifications de conception, des bâtons sur les directives de codage et des commentaires de 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 ramassé par son responsable et ainsi de suite.
Pour que CI fonctionne, il ne suffit pas d'écrire des tests d'unité, de tenter de maintenir une couverture complète et d'assurer une infrastructure de travail pour des systèmes importants.
la ligne inférieure : On pourrait se demander si la fixation de nombreux bugs avant la libération est même souhaitable d'une entreprise. CI implique beaucoup de travail pour capturer une poignée de bugs que le client pourrait identifier à UAT ou à la société pourrait être payé pour la fixation dans le cadre d'un contrat de service à la clientèle lorsque la période de garantie expire de toute façon.
La mise en place d'un moteur CI s'apparente à la mise en place d'une alarme incendie dans une maison.
Dans mon esprit, les avantages ne corrélent pas avec de nombreux développeurs, mais avec une base de code importante. Le moteur CI fait activement tout le travail ennuyeux que vous ne voulez pas faire vous-même, et le faire à chaque fois.
Si vous cassez un module distant que vous n'avez pas touché depuis longtemps, vous vous êtes dit immédiatement. Non seulement la compilation sage, mais également de manière à fonctionner si vous avez mis en place des tests d'unité.
Notez également que si vous vous laissez CI-Engine do tous Le travail ennuyeux, y compris la configuration des installateurs, etc., vous n'avez pas à le faire manuellement. Vous pouvez simplement vérifier votre source et attendre le produit fini en cours de construction dans l'emplacement standard. (EDIT: Le moteur CI fonctionne également dans un environnement bien défini, en évitant les configurations spécifiques au développeur, garantissant la reproductibilité)
Cela fait également partie de l'assurance de la qualité.
Edit: Après avoir écrit ce qui précède, j'ai eu de l'expérience avec l'outil de construction Maven pour Java. Cela nous permettra essentiellement de conserver la configuration CI complète à l'intérieur du projet (avec pom.xml), ce qui facilite beaucoup la maintenance de l'installation CI et/ou de la migrer vers un autre moteur CI.
Ce n'est pas combien de développeurs, mais combien de marches il faut pour aller de 1 à N (inclusif), où 1 & N sont ...
1: Vérification du code
Et
[.____] N: avoir des packages\déployables installables
Si n <2 vous peut-être n'avez pas besoin de CI
Sinon, vous avez besoin de CI
Mise à jour
[.____] de lire vos conclusions, je ne peux que conclure que vous avez approché CI de la mauvaise direction et des mauvaises raisons.
Cela peut valoir l'effort même pour une équipe d'un. Cela est particulièrement vrai lorsque vous développez du code multiplate-forme et vous devez vous assurer que vos modifications fonctionnent sur les deux plates-formes. Par exemple, le compilateur C++ de Microsoft est plus acceptable que GCC, de sorte que si vous développez sous Windows mais que vous devez également prendre en charge Linux, disposer d'un système CI vous indique lorsque votre construction se casse sur Linux est une aide énorme.
Certains systèmes CI sont assez faciles à installer, de sorte que les frais généraux ne sont pas vraiment si énormes. Essayez Jenkins ou Hudson par exemple.
Comme vous le dites, il y a un coût des frais généraux de la configuration et de la maintenance.
Mais la question de savoir où est la pause, le point même n'est pas une fonction de combien de personnes que vous avez dans votre équipe, mais plutôt une fonction de votre projet.
Cela dit, il y a une partie du coût de configuration que vous pouvez utiliser dans tous vos projets futurs, donc à long terme, les frais généraux peuvent contacter zéro.
J'ai mis en place Jenkins cette semaine pour construire un petit projet .NET que je travaille. Je l'ai intégré avec mon contrôle de source GIT afin qu'il ait déclenché une construction sur chaque commit. J'ai intégré les tests de l'unité dans la construction. J'ai une analyse statique intégrée sous la forme de violations FXCOP et de stylécop.
Maintenant, chaque fois que j'enregistre, il vérifie tout mon code, le construit, incrémente le numéro de version sur tous les assemblages, le teste, l'analyse pour les violations FXCOP et STYLécop, archive la construction et enregistre les résultats dans un certain nombre de graphiques. J'ai une visibilité avec le temps des résultats des tests et des violations.
Faire cela à partir de zéro prend une heure environ (peut-être une journée avec Google si vous n'avez pas fait avant). Cela ne coûte rien car tous les outils sont disponibles gratuitement.
Si, comme et lorsque le projet construit, j'ai une infrastructure de haute qualité qui grandira avec elle sans frais. Si ou lorsque de nouveaux développeurs rejoignent le projet, je peux obtenir une visibilité totale sur leur travail et leur impact sur le projet sans frais.
Donc, le seul scénario que je puisse voir CI ne valant pas la peine d'être, soit pour un projet qui prendra une journée environ, puis ne sera jamais revisité, ni une langue dans une langue où il n'y a pas d'outils existants/libres disponibles et le coût de l'acquisition est disproportionné pour le travail.
CI en vaut toujours toujours toujours la peine: le sens de la sécurité qu'il vous donne vous permet de travailler à un taux plus rapide que ce serait possible autrement. Le problème que vous avez semble tourner autour des tests unitaires. Je conviens que les tests d'unités sont très chers, mais je pense aussi que (pour beaucoup de choses), ils sont la moindre pire option que nous avons. Personnellement, et pour les types de systèmes que j'ai tendance à travailler, je jure par des tests au niveau du système opérant sur une combinaison de cas pathologiques réels et (éventuellement synthétiques); Il est moins cher que les tests unitaires et pénètre dans les coins difficiles à atteindre de votre univers conceptuel: "inconnues inconnues" de Donald Rumsfeld.
Si vous pouvez vérifier tous les aspects de votre projet après chaque changement, vous n'avez pas besoin de CI.
Dans tous les autres cas, c'est une victoire nette.
Les frais généraux sont minimes. Je dirais pour un seul homme que ce serait utile. Une fois que vous avez atteint deux, c'est inestimable.
Je conviens que pour un homme des projets si vous avez une "étape de construction/vérification", vous serez peut-être d'accord avec une intégration continue, mais dans ces cas, vous avez fait la majeure partie du travail acharné pour configurer CI afin que cela puisse aussi bien mettre Dans un système formel (CC, Hudson, TeamCity, etc.).
La question de, quand la CI paie-t-elle elle-même est difficile à répondre à un nouveau projet.
Sur un projet existant, il est beaucoup plus facile de voir. Si vous trouvez un bogue critique à la pièce de développement de la chaîne d'approvisionnement, vous savez que le problème existe au plus tôt possible. Le coût de la fixation qui est maintenant le plus bas. Si ce problème existe dans des environnements supérieurs au développement, votre coût est plus élevé.
Maintenant, la direction pourrait décider de libérer avec un bogue, mais c'est un risque d'entreprise. Au moins maintenant, il peut être atténué par cette évaluation des risques, plutôt que des appels de téléphonie/panique de nuit à la nuit, qui, s'ils ont été facturés à des tarifs horaires, finissent par être puissantes coûteuses.
Une autre chose à considérer en termes de coût. Quel est votre département QA? Est-ce que c'est des tests manuels? Si vous allez CI, vous pourrez peut-être réduire les coûts globaux de l'assurance qualité en automatisant ces scripts contre votre boîte de développement. Vous pourrez peut-être réduire le nombre de personnes QA prenant en charge votre projet en les composant dans la phase CI.
Ce n'est pas une question de combien de développeurs, mais de
une. Combien de temps vous économisez à l'aide de l'automatisation et de la fréquence.
- Temps enregistré sur la construction après intégration, exécutant des tests automatisés et création de configurations * Fréquence de l'enregistrement = pourcentage du temps enregistré.
b. Combien de versions/de branches/produits que vous avez.
- Si vous avez un développeur travaillant sur deux branches différentes, le temps enregistré est doublé, car chaque branche nécessiterait des bâtiments, des tests et des emballages.
Toujours l'utiliser, quelle que soit la taille de l'équipe. Si c'est juste vous, par exemple, qui sait, vous pouvez coder de votre ordinateur portable à Starbucks, puis continuez de votre système de ceieu de la maison à la maison?
La surcharge n'est vraiment pas si mauvaise.
Une. Oui, on suffit pour commencer à utiliser une intégration continue.