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.