Esta es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central varias veces al día tras lo cual se ejecutan automaticamente pruebas automáticas. El número de integraciones diarias es variable dependiendo del proyecto pero cuantas menos combinaciones se hagan del código al día más posibilidades hay de que ocurra un error denominado “Integration Hell*”.
El objetivo principal de esta práctica es encontrar y arreglar errores de forma mas proactiva, mejorar la calidad del software y reducir el tiempo que se tarda en validar y publicar versiones en el mercado.
Cómo funciona la integración continua
Como se puede comprobar en la imagen que se encuentra a continuación el proceso de integración no es muy extenso. Para implementar este proceso son necesarios dos servidores, el servidor de control de versiones el cual va a recibir todos los cambios de los desarrollos y el cual va a contener todas las versiones de la aplicación. El segundo servidor es el denominado “Build integration server” este servidor va a compilar la aplicación y realizar las pruebas automáticas sobre esta. Al cabo del proceso este servidor informa si el proceso ha sido completado satisfactoriamente o ha habido algún error.
Ventajas de esta práctica frente al desarrollo tradicional:
- Los desarrolladores pueden detectar y solucionar problemas de integración de forma continua, evitando el caos de última hora cuando se acercan las fechas de entrega.
- Disponibilidad constante de una versión para pruebas, demos o lanzamientos anticipados.
- Ejecución inmediata de las pruebas unitarias.
- Monitorización continúa de las métricas de calidad del proyecto.
Desventajas
- Con múltiples integraciones por día, se puede dar el caso de enviar el codigo de una funcionalidad incompleta. Por lo tanto, las pruebas de integración fallarán hasta que se complete la función por completo.
- Con equipos grandes, el nuevo código se agrega constantemente a la cola de integración. Esto hace que el seguimiento de las entregas (a la vez que se preserva la calidad) es difícil y las compilaciones en cola pueden ralentizar al equipo.
- La integración continua no es necesariamente valiosa si el alcance del proyecto es pequeño o contiene un código heredado no comprobable con pruebas automaticas.
