Hay una sobrecarga asociada con la integración continua, por ejemplo, configuración, reentrenamiento, actividades de concientización, interrupción para corregir "errores" que resultan ser problemas de datos, separación forzada de estilos de programación de preocupaciones, etc.
¿En qué punto se paga la integración continua?
EDITAR: Estos fueron mis hallazgos
La configuración fue CruiseControl.Net con Nant, lectura de VSS o TFS.
Aquí hay algunas razones para el fracaso, que no tienen nada que ver con la configuración:
Costo de la investigación : el tiempo dedicado a investigar si una luz roja se debe a una verdadera inconsistencia lógica en el código, la calidad de los datos u otra fuente, como un problema de infraestructura (por ejemplo, un problema de red, una lectura de tiempo de espera del control de fuente, un servidor de terceros está abajo, etc., etc.)
Costos políticos sobre infraestructura : consideré realizar una verificación de "infraestructura" para cada método en la ejecución de la prueba. No tenía solución para el tiempo de espera, excepto para reemplazar el servidor de compilación. La burocracia se interpuso y no hubo reemplazo del servidor.
Costo de arreglar las pruebas unitarias : una luz roja debido a un problema de calidad de datos podría ser un indicador de una prueba unitaria mal escrita. Por lo tanto, las pruebas unitarias dependientes de los datos se reescribieron para reducir la probabilidad de una luz roja debido a datos incorrectos. En muchos casos, los datos necesarios se insertaron en el entorno de prueba para poder ejecutar con precisión sus pruebas unitarias. Tiene sentido decir que al hacer que los datos sean más sólidos, la prueba se vuelve más sólida si depende de estos datos. ¡Por supuesto, esto funcionó bien!
Costo de la cobertura, es decir, escribir pruebas unitarias para el código ya existente : existía el problema de la cobertura de las pruebas unitarias. Había miles de métodos que no tenían pruebas unitarias. Por lo tanto, se necesitaría una cantidad considerable de días hombre para crearlos. Como esto sería demasiado difícil de proporcionar un caso de negocios, se decidió que las pruebas unitarias se utilizarían para cualquier método público nuevo en el futuro. Aquellos que no tenían una prueba unitaria se denominaron 'potencialmente infrarrojos'. Un punto de prueba aquí es que los métodos estáticos eran un punto discutible en cómo sería posible determinar de manera única cómo había fallado un método estático específico.
Costo de los lanzamientos a medida : los guiones de Nant solo llegan hasta cierto punto. No son tan útiles para, por ejemplo, compilaciones dependientes de CMS para EPiServer, CMS o cualquier implementación de base de datos orientada a UI.
Estos son los tipos de problemas que ocurrieron en el servidor de compilación para ejecuciones de prueba por hora y compilaciones de control de calidad durante la noche. Considero que esto no es necesario ya que un maestro de compilación puede realizar estas tareas manualmente en el momento del lanzamiento, especialmente con una banda de un solo hombre y una pequeña compilación. Por lo tanto, las compilaciones de un solo paso no han justificado el uso de CI en mi experiencia. ¿Qué pasa con las compilaciones de varios pasos más complejas? Puede ser una tarea difícil de construir, especialmente sin un script de Nant. Entonces, incluso después de haber creado uno, estos no tuvieron más éxito. Los costos de solucionar los problemas de luz roja superaron los beneficios. Finalmente, los desarrolladores perdieron interés y cuestionaron la validez de la luz roja.
Después de intentarlo de manera justa, creo que CI es costoso y hay mucho trabajo en los bordes en lugar de solo hacer el trabajo. Es más rentable emplear desarrolladores experimentados que no hagan un desastre de grandes proyectos que introducir y mantener un sistema de alarma.
Este es el caso incluso si esos desarrolladores se van. No importa si un buen desarrollador se va porque los procesos que sigue asegurarán que escriba especificaciones de requisitos, especificaciones de diseño, se adhiera a las pautas de codificación y comente su código para que sea legible. Todo esto es revisado. Si esto no está sucediendo, entonces el líder de su equipo no está haciendo su trabajo, que debe ser recogido por su gerente, etc.
Para que CI funcione, no es suficiente escribir pruebas unitarias, intentar mantener una cobertura completa y garantizar una infraestructura de trabajo para sistemas de gran tamaño.
El resultado final: Uno podría preguntarse si corregir una cantidad de errores antes del lanzamiento es incluso deseable desde una perspectiva empresarial. CI implica mucho trabajo para capturar un puñado de errores que el cliente podría identificar en UAT o que la compañía podría recibir un pago por la reparación como parte de un acuerdo de servicio al cliente cuando el período de garantía expire de todos modos.