Modela el futuro de la entrega de software y haz oír tu voz mediante la encuesta sobre el estado de DevOps de 2021.

Tecnología de DevOps: Integración continua

Los sistemas de software son complejos, y un cambio que puede parecer simple y puntual en un solo archivo puede tener efectos secundarios no deseados en todo el sistema. Cuando una gran cantidad de desarrolladores trabajan en sistemas relacionados, coordinar las actualizaciones de código es un problema difícil, y los cambios de diferentes desarrolladores pueden ser incompatibles.

La práctica de la integración continua (CI) se creó para abordar estos problemas. La CI sigue el principio de que si una tarea conlleva mucho tiempo y energía, debes realizarla con más frecuencia, lo que te obligará a hacerla menos trabajosa. Mediante la creación de ciclos de comentarios rápidos y la garantía de que los desarrolladores trabajen en lotes pequeños, la CI permite que los equipos produzcan software de alta calidad, reduzcan el costo del desarrollo y el mantenimiento continuos del software y aumenten la productividad de los equipos.

Cómo implementar la CI

Cuando la organización practica la CI, los desarrolladores integran todo su trabajo en la versión principal de la base de código (conocida como tronco, instancia principal o línea principal) de forma periódica. La investigación (PDF) de DevOps Research and Assessment (DORA) demuestra que los equipos tienen un mejor rendimiento cuando los desarrolladores combinan su trabajo con el tronco al menos una vez al día. Se ejecuta un conjunto de pruebas automatizadas antes y después de la combinación para validar que los cambios no introduzcan errores de regresión. Si estas pruebas automatizadas fallan, el equipo detiene lo que está haciendo para solucionar el problema de inmediato.

La CI garantiza que el software esté siempre en funcionamiento y que las ramas del desarrollador no difieran de manera significativa del tronco. Los beneficios de la CI son significativos: la investigación (PDF) demuestra que genera una mayor frecuencia de implementación, sistemas más estables y software de mayor calidad.

Los elementos clave para implementar con éxito la integración continua son los siguientes:

  • Cada confirmación debe activar una compilación del software.
  • Cada confirmación debe activar una serie de pruebas automatizadas que proporcionan comentarios en pocos minutos.

Para implementar estos elementos, necesitas lo siguiente:

  • Un proceso de compilación automatizado. El primer paso en la CI es tener una secuencia de comandos automatizada que cree paquetes que se puedan implementar en cualquier entorno. Los paquetes que creó la compilación de CI deben autorizarse y usarse en todos los procesos posteriores. Estas compilaciones deben estar numeradas y repetirse. Debes ejecutar el proceso de compilación de forma correcta al menos una vez al día.
  • Un conjunto de pruebas automatizadas. Si no tienes ninguno, comienza por escribir algunas unidades y pruebas de aceptación (PDF) que abarquen la funcionalidad de alto valor del sistema. Asegúrate de que las pruebas sean confiables. De esa manera, cuando fallan, sabes que hay un problema real, y cuando pasan, estás seguro de que no hay problemas serios con el sistema. Luego, asegúrate de que todas las funciones nuevas estén cubiertas por pruebas. Esas pruebas deben ejecutarse con rapidez para brindar comentarios a los desarrolladores lo antes posible. Las pruebas deben ejecutarse de forma correcta al menos una vez al día. En última instancia, si tienes pruebas de rendimiento y aceptación, los desarrolladores deben recibir comentarios de ellas a diario.
  • Un sistema de CI que ejecuta la compilación y las pruebas automatizadas en cada registro. El sistema también debe hacer que el estado sea visible para el equipo. Puedes divertirte con esto; por ejemplo, puedes usar bocinas o semáforos para indicar cuándo se daña la compilación. No uses notificaciones por correo electrónico; muchas personas las ignoran o crean un filtro que las oculta. Las notificaciones en un sistema de chat son una forma mejor y más popular de lograrlo.

La integración continua, según lo definido por Kent Beck y la comunidad de programación extrema donde se originó el término, también incluye dos prácticas adicionales que predicen un mayor rendimiento de la entrega de software:

La CI requiere pruebas de unidades automatizadas. Estas pruebas deben ser integrales para darte la confianza de que el software funciona como se espera. Las pruebas también deben ejecutarse en unos pocos minutos o menos. Si las pruebas de unidades automatizadas tardan más en ejecutarse, los desarrolladores no querrán ejecutarlas con frecuencia. Si las pruebas se ejecutan con poca frecuencia, una falla de prueba puede originarse a partir de muchos cambios diferentes, lo que dificulta la depuración. Las pruebas que se ejecutan con poca frecuencia son difíciles de mantener.

Crear conjuntos de pruebas de unidades automatizadas que se puedan mantener es complejo. Una buena manera de resolver este problema es practicar el desarrollo basado en pruebas (TDD), en el que los desarrolladores escriben pruebas automatizadas que primero fallan, antes de implementar el código que hace que las pruebas pasen. El TDD tiene varios beneficios, uno de los cuales es garantizar que los desarrolladores escriban código que sea modular y fácil de probar, lo que reduce el costo de mantenimiento de los conjuntos de prueba automatizados resultantes. Muchas organizaciones no cuentan con conjuntos de pruebas de unidades automatizadas que se puedan mantener y, a pesar de eso, aún no practican el TDD.

Objeciones a la CI

Como se describió antes, la CI a veces se considera una práctica controvertida. La CI requiere que los desarrolladores dividan las funciones grandes y otros cambios en pasos incrementales más pequeños que se puedan integrar con frecuencia en el tronco. Este es un cambio para los desarrolladores que no están acostumbrados a trabajar de esta manera. Además, cuando los equipos pasan a usar pasos pequeños, puede llevar más tiempo completar funciones grandes. Sin embargo, en general, no quieres aumentar la velocidad a la que los desarrolladores pueden declarar una función grande como completada en una rama. En cambio, deseas que los cambios se revisen, se integren, se prueben y se implementen lo más rápido posible. Este proceso hace que el desarrollo y la entrega de software sean más rápidos y estables (PDF) cuando los cambios son independientes y pequeños, y las ramas en las que residen son de corta duración. Trabajar en lotes pequeños también garantiza que los desarrolladores reciban comentarios regulares sobre el impacto de su trabajo en el sistema en general, por parte de otros desarrolladores, verificadores y clientes, así como de pruebas automatizadas de rendimiento y seguridad. Esto, a su vez, hace que sea más fácil y rápido detectar, clasificar y solucionar cualquier problema.

A pesar de estas objeciones, ayudar a los equipos de desarrollo de software a implementar la integración continua debe ser la prioridad número uno para cualquier organización que desee comenzar el camino hacia la entrega continua.

Errores comunes

Algunos errores comunes que impiden la adopción amplia de la CI incluyen los siguientes:

  • No poner todo en el repositorio de código. Todos los elementos necesarios para compilar y configurar la aplicación y el sistema deben estar en el repositorio. Esto puede parecer estar fuera del alcance de la CI, pero es un punto importante.
  • No automatizar el proceso de compilación. Los pasos manuales crean posibilidades de errores y dejan los pasos sin documentar.
  • No activar pruebas rápidas en cada cambio. Las pruebas completas de extremo a extremo son necesarias, pero las pruebas rápidas (por lo general, las pruebas de unidades) también son importantes para permitir comentarios rápidos.
  • No corregir las compilaciones dañadas de inmediato. Un objetivo clave de la CI es tener una compilación estable a partir de la cual todos puedan desarrollar. Si la compilación no se puede corregir en unos minutos, se debe identificar y revertir el cambio que causó la falla en la compilación.
  • Tener pruebas que tardan demasiado en ejecutarse. Las pruebas no deberían tardar más de unos minutos en ejecutarse, con un límite máximo de unos 10 minutos según la investigación de DORA (PDF). Si la compilación demora más, debes mejorar la eficiencia de las pruebas, agregar más recursos de procesamiento para que puedas ejecutarlas en paralelo o dividir las pruebas más largas en una compilación separada mediante el patrón de canalización de implementación.
  • No realizar combinaciones con el tronco con suficiente frecuencia. Muchas organizaciones tienen pruebas y compilaciones automatizadas, pero no aplican una combinación diaria con el tronco. Esto da lugar a ramas de larga duración que son mucho más difíciles de integrar y a ciclos de comentarios largos para los desarrolladores.

Formas de medir la CI

Los conceptos de CI que se analizaron antes describen formas de medir la eficacia de la CI en los sistemas y el entorno de desarrollo, como se muestra en la siguiente tabla. La recopilación de estas métricas te permite optimizar los procesos y las herramientas. Esto genera mejores prácticas de CI y ciclos de comentarios más cortos para los desarrolladores.

Factor a probar Qué medir
Las confirmaciones de código activan una compilación del software. El porcentaje de confirmaciones de código que dan como resultado una compilación de software sin intervención manual
Las confirmaciones de código activan una serie de pruebas automatizadas. El porcentaje de confirmaciones de código que dan como resultado un conjunto de pruebas automatizadas que se ejecutan sin intervención manual
Las compilaciones y pruebas automatizadas se ejecutan de forma correcta todos los días. El porcentaje de compilaciones y de pruebas automatizadas que se ejecutan de forma correcta todos los días
Las pruebas actuales están disponibles para las pruebas de exploración de los verificadores. La disponibilidad de las compilaciones para los verificadores, o al revés, es decir, la no disponibilidad de las compilaciones para los verificadores
Los desarrolladores reciben comentarios de las pruebas de aceptación y rendimiento todos los días. La disponibilidad de comentarios para los desarrolladores a partir de las pruebas de aceptación y rendimiento, es decir, el porcentaje de pruebas que proveen comentarios y que están disponibles para los desarrolladores en un día
Las compilaciones rotas se corrigen de inmediato. El tiempo que transcurre entre la falla de la compilación y su corrección, ya sea con un registro que soluciona el problema o con una reversión del cambio que generó el problema

Próximos pasos