Gracias a esta divisi\u00f3n del bloque de funcionalidades, el equipo de desarrollo puede centrarse \u00fanica y exclusivamente en la misma fase de trabajo, si el cliente cambia los requisitos s\u00f3lo afecta a la iteraci\u00f3n actual y una mala implementaci\u00f3n de las funcionalidades no interfiere con el trabajo realizado en anteriores iteraciones.<\/p>\n
Este m\u00e9todo de desarrollo, se adapta con resultados muy atractivos a algunas de las pr\u00e1cticas adoptadas del extreme programming<\/em><\/a> que utilizamos en inLab como la integraci\u00f3n continua<\/a>. En pocas palabras, \u00e9ste modelo de trabajo pretende que el equipo de desarrollo integre su c\u00f3digo diariamente, que dicho c\u00f3digo pase una serie de pruebas predefinidas por los programadores para verificar su correcto funcionamiento y que el despliegue del producto est\u00e9 disponible en cualquier momento ya sea en un sistema de pre-producci\u00f3n o incluso en uno de producci\u00f3n.<\/p>\n \u00abIntegration is primarily about communication. Integration allows developers to tell other developers about the changes they have made. Frequent communication allows people to know quickly as changes develop.\u00bb<\/em><\/p>\n – Martin Fowler, 1 May 2006, Continuous Integration<\/p>\n En el d\u00eda a d\u00eda, antes de empezar a programar, cada desarrollador actualiza su entorno bajando los \u00faltimos cambios del repositorio de c\u00f3digo compartido, si existe cualquier conflicto debe resolverlo y a partir de aqu\u00ed puede empezar a dise\u00f1ar una de las nuevas funcionalidades. Para ello, utilizamos TDD<\/a>, otra de las pr\u00e1cticas del extreme programming<\/em> preparando las pruebas que validar\u00e1n el comportamiento de dichas funcionalidades, implementando la funcionalidad y comprobando que los test definidos anteriormente se ejecutan correctamente. Una vez terminada la funcionalidad, el desarrollador es libre de enviar su aportaci\u00f3n al repositorio antes de repetir el mismo proceso para otra funcionalidad. De esta forma, cada d\u00eda un s\u00f3lo desarrollador realiza varios commits<\/em> con peque\u00f1os cambios, facilitando la detecci\u00f3n de errores y la comprensi\u00f3n de los cambios para otros miembros del equipo. Antes de terminar la jornada el desarrollador tiene que compartir sus cambios, para ello antes tiene que descargarse las aportaciones de sus compa\u00f1eros, resolver posibles conflictos, verificar que todos los test funcionan y finalmente enviar sus cambios al repositorio.<\/p>\n Es en este flujo de trabajo donde entran en juego los sistemas de integraci\u00f3n continua, automatizando y facilitando algunas de estas tareas desde la construcci\u00f3n del proyecto hasta el despliegue del mismo.<\/p>\n Los sistemas de integraci\u00f3n continua son entornos que pretenden gestionar estos procesos de forma aut\u00f3noma liberando as\u00ed a los programadores de estas labores. T\u00edpicamente detectan los cambios en el desarrollo de los proyectos, lanzan la bater\u00eda de test para controlar que el comportamiento del software es el deseado y despliegan en una m\u00e1quina de desarrollo todo el c\u00f3digo. No obstante, los procesos que acabamos de listar son tan s\u00f3lo algunos de una extensa colecci\u00f3n que nos facilitan algunos software de integraci\u00f3n continua.<\/p>\n Las diversas tareas que ejecutan estos sistemas suelen representarse visualmente mediante tarjetas ordenadas que, en caso de funcionar lanzan la siguiente tarea y en caso de fallar pueden llegar a avisar al equipo de desarrollo para que revisen qu\u00e9 ha pasado. Incluso se puede llegar a configurar algunas tarjetas para que su ejecuci\u00f3n tenga que ser lanzada manualmente, podr\u00eda ser el caso de un despliegue del software a un entorno de producci\u00f3n, el cual no siempre nos interesar\u00e1 hacer.<\/p>\n Entre las ventajas que aporta la inclusi\u00f3n de estos sistemas en los proyectos encontramos la detecci\u00f3n de errores en cada iteraci\u00f3n del c\u00f3digo, la disponibilidad del proyecto construido en todo momento y la seguridad de tener la implantaci\u00f3n en el entorno de producci\u00f3n ya comprobada.<\/p>\n Hay multitud de herramientas de integraci\u00f3n continua: Jenkins<\/a>, Hudson<\/a>, Bamboo<\/a>, Solano<\/a>, CruiseControl<\/a>\u2026<\/p>\n En inLab utilizamos este tipo de herramientas en diversos proyectos, tomaremos como ejemplo un proyecto de aplicaciones m\u00f3viles formado por una API, una aplicaci\u00f3n m\u00f3vil y una web de administraci\u00f3n gestionados por Jenkins.<\/p>\n Cada cierto tiempo Jenkins revisa si existe alg\u00fan cambio en la rama de desarrollo del repositorio y si es as\u00ed inicia el flujo de trabajo. Este per\u00edodo de tiempo es parametrizable, tambi\u00e9n se puede lanzar manualmente.<\/p>\n Una vez iniciado el flujo, la primera tarjeta trae la \u00faltima versi\u00f3n del c\u00f3digo, construye el proyecto descargando sus dependencias y preparando el espacio de trabajo para la ejecuci\u00f3n de las siguientes tarjetas.<\/p>\n Una vez el proyecto est\u00e1 listo, se inician dos tarjetas en paralelo, son las de ejecuci\u00f3n de test unitarios de la API y la de test de la aplicaci\u00f3n m\u00f3vil. Al terminar los test unitarios de la API, una nueva tarjeta se encarga de lanzar los test de integraci\u00f3n migrando previamente los \u00faltimos cambios producidos en la base de datos.<\/p>\n Ejecutando este tipo de pruebas en un sistema de integraci\u00f3n continua como Jenkins conseguimos validar el buen funcionamiento del proyecto en un entorno independiente del nuestro.<\/p>\n Si las tarjetas de test de la API tienen \u00e9xito, la siguiente tarjeta desplegar\u00e1 la API a la m\u00e1quina de pre-producci\u00f3n mientras otra tarjeta ejecuta los test de calidad de la API.<\/p>\n En la tarjeta de calidad hemos configurado varios plugins que nos proporcionan informaci\u00f3n acerca del software que estamos desarrollando. Gracias a un plugin para Jenkins llamado Clover PHP<\/a> en la tarjeta de calidad obtenemos m\u00e9tricas de la cantidad de c\u00f3digo cubierto por los test. DRY Plugin<\/a> nos genera una vista donde obtenemos informaci\u00f3n acerca de la posible duplicaci\u00f3n de c\u00f3digo en el proyecto. Otro plugin, PMD Warnings<\/a> nos muestra alertas sobre el mal funcionamiento o uso incorrecto de nuestro c\u00f3digo clasific\u00e1ndolas en distintos niveles de prioridad. Por \u00faltimo, JDepend Plugin<\/a> ense\u00f1a las dependencias entre clases y posibles ciclos en el dise\u00f1o del software.<\/p>\n <\/p>\n Una vez el despliegue en la m\u00e1quina de pre-producci\u00f3n est\u00e9 listo podremos lanzar manualmente la tarjeta de los test de carga. Estos permiten comprobar el correcto funcionamiento del c\u00f3digo en una m\u00e1quina que ser\u00e1 lo m\u00e1s parecida posible a la m\u00e1quina de producci\u00f3n.<\/p>\n Cuando los test de calidad hayan acabado de forma satisfactoria, Jenkins nos permitir\u00e1 lanzar de forma manual el despliegue de la API en la m\u00e1quina de producci\u00f3n. Este proceso tiene que ser manual porque no siempre nos interesar\u00e1 reemplazar la API ya existente.<\/p>\n Adem\u00e1s, como punto extra, existe una \u00faltima tarjeta que lanza el despliegue de la web de administraci\u00f3n. Este punto es posterior al lanzamiento de la API porque la web es dependiente de ella.<\/p>\n Paralelamente, la compilaci\u00f3n de la versi\u00f3n de desarrollo de la aplicaci\u00f3n se realiza en un servidor externo y los ficheros generados son recuperados por Jenkins para subirlos a una web de uso interno. Todo este proceso se realiza en una \u00fanica tarjeta.<\/p>\n Si la tarjeta anterior se ha ejecutado de forma correcta, Jenkins nos permitir\u00e1 lanzar exactamente el mismo proceso pero generando una versi\u00f3n firmada para producci\u00f3n y preparando los archivos APK y IPA listos para distribuir en Play Store para Android y en App Store para iOS.<\/p>\n En caso de que cualquier tarjeta falle, a trav\u00e9s de un plugin<\/a> hemos configurado Jenkins para que nos notifique v\u00eda Slack<\/a> en un canal concreto. Adem\u00e1s, para algunos procesos que requieren cierto tiempo o se tratan de despliegues a producci\u00f3n Jenkins tambi\u00e9n nos avisar\u00e1 al finalizar.<\/p>\n No debemos olvidar que este tipo de sistemas pretenden automatizar procesos pero no redimen al desarrollador de la programaci\u00f3n de pruebas ni de la configuraci\u00f3n de los despliegues de entornos de pre-producci\u00f3n y producci\u00f3n.<\/p>\n![\"tareas](\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2016\/10\/tarjetas.png\")
\u200b<\/p>\n![\"ejemplo](\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2016\/10\/ejemplo_proyecto.png\")
\u200b<\/p>\n![\"Clover](\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2016\/10\/clover_coverage_report.png\")
Figura 1: Ejemplo de informe de cobertura de c\u00f3digo de Clover PHP<\/div>\n![\"PMD](\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2016\/10\/pmd_warning.png\")
\u200bFigura 2: Ejemplo de alerta de PMD Warnings<\/div>\n