Hay un problema fundamental acerca de la Integración Continua (CI) que se refleja perfectamente en su pregunta: las prácticas de CI son difíciles de implementar y defender porque el software del servidor de CI no es trivial de configurar, ni es trivial para que sus proyectos funcionen a través de un CI servidor. Con esto, se hace difícil ver dónde está la ganancia de adoptar CI en absoluto.
En primer lugar, CI se trata de una visión y calidad. Good CI lo acerca a su proyecto, le brinda retroalimentación adecuada sobre métricas de calidad, documentación, cumplimiento de estándares de codificación, etc. Debe proporcionarle las herramientas para visualizar fácilmente todo esto y permitirle reconocer de un vistazo y fácilmente asocie un conjunto de cambios con una instantánea específica de todas estas métricas del proyecto.
No se trata solo de ejecutar pruebas unitarias. ¡De ningún modo! Lo que me lleva a la calidad. CI acepta errores, no los evita ni los tira. Lo que hace es simplemente proporcionarle una herramienta para error desde el principio, en lugar de más adelante. Por lo tanto, realmente no confirma el código probado previamente en un servidor CI. Aunque debe esforzarse por confirmar un código limpio y no roto, en realidad usa el servidor CI para ejecutar automáticamente un generador de integración automáticamente a través de su código y hacer que evalúe si todo salió bien. Si es así, ordenado! Si no lo ha hecho, no hay problema: las buenas prácticas de CI establecen que su próxima prioridad debería ser solucionar lo que se ha roto. Lo cual, en un buen servidor de CI, debería ser fácil de señalar para usted.
A medida que aumenta el tamaño de un equipo, la integración del código de todos naturalmente se vuelve más difícil. Debería ser tarea de un servidor de CI centralizado probar todas las partes integradas y quitar esa carga de los miembros del equipo. Por lo tanto, debe hacer que todos se comprometan temprano (y de la manera más limpia posible) y luego monitoreen el estado de las compilaciones (generalmente hay notificaciones involucradas). Y de nuevo, si algo se rompe debido a la confirmación de algún desarrollador, inmediatamente se convierte en su responsabilidad corregirlo y hacer que esas compilaciones automatizadas vuelvan a estar en estado OK inmediatamente.
Entonces, en mi opinión, cada proyecto se beneficia de estar continuamente integrado. La cuestión es que, hasta ahora y debido a la complejidad alucinante de cada servidor de CI que conozco, la gente realmente rechazó las prácticas de CI en proyectos más pequeños / simples. Porque, vamos, las personas tienen mejores cosas que hacer que pasar días configurando un software feo, demasiado complejo, poco entregado e inflado.
Tuve exactamente el mismo problema, y eso es lo que me hizo desarrollar Cintient en mi tiempo libre desde hace aproximadamente un año. Mi premisa era simplificar la instalación, la configuración y el uso, y hacer que cumpliera con las métricas de calidad que casi todos fallan o no cumplen. Entonces, después de esta larga respuesta viene mi descarado complemento de señalar el enlace de GitHub para el proyecto (que es gratuito y de código abierto, natch). También tiene algunas buenas capturas de pantalla, al parecer. :-) https://github.com/matamouros/cintient
Espero haberte ayudado.
(NOTA: Editado después del comentario de Bryan Oakley, sobre el hecho de que debería haber tomado más tiempo para elaborar una mejor respuesta. También creo que tenía razón).