Análisis de la integración continua
La integración continua es una de las ocho capacidades de la taxonomía de DevOps.
Explicación de la necesidad de la integración continua
El 23 de septiembre de 1999, la Mars Climate Orbiter replegó sus paneles solares para protegerlos durante un descenso temporal hacia la capa superior de la atmósfera de Marte.
Después de haber entrado correctamente en órbita, se suponía que el satélite debía enviar fotos de Marte a la Tierra durante varios años. Pero, lamentablemente, la nave ardió en la atmósfera de Marte.
Un error en el software de control de tierra, suministrado por un tercero, calculó el valor en unidades imperiales, libra-segundos. El software creado por la NASA esperaba que el valor estuviera en unidades métricas, newton-segundos. Puesto que estos valores no se convirtieron correctamente, se acumularon pequeñas discrepancias en la posición de la nave espacial a lo largo de millones de kilómetros.
Control de calidad no detectó el uso de unidades imperiales en el software externo, a pesar de que en los estándares de codificación de la NASA de ese momento se exigía el uso de unidades métricas. Los cálculos además se realizaron manualmente en lugar de usar el software suministrado debido a errores de formato de archivo y errores varios. Esta situación es un ejemplo de la necesidad de la integración continua.
Exploración de la integración continua
La integración continua es una mentalidad y una estrategia de equipo. Además de eso, el autor y conferenciante Martin Fowler dice que la integración continua es un procedimiento de desarrollo de software en el que los miembros de un equipo integran su trabajo con frecuencia, normalmente cada persona integra al menos cada día, lo que resulta en varias integraciones al día.
Cada integración se comprueba mediante una compilación automatizada (que incluye pruebas) para detectar los errores de integración lo más rápido posible.
Si se hace correctamente, este enfoque se traduce en menos problemas de integración al detectarlos en una fase anterior del proceso.
Los objetivos de la integración continua son:
- Aprovechar la colaboración
- Habilitar el desarrollo paralelo
- Minimizar la deuda de integración
- Actuar como puerta de calidad
- Automatizar todo
Nota:
Tenga en cuenta que los objetivos de la integración continua incluyen la colaboración continua, la entrega continua y la calidad continua.
Pero ¿qué ocurre si no hay integración continua? Una carencia de esfuerzos de integración continua suele dar lugar a:
- Ciclos de desarrollo largos
- Código que no se compila
- En cualquier momento, es posible que el código fuente no sea funcional
- Congelaciones del código
- Altos recuentos de errores de compilación u otros
- Ramas de larga duración que provocan esfuerzos de combinación de varios días
- Falta de código en el control de código fuente
- Detección de errores de seguridad en el ciclo de desarrollo
- Gran cantidad de deuda técnica
- Sin números de cobertura de código o pocos
- Calidad global reducida
- Comunicación y colaboración limitadas
- Código que no sigue los estándares de codificación
- Ninguna revisión de código o pocas
- Pruebas realizadas en una fase tardía del ciclo de desarrollo
- En muchos casos, manual, si la hay
Los puntos de integración son el bucle de reacciones rápido que se usa para mejorar el sistema. Cuando hay un error en el control de tiempo de los puntos de integración, el proyecto está en problemas. Esto es lo que Dantar Oosterwal dice sobre ellos en el libro The Lean Machine:
La epifanía de los puntos de integración es que controlan el desarrollo del producto. Son los puntos de aprovechamiento para mejorar el sistema. Cuando hay un error en el control de tiempo de los puntos de integración, el proyecto está en problemas.
Dantar Oosterwal, The Lean Machine
© Scaled Agile, Inc.
Si se pregunta si el equipo está llevando a cabo realmente la integración continua, estas preguntas pueden ayudarle a determinar la respuesta.
- ¿Todos los desarrolladores realizan desarrollo basado en ramas?
- ¿Todos los cambios en una rama desencadenan un proceso de compilación?
- Si se produce un error en la compilación y las pruebas, ¿el equipo corrige la compilación en cuestión de minutos?
El rendimiento también se ve influido por la presencia o ausencia de integración continua. Los datos recopilados y analizados del libro The Science Of DevOps – Accelerate – Building and scaling high performing technology organizations de Nicole Forsgren, Jez Humble y Gene Kim muestran que cuando aumenta la velocidad de comercialización de equipos de bajo rendimiento, se reduce su calidad.
Pero los equipos de alto rendimiento pueden mantener la calidad a la vez que aumentan la velocidad de comercialización. Tienen ciclos de implementación más cortos (y menos complejos) y usan la integración continua para corregir los problemas inmediatamente, lo que aumenta el flujo y la eficacia.
| 2017 | Equipos de alto rendimiento | Equipos de rendimiento medio | Equipos de bajo rendimiento |
|---|---|---|---|
| Frecuencia de implementación | Varias al día | 1 semana - 1 mes | 1 semana - 1 mes |
| Plazo del cambio | < 1 hora | 1 semana - 1 mes | 1 semana - 1 mes |
| MTTR | < 1 hora | < 1 día | 1 día - 1 semana |
| Tasa de errores de cambio | 0-15 % | 0-15 % | 31-45% |