El objetivo de este proceso es permite combinar diferentes componentes software para trabajar juntos. La integración se puede realizar a diferentes niveles o etapas de la implementación, para los siguientes propósitos:

• Integrar el trabajo del equipo que trabaja en un mismo subsistema.
• Integrar subsistemas dentro de un sistema completo.

El software debe de ser integrado incrementalmente, donde el código es escrito y probado en pequeñas piezas y después se combina pieza a pieza, no todas las piezas al mismo tiempo. La integración incremental permite obtener los siguientes beneficios:

• Los errores se localizan más fácilmente.
• Los componentes son mejor probados (testeados).
• Algunas partes del sistema pueden estar funcionando antes.

La integración debe de realizarse en cada Iteración o Sprint. El objetivo de la estrategia de integración es determinar el orden en el cual los componentes son implementados y combinados. La reunión de Planificación de Sprint, nos determina los componentes que se tienen que integrar y el orden de integración. De esta reunión se producen los JIRAs asociados al Sprint, el campo clasificación de cada JIRA, determina el orden en que tienen que integrarse los componentes, ya de determina el orden de creación de estos.

Se DEBE crear un JIRA con los siguientes datos, donde también se añade el tiemplo empleado en realizar y ejecutar los Test de integración y en la subida al repositorio SVN.

Esta tarea se realiza de forma incremental. La podemos realizar al final del Sprint o iteración, o conforme se vayan resolviendo los JIRAs del proceso de desarrollo y se deben seguir los siguientes pasos:

1. El integrador tiene que tener una copia de trabajo que este en la revisión en la que se inicio el Sprint o Iteración.
2. El integrador se actualizara el proyecto a la revisión del siguiente JIRA resuelto del proceso de desarrollo, siguiendo el orden de resolución de estos.
3. Una vez actualizada la copia de trabajo, se debe de probar que el código integrado y el resto de componentes de la aplicación cumplan los requisitos con los que fueron definidos, es decir, que funcionen correctamente.

Si el código funciona correctamente, se resolverá el JIRA del proceso de desarrollo asociado al código integrado. Si se produce algún error, se reabrirá la incidencia asociada indicando la causa del error producido y como puede reproducirse.

Este proceso suele tratar con dos tipos de artefactos: el código interno del propio proyecto u otros subsistemas del proyecto. Pero se suelen realizar los mismo pasos para realizar la integración.

Para ayudarnos en esta tarea, podemos utilizar el servidor de integración continua Jenkins, que compila y pasa los test todas las noches el proyecto. De esta forma se pueden detectar errores de forma más rápida. Solo tenemos que ir al Servidor Jenkins y buscar nuestro proyecto para comprobar la ultima ejecución automática. Si el circulo del resultado de la build es azul, todo ha ido correctamente, si es amarillo algún proceso de la tarea ha fallado y si es rojo la build a fallado completamente.

Si la bola es amarilla o roja, tendremos que revisar la ejecución de la build, dirigiéndonos a la pantalla de resultados de la propia build y ver la salida de la consola para ver que proceso a fallado y realizar las correcciones necesarias.

Cada día de trabajo, el arquitecto debe de indicar las horas trabajadas en la tarea.

Lo puede hacer desde JIRA, vamos a la tarea, y en el menú asociado a esta pinchamos en, Más Acciones –> Registrar Horas de Trabajo y en la pantalla que aparece, introduciremos la información sobre el trabajo realizado en dicho periodo de tiempo.

En ambos casos tendremos que rellenar la siguiente información.

Para almacenar la información utilizaremos el botón Registrar.

En muchas ocasiones es necesario definir test de integración. Los tests de integración se encargan de comprobar que los diferentes componentes de nuestro sistema funcionan como es debido, y que interactuan como se espera dentro de sistemas que imitan al entorno de producción que nos vamos a encontrar.

Nótese que la palabra integrar aquí adquiere un significado algo ambiguo y se refiere tanto a integrar dos piezas de software que se deben comunicar entre sí, como a integrar esas piezas de software en un entorno de ejecución determinado.

Ya que estamos en desarrollo utilizando un lenguaje orientado a objetos, un test de integración también puede ser considerado con un test unitario. Para crear test de integración, seguiremos la Guía Técnica de Test Unitarios que se indica en la Guía Técnica de Test Unitarios que se indica en la Normativa de Desarrollo de Aplicaciones FundeWeb v1.0. También puedes consultar la Normativa de Desarrollo de Aplicaciones FundeWeb v2.0.

Cada día de trabajo, el arquitecto debe de indicar las horas trabajadas en la tarea.

Lo puede hacer desde JIRA, vamos a la tarea, y en el menú asociado a esta pinchamos en, Más Acciones –> Registrar Horas de Trabajo y en la pantalla que aparece, introduciremos la información sobre el trabajo realizado en dicho periodo de tiempo.

En ambos casos tendremos que rellenar la siguiente información.

Para almacenar la información utilizaremos el botón Registrar.

Para aceptar a una pila test integración de un componente o subsistema, todas los test integración tienen que ser satisfactorios. Hay que realizar test que comprueben también los errores. Los test se ejecutaran en las siguientes herramientas:

• En el IDE Eclipse mediante el plugin TestNG para aplicaciones FundeWeb.

Cada día de trabajo, el arquitecto debe de indicar las horas trabajadas en la tarea.

Lo puede hacer desde JIRA, vamos a la tarea, y en el menú asociado a esta pinchamos en, Más Acciones –> Registrar Horas de Trabajo y en la pantalla que aparece, introduciremos la información sobre el trabajo realizado en dicho periodo de tiempo.

En ambos casos tendremos que rellenar la siguiente información.

Para almacenar la información utilizaremos el botón Registrar.

Para finalizar el proceso, tenemos que subir los test de integración creados o modificados al repositorio SVN, se puede utilizar tanto el IDE Eclipse con su plugin subeclipse como el Tortoise SVN.

La operación u operaciones SVN commit relacionadas con la subida de los test de integración creados o modificados, tienen que llevar en el comentario o mensaje, los identificadores de las tareas JIRA, que indican la realización de esta tarea.

Una vez subidos los artefactos al repositorio SVN, podemos resolver los JIRAs asociados a las tareas de Crear o Modificar Componente y a Crear y Ejecutar Test Unitarios de los Componentes.

Para cerrar un JIRA, podemos hacerlo desde JIRA, vamos a la tarea, y en el menú asociado a esta pinchamos en, Flujo de Trabajo –> Cerrar Incidencia y en la pantalla que aparece, introduciremos la información sobre el trabajo realizado en dicho periodo de tiempo.

Una vez rellenada la información relativa a la imputación en la tarea del trabajo realizado no computado anteriormente tenemos que pinchar el botón Cerrar.

De esta forma se cierra la tarea.

Ahora podemos cerrar el JIRA asociado a la tarea del proceso de Integración.

Para resolver un JIRA, podemos hacerlo desde JIRA, vamos a la tarea, y en el menú asociado a esta pinchamos en, Flujo de Trabajo –> Cerrar Incidencia y en la pantalla que aparece, introduciremos la información sobre el trabajo realizado en dicho periodo de tiempo.

Una vez rellenada la información relativa a la imputación en la tarea del trabajo realizado no computado anteriormente tenemos que pinchar el botón Cerrar.

De esta forma se resuelve la tarea.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Desarrollo-DE-Organizar el código

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

Número de clases de test integración totales al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Ir al informe TestNG, en este informe nos muestra los paquetes de código con test.
4. Seleccionamos en cada enlace referente a un paquete de código de test. En la página a la que se navega, aparecen dos tablas, en la primera aparecen las clases de Test, en la segunda aparecen los test ejecutados en el paquete.
5. Para el calculo de la métrica, hay que contar las filas de la primera tabla.

Número de test totales que hay en las clases de test integración al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Entrar en el informe del Sprint, Build o Release.
4. En el resumen de TestNG aparecen el número total de test.