¿Cuántos desarrolladores antes de que la integración continua sea efectiva para nosotros?

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.

Configurar un motor CI es similar a configurar una alarma de incendio en una casa.

En mi opinión, los beneficios no se correlacionan con muchos desarrolladores, sino con una gran base de código. El motor CI hace todo el trabajo aburrido que no desea hacer usted mismo, y lo hace siempre.

Si interrumpe un módulo remoto que no ha tocado en mucho tiempo, se le informa de inmediato. No solo es una compilación inteligente, sino también funcional si ha configurado pruebas unitarias.

También tenga en cuenta que si deja que CI-engine haga todo el trabajo aburrido, incluida la instalación de instaladores, etc., no tiene que hacerlo manualmente. Puede verificar su fuente y esperar a que el producto terminado se construya en la ubicación estándar. (EDITAR: el motor CI también funciona en un entorno bien definido, evitando cualquier configuración específica del desarrollador, asegurando la reproducibilidad)

Esto también es parte del aseguramiento de la calidad.

EDITAR: Después de escribir lo anterior, he tenido experiencia con la herramienta de compilación Maven para Java. Esencialmente, esto nos permite mantener la configuración de CI completa dentro del proyecto (con pom.xml), lo que hace que sea mucho más simple mantener la instalación de CI y / o migrar a otro motor de CI.

No se trata de cuántos desarrolladores, sino cuántos pasos se necesitan para llegar de 1 a n (inclusive), donde están 1 & n ...

1: Conceptos básicos acerca de código
Y
n: tener instalable \ paquetes de despliegue

Si n <2 quizás no necesite CI
, de lo contrario, necesita CI

Actualización Al
leer sus hallazgos, solo puedo concluir que se acercó a CI desde la dirección incorrecta y por los motivos equivocados.

Puede valer la pena incluso para un equipo de uno. Esto es especialmente cierto cuando está desarrollando código multiplataforma y necesita asegurarse de que sus cambios funcionarán en ambas plataformas. Por ejemplo, el compilador de C ++ de Microsoft acepta más que GCC, por lo que si desarrolla en Windows pero necesita admitir Linux también, tener un sistema de CI le avise cuando su compilación se rompa en Linux es de gran ayuda.

Algunos sistemas de CI son bastante fáciles de configurar, por lo que la sobrecarga no es realmente tan grande. Prueba Jenkins o Hudson, por ejemplo.

Como usted dice, hay un costo adicional de configurarlo y mantenerlo en funcionamiento.

Pero la cuestión de dónde está el punto de equilibrio no es una función de cuántas personas tiene en su equipo, sino una función de la duración de su proyecto.

Dicho esto, hay una parte del costo de instalación que puede usar en todos sus proyectos futuros, por lo que a largo plazo el costo indirecto puede acercarse a cero.

Configuré Jenkins esta semana para construir un pequeño proyecto .NET en el que estoy trabajando. Lo integré con mi control de fuente Git para que activara una compilación en cada confirmación. Integré las pruebas unitarias en la construcción. Integré el análisis estático en forma de violaciones de FxCop y StyleCop.

Ahora, cada vez que me registre, verifica todo mi código, lo compila, incrementa el número de versión en todos los ensamblajes, lo prueba, lo analiza en busca de violaciones de FxCop y StyleCop, archiva la compilación y registra los resultados en una serie de gráficos. Tengo visibilidad en el tiempo de los resultados de las pruebas y las infracciones.

Hacerlo desde cero lleva aproximadamente una hora (tal vez un día con Google si no lo ha hecho antes). No cuesta nada porque todas las herramientas están disponibles de forma gratuita.

Si, a medida que se construye el proyecto, tengo una infraestructura de alta calidad que crecerá sin costo alguno. Si o cuando nuevos desarrolladores se unen al proyecto, puedo obtener visibilidad total de su trabajo y su impacto en el proyecto sin costo alguno.

Entonces, el único escenario en el que puedo ver que CI no vale la pena es para un proyecto que tomará un día más o menos y luego nunca será revisado, o uno en un idioma donde no hay herramientas disponibles / gratuitas disponibles y el costo de adquirirlas es desproporcionado para el trabajo.

Si puede verificar todos los aspectos de su proyecto después de cada cambio, entonces no necesita CI.

En todos los demás casos, es una ganancia neta.

Los gastos generales son mínimos. Yo diría que para proyectos de un hombre sería útil. Una vez que alcanzas dos es invaluable.

Estoy de acuerdo en que para proyectos de un solo hombre si tiene una "compilación / verificación en un solo paso", entonces podría estar bien con la integración continua, pero en esos casos ha hecho la mayor parte del trabajo duro para configurar CI, así que podría simplemente poner en un sistema formal (CC, Hudson, TeamCity, etc.).

La pregunta de cuándo CI se paga sola es difícil de responder en un nuevo proyecto.

En un proyecto existente, es mucho más fácil de ver. Si encuentra un error crítico en la parte de desarrollo de la cadena de suministro, sabrá que el problema existe lo antes posible. El costo de la reparación que ahora es el más bajo. Si ese problema existe en cualquier entorno superior al desarrollo, su costo es mayor.

Ahora, la administración podría decidir lanzar con un error, pero eso es un riesgo comercial. Al menos ahora puede mitigarse a través de esa evaluación de riesgos, en lugar de llamadas telefónicas / pánico a altas horas de la noche, que, si se facturaban a tarifas por hora, terminarían siendo muy caras.

Otra cosa a considerar en términos de costo. ¿Cómo es su departamento de control de calidad? ¿Es una prueba manual? Si va a CI, es posible que pueda reducir los costos generales de control de calidad al automatizar esos scripts en su cuadro de desarrollo. Es posible que pueda reducir la cantidad de personas de control de calidad que apoyan su proyecto al involucrarlos en la fase de CI.

CI siempre vale la pena: la sensación de seguridad que le brinda le permite trabajar a un ritmo más rápido de lo que sería posible de lo contrario. El problema que tiene parece girar en torno a las pruebas unitarias. Estoy de acuerdo en que las pruebas unitarias son muy caras, pero también creo que (para muchas cosas) son la peor opción que tenemos. Personalmente, y para los tipos de sistemas en los que tiendo a trabajar, juro por las pruebas a nivel de sistema que operan en una combinación de casos patológicos del mundo real y (posiblemente sintéticos); Es más barato que las pruebas unitarias, y entra en esos rincones difíciles de alcanzar de su universo conceptual: las "incógnitas desconocidas" de Donald Rumsfeld.

Úselo siempre, independientemente del tamaño del equipo. Si solo eres tú, por ejemplo, quién sabe, ¿podrías estar codificando desde tu computadora portátil en Starbucks y luego continuar desde tu sistema más robusto en casa?

Los gastos generales realmente no son tan malos.

Uno. Sí, uno es suficiente para comenzar a usar la integración continua.

No se trata de cuántos desarrolladores, sino de

a. Cuánto tiempo ahorra usando la automatización y con qué frecuencia.

• Tiempo ahorrado en la construcción después de las integraciones, ejecutando pruebas automatizadas y creando configuraciones * frecuencia de check-in = porcentaje de tiempo ahorrado.

si. Cuántas versiones / sucursales / productos tiene.

• Si tiene un desarrollador trabajando en dos sucursales diferentes, el tiempo ahorrado se duplica, ya que cada sucursal requeriría construcción, prueba y empaque.