version control - integracion - ¿Cuáles son algunos argumentos en contra del uso de la integración continua?
pipeline integracion continua (6)
La única buena razón para no hacer una integración continua se produce cuando ha logrado que su proyecto funcione hasta el punto en que sus pruebas de integración no hayan identificado ningún defecto en mucho tiempo y estén tardando demasiado tiempo en ejecutarse cada vez que lo haga. una construcción. En otras palabras: has hecho suficiente integración continua que te has probado a ti mismo que ya no la necesitas.
Puedo pensar en muchas buenas razones para usarlo; sin embargo, ¿cuáles son las desventajas?
(Además de comprar otro servidor)
¿Cuáles son algunas ventajas de usar una compilación diaria en lugar de usarla?
No creo que haya inconvenientes. Pero por el bien de la discusión, aquí está el artículo de Eric Minick sobre UrbanCode ("Se trata de pruebas, no construcciones") . Critica las herramientas que se basan en el trabajo de Martin Fowler diciendo que no dejan suficiente tiempo para las pruebas.
"Para ser realmente exitoso en CI, Fowler afirma que la construcción debe ser de autocomprobación y que estas pruebas incluyen pruebas unitarias y de extremo a extremo. Al mismo tiempo, la construcción debe ser muy rápida, idealmente menos de diez minutos - porque debe ejecutarse en cada confirmación. Si hay un número significativo de pruebas de extremo a extremo, ejecutarlas en tiempo de compilación mientras se mantiene todo el proceso en menos de diez minutos no es realista.
Agregue la demanda de una compilación en cada compromiso, y los requisitos comienzan a parecer improbables. Las opciones son una retroalimentación más lenta o la eliminación de algunas pruebas ".
Cuando se inicia, toma un tiempo configurar todo.
Si agrega pruebas, cobertura, inspecciones de código estático, búsqueda duplicada, creación de documentación y despliegues, puede tomar mucho tiempo (semanas) hacerlo bien. Después de eso, mantener la construcción puede ser un problema.
por ejemplo, si agrega pruebas a la solución, puede hacer que la compilación las detecte automáticamente en función de algunos criterios o tiene que actualizar las configuraciones manualmente. La detección automática es mucho más difícil de hacer bien. Lo mismo para la cobertura. Igual a la generación de documentación ...
(Vale la pena señalar que por "integración continua" me refiero a la integración automatizada con un proceso de construcción automatizado y automáticamente ejecuta pruebas y detecta automáticamente el fallo de cada pieza.
También vale la pena señalar que la "integración continua" solo significa un tronco o servidor de prueba. No significa "empujar cada cambio en vivo".
Hay muchas formas de hacer una integración continua incorrecta).
No puedo pensar en ninguna razón para no hacer pruebas de integración continua. Supongo que estoy asumiendo que la "integración continua" incluye pruebas. El hecho de que compila no significa que funcione.
Si su compilación y / o pruebas toman mucho tiempo, la integración continua puede ser costosa. En ese caso, ejecute las pruebas obviamente relacionadas con su cambio antes de la confirmación (las herramientas de análisis de cobertura, como Devel :: CoverX :: Covered pueden ayudarlo a descubrir qué pruebas corresponden a qué código), haga su prueba de integración después del commit usando algo como SVN :: Notificar y alertar a los desarrolladores si falla. Archive los resultados de la prueba usando algo como Smolder . Eso permite a los desarrolladores trabajar rápidamente sin tener que sentarse a mirar cómo se ejecutan los bancos de pruebas, a la vez que detecta los errores al principio.
Dicho esto, con un poco de trabajo, a menudo puede acelerar su proceso de compilación y prueba. Muchas veces las pruebas lentas son el resultado de que cada prueba tiene que hacer demasiada configuración y desmontaje apuntando a un sistema que está demasiado acoplado y que requiere que todo el sistema se configure solo para probar una pieza pequeña.
El desacoplamiento a menudo ayuda, dividiendo los subsistemas en proyectos independientes. El alcance más pequeño facilita la comprensión y las compilaciones y pruebas más rápidas. Cada compromiso puede hacer una compilación completa y probar sin molestar al programador. Luego, todos los subproyectos pueden reunirse para realizar pruebas de integración.
Una de las principales ventajas de ejecutar el conjunto de pruebas en cada confirmación, incluso si es posterior al compromiso, es que usted sabe exactamente lo que rompió la compilación. En lugar de "algo que hicimos ayer rompió la construcción", o peor, "cuatro cosas que hicimos ayer rompieron la construcción de diferentes maneras y ahora tenemos que desentrañarlo" es "la revisión 1234 rompió la construcción". Solo tiene que examinar esa revisión para encontrar el problema.
La ventaja de hacer una compilación diaria es que, al menos, usted sabe que todos los días se lleva a cabo una compilación y compilación limpias y completas. Pero deberías estar haciendo eso de todos modos.
En general, hay dos casos en los que he visto que la integración continua no tiene sentido. Tenga en cuenta que soy un gran defensor de CI y trato de usarlo cuando puedo.
El primero es cuando el roi simplemente no tiene sentido. Actualmente desarrollo varias aplicaciones internas pequeñas. Las aplicaciones son normalmente muy triviales y todo el ciclo de vida del desarrollo es de aproximadamente una semana o dos. Para configurar correctamente todo para CI probablemente duplicaría eso y probablemente nunca volvería a ver esa inversión. Puede argumentar que lo recuperaré en el mantenimiento, pero es probable que estas aplicaciones se descarten a medida que se actualicen. Tenga en cuenta que su trabajo probablemente sea enviar software, no alcanzar el 100% de cobertura de código.
El otro escenario que he escuchado mencionar es que CI no tiene sentido si no vas a hacer nada con los resultados. Por ejemplo, si su software debe enviarse al control de calidad, y el personal de control de calidad solo puede ver una nueva versión cada dos días, no tiene sentido tener compilaciones cada pocas horas. Si otros desarrolladores no van a mirar las métricas del código y tratan de mejorarlas, no tiene sentido rastrearlas. De acuerdo, esto no es culpa de que CI no sea una buena técnica, es la falta de su equipo dispuesto a abrazar a CI. Sin embargo, implementar un sistema de CI en tal escenario no tiene sentido.
James Shore tuvo una gran serie de entradas de blog sobre los peligros de pensar que el uso de una herramienta de CI como CruiseControl significaba que estaba haciendo una integración continua:
- Por qué no me gusta CruiseControl
- La integración continua es una actitud, no una herramienta
- Integración continua en un dólar por día
Un peligro de configurar un servidor de CI es el desplazamiento de objetivos, pensando que lo importante es "mantener el desarrollo de compilación" en lugar de "garantizar que tengamos software de alta calidad". Entonces la gente deja de preocuparse por el tiempo que tardan las pruebas en correr. Luego tardan demasiado en ejecutarlos todos antes de registrarse. Entonces la construcción se sigue rompiendo. Entonces la construcción siempre está rota. Entonces la gente comenta las pruebas para hacer que la construcción pase. Y la calidad del software disminuye, pero bueno, la construcción está pasando ...