build process - programming - ¿Vale la pena una integración continua para proyectos pequeños?
continuous integration jenkins (7)
He estado presionando para la integración continua en mi empresa desde que me uní hace 5 meses, pero habiendo visto el tipo de aplicaciones en las que trabajamos, estoy empezando a pensar que tal vez no valga la pena el esfuerzo de configurar cada proyecto para integración continua.
Si trabajas en un departamento de desarrollo donde el proyecto promedio demora entre 2 y 3 semanas y una vez implementado, rara vez o nunca tendrás que preocuparte por él, ¿la integración continua vale la pena por la molestia de configurarlo?
Como han señalado otros, una vez que CI se configura, agregar un nuevo proyecto es trivial, así que yo diría que síganlo. Uno de los beneficios que verá es que si alguno de sus proyectos cambia alguna vez, ya tiene CI y, con suerte, las pruebas de su unidad estarán listas para que no le surjan sorpresas desagradables.
La integración continua no es solo una cuestión de herramienta, sino también un conjunto de procesos (comprometerse regularmente, tener un sistema de control de versiones ...).
Con respecto al software IC, puede instalar, configurar y comenzar a utilizar Hudson en menos de 10 minutos. Entonces, ¿por qué ir sin ningún sistema IC?
Personalmente, creo que CI y los diversos procesos que fomentan siempre son útiles. Obtener la configuración de CI es bastante trivial una vez que tiene el servidor configurado por sí mismo. Básicamente, solo copia un archivo de configuración de un proyecto, lo edita y crea un nuevo proyecto. No utilizaría CI por el "esfuerzo de configurar todos y cada uno de los proyectos".
Si sus muchas aplicaciones comparten componentes o módulos comunes, es probable que CI y las pruebas lo ayuden a notar algo que se rompe. Si en realidad son guiones autónomos, es posible que no necesites CI, pero es una decisión difícil.
La integración continua no solo garantiza que todo funcione, sino que también le permite DOCUMENTAR y PROBAR el proceso de lanzamiento tal como lo haría un nuevo desarrollador.
Esto asegura que el cliente obtenga lo que se ha probado, no lo que el desarrollador simplemente arroja desde su disco duro.
Esto puede ser extremadamente importante para fines de mantenimiento.
Realmente depende de qué tan rápido pueda configurar una compilación automática y luego conectarla a un servidor de CI.
.RED
Nos hemos visto pasar de una versión sin automatización a una versión automatizada para un proyecto en pocos minutos usando UppercuT. Usamos eso y CruiseControl.NET (en la configuración, agregamos una línea por proyecto b / c aprovechamos el preprocesador).
http://code.google.com/p/uppercut/
Algunas buenas explicaciones aquí: UppercuT
Probablemente depende de tu proceso. Si tiene pruebas unitarias que cubren su código, entonces la integración continua vale todo. Supongo que todos ustedes trabajan en un solo módulo de trabajo, ya que los proyectos duran de 2 a 3 semanas.
No creo que las personas hagan todas las pruebas para cada una de sus confirmaciones y la integración continua ayuda mucho aquí.
La otra razón sería si su proyecto está altamente modularizado. He trabajado en sistemas en los que hay muchos módulos y un desarrollador no sería funcional: probar todo el sitio web antes de comprometerse. Es posible que las cosas ni siquiera se compilen correctamente, ya que el otro módulo ni siquiera compilaría porque el desarrollador no revisó el código completo.
Recomiendo la integración continua de todos modos. Con configuraciones como Hudson y Cruisecontrol, no toma mucho tiempo configurarse y se paga rápidamente.