Quel est le retour sur investissement de l'intégration continue?

Question

À l'heure actuelle, notre organisation ne pratique pas l'intégration continue.

Pour que nous puissions faire pour obtenir une place de serveur CI et en cours d'exécution, je vais devoir produire un document prouvant le retour sur l'investissement.

En plus des économies de coûts par la recherche et la correction des bugs au début, je suis curieux de savoir d'autres avantages / économies que je pourrais coller dans ce document.

Answer 1

Mon raison # 1 pour aimer CI est qu'il aide à empêcher les développeurs de vérifier dans le code cassé qui peut parfois paralyser toute une équipe. Imaginez si je fais un enregistrement important impliquant des changements de schéma db droit avant de partir pour les vacances. Bien sûr, tout fonctionne très bien sur ma boîte de dev, mais j'oublier de vérifier dans le schéma db changescript qui peuvent ou peuvent ne pas être trivial. Eh bien, maintenant il y a des changements complexes concernant les nouveaux / champs modifiés dans la base de données, mais personne qui est dans le bureau le lendemain a fait ce nouveau schéma, maintenant l'ensemble de l'équipe est en baisse pendant que quelqu'un regarde en reproduisant le travail que vous avez déjà fait et juste oublié de l'enregistrement.

Et oui, j'ai utilisé un exemple particulièrement agressif avec des changements db, mais il pourrait être quelque chose, vraiment. Peut-être un enregistrement partiel avec un code emailing qui provoque alors tous vos devs de spam vos réels utilisateurs finaux? Vous nommez ...

Donc, à mon avis, ce qui évite une seule de ces situations fera le retour sur investissement d'une telle entreprise rentable très rapidement.

Answer 2

Si vous parlez à un gestionnaire de programme standard, ils peuvent trouver l'intégration continue d'être un peu difficile à comprendre en termes de retour sur investissement simple: il est pas évident quel produit physique qu'ils vont obtenir en échange d'un dollar donné investissement.

Voici comment je l'ai appris à expliquer: «L'intégration continue élimine des classes entières de risque de votre projet »

La gestion des risques est un réel problème pour les gestionnaires de programme qui est en dehors de la portée normale de types de génie logiciel qui passent plus de temps à écrire du code que de se préoccuper de la façon dont les dollars se dépensés. Une partie de travailler avec ce genre de personnes est effectivement apprendre à exprimer ce que nous savons être une bonne chose en termes qu'ils peuvent comprendre.

Voici quelques-uns des risques que je débitent dans les conversations comme celles-ci. Remarque, les gestionnaires de programme sensibles, je l'ai déjà gagné l'argument après le premier point:

1. risque d'intégration: dans un système de construction à base d'intégration continue, les problèmes d'intégration comme « il a oublié de vérifier dans un fichier avant de rentrer chez un long week-end » sont beaucoup moins susceptibles de provoquer une équipe de développement pour perdre son ensemble vendredi la valeur du travail. Économies au projet éviter un tel incident = nombre de personnes dans l'équipe (moins un en raison du méchant qui a oublié de vérifier dans) * 8 heures par jour de travail * Taux horaire par ingénieur. Ici, que les sommes à des milliers de dollars qui ne seront pas imputés au projet. ROI Win!
2. Risque de régression: avec un test unitaire / suite de test automatique qui court après chaque construire, vous réduisez le risque qu'un changement au code casse quelque chose qui utilisent au travail. Cela est beaucoup plus vague et moins assurée. Cependant, vous êtes au moins un cadre dans lequel fournirez certains des plus ennuyeux et beaucoup de temps (à savoir, coûteux) test humain est remplacé par l'automatisation.
3. Risque technologique: intégration continue vous donne également l'occasion d'essayer de nouveaux composants technologiques. Par exemple, nous avons récemment constaté que Java 1.6 mise à jour 18 plantait dans l'algorithme de collecte des déchets lors d'un déploiement sur un site distant. En raison de l'intégration continue, nous avons eu une grande confiance que la sauvegarde vers le bas pour mettre à jour 17 avait une forte probabilité de travail où la mise à jour n'a pas 18. Ce genre de chose est beaucoup plus difficile de formuler en termes d'une valeur monétaire, mais vous pouvez toujours utiliser l'argument du risque: un échec certain du projet = mauvais. déclassement Graceful = beaucoup mieux.

Answer 3

CI aide à la découverte d'émission. Mesurer la quantité de temps actuellement qu'il faut pour découvrir brisé construit ou bugs majeurs dans le code. Multiplier par le coût pour la société pour chaque développeur en utilisant ce code pendant ce laps de temps. Multipliez ce chiffre par le nombre de fois se produisent au cours de la casses année.

Il y a votre numéro.

Answer 4

Chaque construction réussie est un candidat de libération - de sorte que vous pouvez fournir des mises à jour et corrections beaucoup plus rapidement des correctifs

.

Si une partie de votre processus de construction génère un programme d'installation, cela permet un cycle de déploiement rapide ainsi.

Answer 5

De Wikipedia :

• lorsque les tests unitaires échouent ou un bug se dégage, les développeurs pourraient revenir le code de base à un état sans bug, sans perdre de temps le débogage
• les développeurs de détecter et de résoudre les problèmes d'intégration continue - en évitant le chaos de dernière minute à date de sortie, (quand tout le monde essaie de vérifier leur peu incompatibles versions).
• alerte précoce code cassé / incompatible
• alerte précoce des changements contradictoires
• les tests unitaires immédiate de toutes les modifications
• disponibilité constante d'une construction « en cours » pour les tests, démonstration, ou libérer des fins
• un retour immédiat aux développeurs sur la qualité, la fonctionnalité ou l'impact du système à l'échelle du code qu'ils écrivent
• enregistrement de code fréquentes pousse les développeurs à créer modulaire, moins code complexe
• les mesures générées par les tests automatisés et CI (tels que les mesures de couverture de code, le code la complexité et les caractéristiques complètes) mettent l'accent sur le développement de développeurs code de qualité fonctionnelle, et aider à développer l'élan dans une équipe
• test de suite bien développé nécessaire pour meilleur utilitaire

Nous utilisons CI (deux construit un jour) et il nous permet de gagner beaucoup de code de travail tenue de temps disponible pour le test et la libération.

D'un point de vue du développeur CI peut être intimidant quand le résultat automatique de construction, envoyé par e-mail à tout le monde (développeurs, chefs de projets, etc., etc.), dit:   « Erreur de chargement de DLL de construction « xyz.dll » a échoué. » et vous êtes M. XYZ et ils savent qui vous êtes :)!

Answer 6

Voici mon exemple de mes propres expériences ...

Notre système a de multiples plates-formes et configurations avec plus de 70 ingénieurs travaillant sur la même base de code. Nous avons souffert de quelque part autour de 60% pour les succès construire configs moins couramment utilisés et 85% pour les plus couramment utilisés. Il y avait un flot constant d'e-mails sur une base quotidienne la compilation des erreurs ou d'autres défaillances.

Je l'ai fait quelques calculs approximatifs et a estimé que nous avons perdu en moyenne une heure par jour et par programmeur de mauvais construit, qui totalise près de 10 jours homme de travail tous les jours. Cela ne tient pas compte des coûts qui se produisent dans le temps d'itération lorsque les programmeurs refusent de synchroniser le dernier code parce qu'ils ne savent pas si elle est stable, qui nous coûte encore plus.

Après avoir déployé un rack de serveurs de construction gérés par équipe de la ville, nous voyons maintenant un taux de réussite moyen de 98% sur tous les configs, l'erreur de compilation moyenne reste dans le système pendant quelques minutes non en quelques heures et la plupart de nos ingénieurs sont maintenant à l'aise de rester à la dernière révision du code.

En général, je dirais qu'une estimation prudente sur nos économies globales était environ 6 mois homme de temps au cours des trois derniers mois du projet par rapport aux trois mois avant le déploiement de CI. Cet argument nous a permis d'obtenir des ressources pour étendre nos serveurs de construire et de se concentrer plus de temps d'ingénieur sur les tests automatisés supplémentaires.

Answer 7

Notre plus grand gain, est de toujours avoir une nightly build pour l'AQ. Dans le cadre de notre ancien système chaque produit, au moins une fois par semaine, découvririez à 2h du matin que quelqu'un avait vérifié dans le mauvais code. Ceci ne pose pas la nuit pour construire QA tester avec, le remède était d'envoyer un e-mail libération d'ingénierie. Ils diagnostiquer le problème et contactez un dev. Parfois, il a fallu aussi longtemps que midi avant QA avait effectivement quelque chose à travailler. Maintenant, en plus d'avoir un bon installateur tous les soirs, nous installons en fait sur les machines virtuelles de toutes les différentes configurations prises en charge tous les soirs. Alors maintenant, quand QA arrive, ils peuvent commencer à tester en quelques minutes. Maintenant, quand vous pensez à l'ancienne, QA est venu a saisi l'installateur, a tiré toutes les VMs, installé, puis a commencé à tester. Nous économisons QA probablement 15 minutes par configuration pour tester sur, par personne QA.

Answer 8

Il existe des serveurs de CI gratuits disponibles et des outils de construction gratuits comme NAnt. Vous pouvez la mettre en œuvre sur votre boîte de dev pour découvrir les avantages.

Si vous utilisez le contrôle de la source, et un système de suivi des bogues, je pense que d'être toujours le premier à rapporter les bogues (quelques minutes après chaque check-in) sera assez convaincant. Ajoutez à cela la baisse de votre taux de bug, et vous aurez probablement une vente.

Answer 9

Le retour sur investissement est vraiment une capacité à fournir ce que le client veut. Ceci est bien sûr très subjectif, mais lorsque mis en œuvre avec la participation du client final, vous verrez que les clients commence à apprécier ce qu'ils obtiennent, et donc vous avez tendance à voir moins de problèmes lors de la réception de l'utilisateur.

• Ne serait-il réduire les coûts? peut-être pas,
• serait le projet échouer pendant UAT? Absolument pas,
• serait fermé le projet entre les deux? - possibilité élevée lorsque les clients trouvent que ce ne serait pas livrer le résultat attendu.
• voulez-vous obtenir en temps réel et des données réelles sur le projet - YES

Il aide à ne plus rapide, ce qui contribue à atténuer les risques plus tôt.