search
top

Aprende a implantar integración continua desde cero (I): ¿Por qué integración continua?

En este post, voy a hablar de integración continua de cara a una empresa que desarrolla software, y no de integración continua en empresas que subcontratan software, donde la integración continua también es beneficiosa, pero juega otro papel.

—–

La integración continua es una práctica de desarrollo software que me encanta,  porque tanto si te faltan elementos para llevarla a cabo como si no, implantarla aportará muchísimos beneficios a tu organización.

Para mi, implantar integración continua en una empresa lleva de la mano mejoras de la calidad del software en general, en todos sus ámbitos: proceso, producto y equipo.

La integración continua conlleva una mejora de la calidad del software

Calidad de proceso

En primer lugar, con la integración continua se le da más visibilidad al proceso de desarrollo en general, a todos los pasos que se siguen desde que se empieza a programar un requisito del cliente hasta que está en producción.

Así, todo el mundo sabe las fases por las que va pasando el código, y el estado del software en cada momento (si compila, si pasa las pruebas, en qué entorno está cada versión, qué versión se está probando etc).

También le damos visibilidad a la estrategia de gestión de configuración, política de ramas del control de versiones y tagueos, entre otras cosas.

Si todo el equipo no conocía esto bien, o las estrategias estaban poco definidas, con la integración continua habrá que solucionarlo.

Y esto ya es un avance importante, porque en muchas empresas a las que vamos, todas estas cosas imprescindibles no son conocidas por todo el equipo, ni están claras ni bien definidas.

Calidad de producto

Por otro lado, también se mejora la calidad del producto software.

El principal objetivo de la integración continua es detectar los errores lo más pronto posible, en fases tempranas del desarrollo, para poder solucionarlos rápidamente.

Así se introducen varios tipos de pruebas y comprobaciones, minimizando los riesgos, y haciendo que el software tenga menos bugs que si no realizáramos integración continua.

Por otra parte, en fases ya avanzadas de la integración continua se suelen lanzar inspecciones continuas de código, análisis periódicos para detectar problemas de calidad en él.

Los desarrolladores tendrán que mejorar esas deficiencias, e incluso en ciertas ocasiones, se puede impedir que los desarrolladores suban el código al control de versiones si no cumplen los estándares de calidad definidos por la empresa.

Calidad de las personas

Por último, también se mejora la calidad del equipo. Si no sabía, el equipo acaba aprendiendo a hacer distintos tipos de pruebas (unitarias, de integración), mejores prácticas de programación y en general a desarrollar código de mayor calidad.

Además, tener todo este proceso de desarrollo claro y tener todas estas comprobaciones para minimizar los riesgos, le da más confianza al equipo.

Así es capaz de afrontar nuevos retos, mejoras y cambios y está más motivado. Además de que le ahorra muchísimo tiempo, porque automatizamos procesos repetitivos (por ejemplo ciertas pruebas de regresión), dejando más tiempo para hacer otras cosas.

Y todo esto, al final se acaba reflejando en una mejora de cara al cliente y por supuesto en términos económicos para la empresa.

Bueno pero ¿qué es integración continua?

Una de las definiciones que más me gustan de integración continua es la de Martin Fowler, porque resume muy bien lo que conlleva el concepto.

Fowler define la integración continua como una:

Práctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente, al menos una vez al día. Cada integración se verifica con un build automático (que incluye la ejecución de pruebas) para detectar errores de integración tan pronto como sea posible.”

Muchas veces, se tiende a pensar que la integración continua es tener instalado el servidor de integración continua (por ejemplo Jenkins) y que este compile el código periódicamente; o tener automatizados los despliegues dándole a un botón desde dicho servidor.

Pero como ves, la integración continua engloba mucho más que esto. Es una serie de buenas prácticas, de comprobaciones interconectadas entre sí, para conseguir software de mejor calidad.

¿Y cuáles son esas buenas prácticas, esos componentes que intervienen en la integración continua?

Vamos a ir partiendo de la definición de Fowler para ir identificando los componentes e ideas claves de la integración continua.

1. “Práctica de desarrollo software”

Como ya comenté, la integración continua afecta al proceso de desarrollo del software, incorporando nuevas prácticas o interconectando las que ya había.

Para implantar integración continua solemos definir un “pipeline”, un conjunto de etapas, de fases por las que va pasando el software y que se automatizan.

Un ejemplo de un pipeline podría ser que con cada subida de código al repositorio de control de versiones este se descargue y compile.

Si está todo correcto, que se ejecuten una serie de pruebas unitarias, o se despliegue el código a otro entorno para hacer pruebas de sistema.

Por último, que se despliegue al entorno de QA, de pruebas, para realizar otro tipo de pruebas manuales. (Recuerda ¿Pruebas de integración, funcionales, de carga…? ¡Qué jaleo! ¿Qué diferencias hay?)

Esta es una de las primeras cosas que hay que definir, saber cómo es el desarrollo, cuál es el criterio para que el código promocione de un entorno a otro, y qué se hace en cada entorno.

Y si el código no pasa algún punto hay que establecer cuál es la estrategia para resolver el error, quién se encarga de ello, cómo se gestiona.

Este sería un ejemplo de cómo se vería un pipeline implementado en Jenkins.

pipeline2

Esto es a lo que me refería con visibilidad del proceso. Podremos saber qué revisión de código compila, cuál no y en qué punto del pipeline se encuentra cada subida del código.

2. “los miembros del equipo integran su trabajo frecuentemente”

¿Dónde se suele integrar, poner en común el trabajo que hace cada desarrollador? En el control de versiones.

En un equipo, el código que implementa cada desarrollador no suele actuar aislado.

Cuando se distribuye el trabajo entre los miembros del equipo, y cada uno comienza a trabajar, normalmente se asumen cosas de otros componentes del software que todavía no están implementados o que está programando otra persona.

Y hasta que no juntamos todo ese código, no nos damos cuenta de los errores de ese tipo que cometemos.

Antes, lo que se tendía a hacer es que cada desarrollador programara de forma independiente y luego al final se realizaba la integración de todo el código.

Esto se traduce en integraciones difíciles, que tardan mucho en completarse y mucho sufrimiento, ya que hay muchos cambios, mucho código que integrar.

Uno de los motivos por los que surge la integración continua es para evitar esto. La idea es que en vez de dejar la integración para el final, se vayan haciendo pequeñas integraciones de código frecuentemente.

La frase que podríamos aplicar aquí es que si algo te cuesta, debes hacerlo más a menudo y poco a poco, para que con el tiempo te vaya costando cada vez menos esfuerzo.

—–

Aunque trato de ir a lo esencial, este tema da para varios posts. La semana que viene terminaremos de ver lo que es integración continua y nos meteremos en un esquema típico de integración continua en la vida real.

Aquí tienes el siguiente post: Aprende a implantar integración continua desde cero (II): Un esquema simple de integración continua

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

5 Respuestas to “Aprende a implantar integración continua desde cero (I): ¿Por qué integración continua?”

  1. Johann Alexander Quintero Cortés dice:

    Muchas gracias por este post.

  2. eddy dice:

    Muchas gracias.

  3. Harry dice:

    Hola. Si bien la primera decisión *acertada* de una compañía dedicada a la fabricación de software, el manejo de líneas de productos de software, y el consultorio de arquitectura, es el montaje de líneas de integración continua, no deja de ser sólo el comienzo del viaje. Y como tu lo mencionaste, la gran mayoría de compañías no ha tomado esta decisión importante todavía. Mi punto es, cuales serian los pasos para la adopción (y el manejo del cambio) en una empresa que quiere o debe ir, y no lo sabe, a una línea de integración continua? Actualmente estoy en el grupo de arquitectura de mi compañía y estamos en este importante viaje de adopción de esta práctica.

  4. Conrado dice:

    Muy Bueno Ana, gracias por los conceptos claros y concisos!

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top