¿Cuál es el ROI de la Integración Continua?

Si está hablando con un gerente de programa estándar, puede encontrar que la integración continua es un poco difícil de entender en términos de ROI simple: no es obvio de inmediato qué producto físico obtendrán a cambio de una inversión en dólares dada.

He aprendido a explicarlo así: "La integración continua elimina clases enteras de riesgo de tu proyecto."

La gestión de riesgos es un problema real para los administradores de programas que está fuera del conocimiento normal de tipos de ingeniería de software que pasan más tiempo escribiendo código que preocupándose por cómo se gastan los dólares. Parte de trabajar con este tipo de personas de manera efectiva es aprender a expresar lo que sabemos que es bueno en términos que puedan entender.

Estos son algunos de los riesgos que explico en conversaciones como estas. Nota, con gestores de programas sensatos, ya he ganado el argumento después del primer punto:

1. Riesgo de integración: en una integración continua sistema de construcción, problemas de integración como "se olvidó de comprobar en un archivo antes de que se fue a casa para un fin de semana largo" son mucho menos propensos a causar todo un equipo de desarrollo a perder el valor de todo un viernes de trabajo. Ahorro para el proyecto evitando uno de estos incidentes = número de personas en el equipo (menos uno debido al villano que olvidó registrarse) * 8 horas por día de trabajo * tarifa por hora por ingeniero. Por aquí, eso equivale a miles de dólares que no se cargarán al proyecto. ROI ¡Gana!
2. Riesgo de regresión: con un conjunto de pruebas unitarias / automáticas que se ejecuta después de cada compilación, reduce el riesgo de que un cambio en el código rompa algo que solía funcionar. Esto es mucho más vago y menos seguro. Sin embargo, al menos está proporcionando un marco en el que algunas de las pruebas humanas más aburridas y consumidoras de tiempo (es decir, costosas) se reemplazan con automatización.
3. Riesgo tecnológico: la integración continua también le da la oportunidad de probar nuevas tecnologías componente. Por ejemplo, recientemente descubrimos que la actualización 18 de Java 1.6 estaba fallando en el algoritmo de recolección de basura durante una implementación en un sitio remoto. Debido a la integración continua, teníamos una gran confianza en que retroceder a la actualización 17 tenía una alta probabilidad de funcionar donde la actualización 18 no lo hizo. Este tipo de cosas es mucho más difícil de expresar en términos de un valor en efectivo, pero todavía se puede utilizar el argumento de riesgo: cierto fracaso del proyecto = malo. Rebaja agraciada = mucho mejor.

CI ayuda con el descubrimiento de problemas. Mida la cantidad de tiempo que se tarda actualmente en descubrir compilaciones rotas o errores importantes en el código. Multiplique eso por el costo para la compañía por cada desarrollador que use ese código durante ese período de tiempo. Multiplique eso por el número de veces que ocurren roturas durante el año.

Ahí está tu número.

Cada compilación exitosa es una versión candidata, por lo que puede entregar actualizaciones y correcciones de errores mucho más rápido.

Si parte de su proceso de compilación genera un instalador, esto también permite un ciclo de implementación rápido.

De Wikipedia:

• cuando las pruebas unitarias fallan o surge un error, los desarrolladores pueden revertir la base de código a un estado libre de errores, sin perder tiempo depurando
• los desarrolladores detectan y solucionan problemas de integración continuamente, evitando el caos de último minuto en las fechas de lanzamiento (cuando todos intentan verificar su versiones).
• alerta temprana de código roto/incompatible
• alerta temprana de cambios conflictivos
• unidad inmediata pruebas de todos los cambios
• disponibilidad constante de una compilación" actual " para fines de prueba, demostración o publicación
• retroalimentación inmediata a los desarrolladores sobre la calidad, funcionalidad o impacto en todo el sistema de código que están escribiendo
• el registro frecuente de código empuja a los desarrolladores a crear módulos, menos código complejo
• métricas generadas a partir de pruebas automatizadas y CI (como métricas de cobertura de código, código complexity, and features complete) focus developers on developing código funcional, de calidad y ayuda a desarrollar impulso en un equipo
• se requiere un conjunto de pruebas bien desarrollado para obtener la mejor utilidad

Usamos CI (Dos compilaciones al día) y nos ahorra mucho tiempo manteniendo el código de trabajo disponible para pruebas y versiones.

Desde el punto de vista del desarrollador CI puede ser intimidante cuando el Resultado de Compilación automática, enviado por correo electrónico a todo el mundo (desarrolladores, gerentes de proyecto, etc. sucesivamente.), decir: "Error al cargar la compilación DLL de 'XYZ.dll ' falló." y tú son el Sr. XYZ y saben quién eres :)!

Aquí está mi ejemplo de mis propias experiencias...

Nuestro sistema tiene múltiples plataformas y configuraciones con más de 70 ingenieros trabajando en la misma base de código. Sufrimos un éxito de construcción de alrededor del 60% para las configuraciones menos utilizadas y del 85% para las más utilizadas. Había una inundación constante de correos electrónicos sobre una base diaria sobre errores de compilación u otras fallas.

Hice algunos cálculos aproximados y estimé que perdimos un promedio de una hora al día por programador a malas construcciones, que suman casi 10 días-hombre de trabajo cada día. Eso no tiene en cuenta los costos que ocurren en el tiempo de iteración cuando los programadores se niegan a sincronizar con el código más reciente porque no saben si es estable, eso nos cuesta aún más.

Después de implementar un rack de servidores de compilación administrados por Team City, ahora vemos una tasa promedio de éxito del 98% en todas las configuraciones, el error promedio de compilación permanece en el sistema durante minutos y no horas y la mayoría de nuestros ingenieros ahora se sienten cómodos permaneciendo en la última revisión del código.

En general, diría que una estimación conservadora de nuestros ahorros totales fue de alrededor de 6 meses-hombre en los últimos tres meses del proyecto en comparación con los tres meses anteriores a la implementación de CI. Este argumento nos ha ayudado a asegurar recursos para expandir nuestros servidores de compilación y centrar más tiempo de ingeniería en pruebas automatizadas adicionales.

Nuestra mayor ganancia es tener siempre una compilación nocturna para QA. Bajo nuestro antiguo sistema, cada producto, al menos una vez a la semana, descubría a las 2 AM que alguien había ingresado un código defectuoso. Esto causó que nightly build for QA no probara, el remedio era enviar un correo electrónico a release engineering. Ellos diagnosticarían el problema y contactarían a un dev. A veces tomó tanto tiempo como el mediodía antes de QA realmente tenía algo para trabajar. Ahora, además de tener un buen instalador cada noche, en realidad instálelo en máquinas virtuales de todas las diferentes configuraciones compatibles cada noche. Así que ahora, cuando entra el control de calidad, pueden comenzar a probar en pocos minutos. Ahora, cuando se piensa en la forma antigua, QA entró agarró el instalador, encendió todas las máquinas virtuales, lo instaló, y luego comenzó a probar. Ahorramos QA probablemente 15 minutos por configuración para probar, por persona QA.

Hay servidores CI gratuitos disponibles, y herramientas de compilación gratuitas como NAnt. Puede implementarlo en su dev box para descubrir los beneficios.

Si está utilizando el control de código fuente y un sistema de seguimiento de errores, imagino que consistentemente ser el primero en reportar errores (minutos después de cada check-in) será bastante convincente. Agregue a eso la disminución en su propia tasa de errores, y probablemente tendrá una venta.

El ROI es realmente una capacidad para proporcionar lo que el cliente quiere. Por supuesto, esto es muy subjetivo, pero cuando se implementa con la participación del cliente final, verá que los clientes comienzan a apreciar lo que están obteniendo y, por lo tanto, tiende a ver menos problemas durante la Aceptación del usuario.

• ¿Ahorraría costos? no puede ser,
• ¿fallaría el proyecto durante UAT? definitivamente NO,
• ¿se cerraría el proyecto en el medio? - alta posibilidad cuando el los clientes encuentran que esto no entregaría el resultado esperado.
• ¿obtendrías datos en tiempo real y reales sobre el proyecto? - SÍ

Por lo que ayuda a fallar más rápido, lo que ayuda a mitigar los riesgos antes.