MANUAL DE USUARIO Normativa para el desarrollo con Subversion de varias líneas paralelas (correctivo / evolutivo)

Transcripción

1 MANUAL DE USUARIO Normativa para el desarrollo con Subversion de varias líneas paralelas (correctivo / evolutivo) Versión 1.2 Área de Aplicaciones Especiales y Arquitectura de Software

2 Hoja de Control Título Documento de Referencia Responsable ICM Versión 1.2 Fecha Versión 21/11/ Revisado/Validado por: Fecha Revisión/Validación 2 Aprobado por: Fecha Aprobación Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 1.0 Versión inicial del documento - Modificado procedimiento para que v0 siempre sea la rama actual (el trunk). - Incluido nuevo apartado 4.2.1: Publicación en los entornos de ICM no productivos - Añadida nueva norma ICMGestionaEntornos - Añadida nueva norma ICMApruebaEvolutivo Área de Aplicaciones Especiales y Arquitectura de Software 14/06/ Normas modificadas: - EvolutivoCreaBranch: El trunk siempre es la rama "v0" - CorrectivoIntegraBranch: La fusión se hará sobre el trunk, el responsable del correctivo ya no tiene que cambiar de carpeta de trabajo. - EvolutivoIntegraBranch: La fusión se hará sobre el trunk - ICMGestionaFusion: La fusión se hará sobre el trunk - CorrectivoMantieneFusion: El trunk es siempre la carpeta "v0" - EvolutivoEstabilizaCommit: El trunk es siempre la carpeta "v0" Área de Aplicaciones Especiales y Arquitectura de Software 19/11/ Apartado 5.2: Corrección de error, había quedado un sitio donde no se indicaba que la fusión se hacía sobre v0. Área de Aplicaciones Especiales y Arquitectura de Software 21/11/2013 Página 2 de 60

3 Índice 1 INTRODUCCIÓN AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS NORMAS GENERALES HERRAMIENTA INSTALACIÓN DE SUBCLIPSE CON COLLABNET MERGE CLIENT USO DE TRUNK Y BRANCH FASE 1: ARRANQUE DEL PROYECTO Y CREACIÓN DEL BRANCH FASE 1: NORMAS PARA EL RESPONSABLE DEL CORRECTIVO FASE 1: NORMAS PARA EL RESPONSABLE DEL EVOLUTIVO FASE 1: NORMAS PARA EL RESPONSABLE DE ICM FASE 2: DESARROLLO DEL PROYECTO E INTEGRACIÓN CONTÍNUA FASE 2: NORMAS PARA EL RESPONSABLE DEL CORRECTIVO FASE 2: NORMAS PARA EL RESPONSABLE DEL EVOLUTIVO PUBLICACIÓN EN LOS ENTORNOS DE ICM NO PRODUCTIVOS ACTUALIZACIÓN PERIÓDICA (SYNC MERGE) VISTA GRÁFICA DE LAS REVISIONES INTEGRADAS FASE 2: NORMAS PARA EL RESPONSABLE DE ICM FASE 3: FUSIÓN DEL EVOLUTIVO Y EL CORRECTIVO FASE 3: NORMAS PARA EL RESPONSABLE DEL CORRECTIVO FASE 3: NORMAS PARA EL RESPONSABLE DEL EVOLUTIVO FASE 3: NORMAS PARA EL RESPONSABLE DE ICM FASE 4: ESTABILIZACIÓN FASE 4: NORMAS PARA EL RESPONSABLE DEL CORRECTIVO FASE 4: NORMAS PARA EL RESPONSABLE DEL EVOLUTIVO FASE 4: NORMAS PARA EL RESPONSABLE DE ICM RESOLUCIÓN DE CONFLICTOS DURANTE EL MERGE ENLACES DE INTERÉS A1.1 LISTA DE NORMAS Página 3 de 60

4 Contenido 1 INTRODUCCIÓN En la Comunidad de Madrid, el código de las aplicaciones desarrolladas en tecnología Java se almacena y gestiona en un repositorio de código Subversion. Existe un manual de uso básico de Subversion llamado Guia_Uso_Subversion que puede consultarse en la web En dicho manual se muestra el uso básico del repositorio de código Subversion para un proyecto basado en una única línea de desarrollo. Existen ocasiones en las que no es posible mantener una única línea de desarrollo, un típico ejemplo es cuando se desarrolla un evolutivo de una magnitud considerable, y en paralelo se tiene que hacer mantenimiento correctivo de la versión que se encuentra operativa en el entorno de producción. En este documento se muestran las recomendaciones y normas de uso del repositorio de código Subversion en las ocasiones en las que existen dos líneas de desarrollo paralelas, un correctivo y un evolutivo. En el siguiente diagrama se muestra un resumen de alto nivel de las fases por las que pasa el desarrollo en estas condiciones, así como las normas aplicables a cada uno de los tres implicados: El desarrollador del evolutivo, El desarrollador del Correctivo, e ICM. Página 4 de 60

5 Página 5 de 60

6 1.1 AUDIENCIA OBJETIVO Este documento está orientado a toda aquella persona implicada en un desarrollo utilizando el repositorio de código Subversion que mantenga dos líneas de desarrollo en paralelo, un correctivo y un evolutivo. En el apartado 2 se muestran las normas y líneas de trabajo generales para los responsables tanto del evolutivo como del correctivo. En el apartado 3 se muestran las buenas prácticas y guía de uso para el responsable del correctivo, que trabajará en la rama principal del repositorio de Subversion (trunk). En el apartado 4, se muestran las buenas prácticas y guía de uso para el responsable del evolutivo, que trabajará sobre una rama del código (branch). 1.2 CONOCIMIENTOS PREVIOS Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes tecnologías: Subversion Eclipse Plugin Subclipse para integración de Subversion en Eclipse CollabNet Merge Client para Subclipse Página 6 de 60

7 2 NORMAS GENERALES 2.1 HERRAMIENTA Para el desarrollo con el repositorio de código Subversion se utilizará el entorno Eclipse que se proporciona con el DVD del entorno de desarrollo ATLAS (disponible en el portal de arquitecturasw), que incluye el plugin Subclipse. Si no se encuentra instalado, además del plugin subclipse deberá instalarse el plugin opcional denominado CollabNet Merge Client, que nos permitirá realizar los Merge o mezclas de código de manera visual e intuitiva. En el siguiente apartado de indica cómo instalar dicho plugin Instalación de Subclipse con CollabNet Merge Client En Eclipse, accedemos a la opción Help -> Install New Software : En la pantalla que aparece, en el desplegable Work With: seleccionamos el sitio de descargas de software de Subclipse (si no tenemos este sitio disponible, es probable que no se haya utilizado el DVD con el entorno de desarrollo de ATLAS, puede agregarse el sitio de descargas de Subclipse siguiendo el manual Guía de Configuración del Entorno de Desarrollo ). En el sitio de descargas de Subclipse, seleccionamos las siguientes opciones (si algunas ya están marcadas las dejamos, y seleccionamos las que no lo estén). Es muy importante revisar que está marcada la opción CollabNet Merge Client. Página 7 de 60

8 En la siguiente pantalla se nos indica que se van a instalar las opciones seleccionadas, pulsamos sobre Next : Página 8 de 60

9 Aceptamos los términos de la licencia: Si aparece la siguiente pantalla, pulsamos sobre Ok : A continuación es posible que aparezca una pantalla en la que debemos pulsar sobre Ok, y posteriormente se nos recomienda que reiniciemos el entorno, pulsamos sobre Yes : Página 9 de 60

10 Con esto ya tenemos instalado el plugin de Subclipse con la opción CollabNet Merge Client que nos servirá durante el resto del documento. Página 10 de 60

11 2.2 USO DE TRUNK Y BRANCH Llamaremos Trunk a la línea principal de desarrollo, y Branch a la línea paralela. NOTA En los repositorios de código de ICM, el Trunk siempre corresponde con la carpeta llamada v0 que se encuentra en el directorio raíz del repositorio del proyecto: El responsable del desarrollo del correctivo trabajará en el Trunk del repositorio de código Subversion, y el desarrollo paralelo del evolutivo en el Branch será transparente para él. En el momento en el que el evolutivo esté listo para unirse con el correctivo, los cambios del evolutivo se subirán a la línea principal de desarrollo (Trunk), y por tanto el responsable del correctivo ya verá dichos cambios. Las fases por las que pasa el desarrollo de dos líneas paralelas de código son las siguientes: 1) FASE 1: Creación del Branch En el momento en el que comienza el desarrollo del evolutivo, se define un Responsable de Proyecto y un Responsable de Gestión de Aplicaciones por parte de ICM, y un Responsable de Integración por parte de cada uno de los proveedores (evolutivo y correctivo). En ese momento se crea la línea de desarrollo paralela en el repositorio de código Subversion, partiendo de la versión actual del código. A partir de ese momento, el responsable del Trunk trabajará en una línea, y el del Branch en otra. 2) FASE 2: Desarrollo paralelo e integración continua del Trunk en el Branch Durante el desarrollo paralelo, el responsable del correctivo que trabaja en el Trunk no será consciente en ningún momento del evolutivo, hasta que no finalice su desarrollo. Sin embargo, el responsable del evolutivo es también responsable de realizar una integración periódica en el Branch de todos los cambios que se van haciendo en el correctivo. Desde el Área de Aplicaciones Especiales y Arquitectura de Software se recomienda la integración periódica con un periodo de dos semanas (y nunca superior a tres semanas) de ambas líneas de desarrollo en el Branch (el responsable de dicha integración es el responsable del Branch el que desarrolla el evolutivo). 3) FASE 3: Fusión del Branch en el Trunk Una vez finalizado el desarrollo del evolutivo, llega el momento de integrar el Branch y el Trunk, de forma que sólo exista una línea de desarrollo (el Trunk). El responsable del evolutivo será el encargado de esta integración, y a partir de ese momento ambas líneas estarán fusionadas en el Trunk (la carpeta v0 ). La antigua rama del branch estará discontinuada y no podrán subirse modificaciones a ella. 4) FASE 4: Estabilización Página 11 de 60

12 Una vez integrado el evolutivo y pasado a producción comienza la fase de estabilización de la aplicación. Durante esta fase, el responsable del correctivo será el que siga centralizando la recepción de todos los problemas que pudiesen surgir en la aplicación. Si el responsable del correctivo identifica que un problema pudiese deberse a un fallo en la implementación del nuevo evolutivo, se lo comunicará a los Responsables de Proyecto y Gestión de Aplicaciones de ICM para que haga llegar este problema al responsable del evolutivo, que lo corregirá sobre la línea de desarrollo principal (Trunk). Página 12 de 60

13 NORMA NORMA 3 FASE 1: ARRANQUE DEL PROYECTO Y CREACIÓN DEL BRANCH Framework Atlas En el momento en el que comienza el desarrollo del evolutivo, se define un Responsable de Proyecto y un Responsable de Gestión de Aplicaciones por parte de ICM, y un Responsable de Integración por parte de cada uno de los proveedores (evolutivo y el correctivo). En ese momento se crea la línea de desarrollo paralela en el repositorio de código Subversion, partiendo de la versión actual del código. A partir de ese momento, el responsable del Trunk trabajará en una línea, y el del Branch en otra. En los siguientes apartados se definen las normas para cada uno de los tres agentes implicados en la fase de creación del branch. 3.1 FASE 1: NORMAS PARA EL RESPONSABLE DEL CORRECTIVO El desarrollo para el responsable del correctivo es bastante independiente del evolutivo. Al comienzo del desarrollo, antes de crearse el branch para el evolutivo, el responsable del correctivo definirá un responsable de integración. CorrectivoDefineResponsable Antes del arranque del evolutivo, el proveedor responsable del correctivo identificará a una persona de su equipo como el Responsable de Integración. Esta persona será la responsable de cualquier problema durante todo el desarrollo paralelo del correctivo, así como la cabeza visible que centralizará la comunicación con el personal de ICM. 3.2 FASE 1: NORMAS PARA EL RESPONSABLE DEL EVOLUTIVO El responsable del evolutivo es también responsable de la creación del Branch, la integración periódica en el Branch de todos los cambios que se van haciendo en el correctivo, así como la fusión del Branch y el Trunk una vez finalizado su desarrollo. EvolutivoDefineResponsable Antes del arranque del evolutivo, el proveedor responsable del evolutivo identificará a una persona de su equipo como el Responsable de Integración. Esta persona será la responsable de la integración del evolutivo con la línea paralela del correctivo, así como la cabeza visible que centralizará la comunicación con el personal de ICM. Página 13 de 60

14 NORMA Framework Atlas EvolutivoCreaBranch Al inicio del desarrollo del evolutivo, el Responsable de Integración de dicho evolutivo será el encargado de crear el Branch en el repositorio de Subversion. La rama se creará al mismo nivel que el Trunk (v0), y con un nombre que corresponda al nuevo número de versión del evolutivo. Por ejemplo, como la rama de desarrollo del correctivo era v0, se creará un Branch llamado v1 al mismo nivel que ésta (o v2, v3, ) Para ello el responsable del evolutivo deberá realizar los siguientes pasos: Paso 1. Descarga del Trunk: Desde el entorno de desarrollo Eclipse, nos situamos en la perspectiva SVN Repository Exploring y pulsamos sobre New->Repository Location : Introducimos la URL del repositorio en cuestión (se sustituirá pruebas por el código del proyecto concreto con el que estemos trabajando): A continuación ya veremos el nuevo repositorio añadido en la pestaña SVN Repositories. Pulsaremos con el botón derecho sobre la versión del correctivo ( v0 ) y seleccionaremos la opción Checkout : Página 14 de 60

15 A continuación indicamos el nombre que queremos dar al proyecto, que deberá ser xxxx_correctivo, donde xxxx es el identificador del proyecto: Pulsamos sobre Finish, y con esto ya tendremos descargado el proyecto con el correctivo en nuestro entorno de desarrollo. Paso 2. Creación del branch: Una vez descargado el correctivo, tenemos que crear el Branch sobre éste, para comenzar con nuestra nueva línea de desarrollo evolutiva. Para ello, pulsamos con el botón derecho sobre el proyecto que contiene el correctivo, y seleccionamos la opción Team -> Branch / Tag : Página 15 de 60

16 En la ventana que aparece, seleccionamos la ruta donde queremos crear el branch. La rama se creará al mismo nivel que el desarrollo del correctivo, y con un nombre que corresponda al nuevo número de versión del evolutivo. Por ejemplo, como la rama de desarrollo del correctivo era v0, se creará un Branch llamado v1 al mismo nivel que ésta: Página 16 de 60

17 Pulsamos sobre Next, y en la siguiente pantalla volvemos a pulsar sobre Next : A continuación introducimos un comentario y pulsamos sobre Finish : Página 17 de 60

18 En este momento es posible que aparezca la siguiente ventana, en la que pulsaremos sobre Ok (si no aparece, no haremos nada): A continuación, para guardar los cambios sobre el proyecto del correctivo, pulsamos con el botón derecho sobre el correctivo y seleccionamos Team -> Commit : Página 18 de 60

19 Introducimos un comentario y pulsamos sobre Ok : Página 19 de 60

20 Paso 3. Descarga del branch: Ya hemos descargado el correctivo y creado el branch para el evolutivo. Llega el momento de descargarnos dicho branch a nuestro entorno de desarrollo, para tener ambos proyectos abiertos (correctivo y evolutivo) y poder trabajar con ellos. Para ello accedemos a la perspectiva de Eclipse SVN Repositories, y navegamos por el repositorio hasta localizar la nueva rama que acabamos de crear. Pulsamos con el botón derecho sobre ella y seleccionamos la opción Checkout : Indicamos el nombre que queremos dar al proyecto, por ejemplo xxxx_evolutivo, y pulsamos sobre Finish : Página 20 de 60

21 Con esto ya tenemos descargados ambos proyectos correctivo y evolutivo a nuestro entorno de desarrollo local, y podemos visualizar ambos en la vista Proyect Explorer : Paso 4. Asignación del branch al trunk: Para poder hacer los Merges con facilidad, es necesario indicar al plugin de Subclipse que ambos proyectos están enlazados (uno es un branch del otro). Pulsamos con el botón derecho sobre el proyecto xxxx_correctivo y seleccionamos la opción Team -> Configure Branches / Tags : Página 21 de 60

22 En la siguiente pantalla desplegamos el repositorio, seleccionamos la versión del correctivo y pulsamos sobre la opción Add Branch. Hacemos lo mismo con el evolutivo: Finalmente si desplegamos la opción Branches tienen que estar las dos ramas, evolutivo y correctivo, según se muestra en la siguiente pantalla: Página 22 de 60

23 Volvemos a hacer Commit sobre el correctivo para subir las modificaciones sobre la configuración de los Branches, seleccionando Team -> Commit : Página 23 de 60

24 Como siempre, introducimos un comentario al commit: Página 24 de 60

25 NORMA Framework Atlas 3.3 FASE 1: NORMAS PARA EL RESPONSABLE DE ICM Al arrancar el proyecto, desde ICM se definirá un responsable de proyecto que será la persona por parte de ICM que coordine el correcto desarrollo de las dos líneas de trabajo paralelas. ICMDefineResponsables Durante el arranque del proyecto, desde ICM se identificará a una persona como el Responsable de Proyecto y otra persona Responsable de Gestión de Aplicaciones. El Responsable de Proyecto será el encargado de la coordinación entre los proveedores del evolutivo y el correctivo, así como el responsable de la comunicación con el resto de áreas de ICM y con el Responsable de Gestión de Aplicaciones. Página 25 de 60

26 NORMA NORMA 4 FASE 2: DESARROLLO DEL PROYECTO E INTEGRACIÓN CONTÍNUA Framework Atlas 4.1 FASE 2: NORMAS PARA EL RESPONSABLE DEL CORRECTIVO El desarrollo para el responsable del correctivo es bastante independiente del evolutivo. Lo único a tener en cuenta es que el responsable del evolutivo deberá integrar el correctivo periódicamente, por tanto para que pueda realizar su tarea sin problemas es necesario cumplir las siguientes normas: CorrectivoCommitAtomico Cualquier subida de código a Subversion deberá ser auto-contenida, y no deberá de depender de otras subidas posteriores para su correcta compilación o funcionamiento. Ninguna subida afectará al correcto funcionamiento de la aplicación, todo commit dejará la aplicación en un modo estable de funcionamiento (no se subirán correcciones a medias ). CorrectivoModifBBDD Durante el desarrollo del correctivo se deben minimizar las modificaciones al modelo de datos. Sin embargo, hay ocasiones en las que es necesario modificarlo. En las ocasiones en las que la resolución de una incidencia durante el correctivo implique modificaciones al modelo de datos, el desarrollador del correctivo informará al Responsable de Proyecto de ICM y al Responsable de Gestión de Aplicaciones de ICM, para que lo pongan en conocimiento del proveedor responsable del evolutivo (y así se tenga en cuenta durante la siguiente integración periódica). Página 26 de 60

27 NORMA NORMA NORMA Framework Atlas CorrectivoCommitComentario Deberá incluirse un comentario explicativo en cualquier subida de código a Subversion (commit). El comentario incluirá obligatoriamente: Número de incidencia o encargo del correctivo al que corresponde Indicador de si el correctivo supone modificación de modelo de datos o no, con el siguiente formato: SI MODIFICA BBDD / NO MODIFICA BBDD (mayúsculas) Breve descripción de lo que se está corrigiendo, en minúsculas Si el correctivo implica modificación de modelo de datos, script SQL con la modificación Ejemplos de comentarios: - Encargo : NO MODIFICA BBDD. Corrige el problema de la pérdida de sesiones - Encargo : SI MODIFICA BBDD. Incluye nueva forma de gestionar usuarios. Script de modificación de BBDD: ALTER TABLE XXXX_USUARIO ADD COLUMN DS_DETALLE VARCHAR2(100); 4.2 FASE 2: NORMAS PARA EL RESPONSABLE DEL EVOLUTIVO Durante el desarrollo del evolutivo, es imprescindible que periódicamente se integre con el correctivo. No se debe esperar a finalizar el evolutivo para realizar la integración, ya que la complejidad sería alta y podrían aparecer discrepancias que hubiesen sido fáciles de resolver cuando se produjeron, pero son irresolubles una vez finalizado. EvolutivoIntegracionPeriodica El Responsable de Integración del evolutivo debe realizar integraciones periódicas del correctivo en su línea de desarrollo. No puede esperarse a finalizar el evolutivo para realizar la integración. Se recomienda realizar integraciones con un periodo de dos semanas. Salvo autorización expresa por parte de ICM, el periodo máximo de desarrollo de un evolutivo sin integración con el correctivo es de tres semanas. EvolutivoComunicaIntegracion Cada vez que el Responsable de Integración del evolutivo realice una integración periódica del correctivo, deberá comunicar al Responsable de Proyecto de ICM a través de correo electrónico la siguiente información: Fecha en la que se ha realizado la integración Número de Revisión de Subversion del correctivo hasta la que se ha integrado Posibles conflictos que hayan surgido durante la integración, y su resolución Página 27 de 60

28 4.2.1 Publicación en los entornos de ICM no productivos Es posible que durante el desarrollo del evolutivo, se requiera de la instalación de una versión de dicho evolutivo en los entornos de ICM (antes del paso a producción). En ese caso, es fundamental comunicar dicha necesidad al Responsable de Proyecto de ICM, que deberá de gestionar los entornos para que no haya conflictos entre el correctivo y el evolutivo Actualización Periódica (Sync Merge) En este apartado se muestra cómo hacer una integración en el evolutivo de las modificaciones realizadas en el correctivo. Paso 5. Actualizar el branch y hacer commit de todos los cambios locales en el branch: Debemos de asegurarnos de que el código del branch es el último y no hay nada sin subir. Para ello, primero realizamos un Update del branch, para traernos todos los cambios que hayan podido realizar otros desarrolladores. Pulsamos con el botón derecho sobre el proyecto del branch y seleccionamos Team -> Update to Head : Ahora debemos subir los cambios que tengamos en local al branch. Para ello pulsamos con el botón derecho sobre el proyecto del branch y seleccionamos Team -> Commit : Página 28 de 60

29 Introducimos un comentario asociado al commit: Paso 6. Actualizar el trunk: Antes de poder integrar, también debemos asegurarnos de que tenemos en local el último código del trunk (el correctivo). Para ello pulsamos con el botón derecho sobre el proyecto del trunk y seleccionamos Team -> Update to Head : Página 29 de 60

30 Paso 7. Ver los cambios que ha habido en el trunk: Antes de realizar la integración, debemos revisar los cambios que ha habido en el correctivo desde la última vez que integramos. Para ello, pulsamos con el botón derecho sobre el correctivo y seleccionamos Team -> Show History : Página 30 de 60

31 En la pestaña History de la zona inferior de la pantalla podemos ver el histórico de commits del correctivo: Página 31 de 60

32 AVISO IMPORTANTE Debemos apuntar el número de la última revisión (último commit) que se ha realizado en el correctivo. En el ejemplo de la imagen superior, 54. AVISO IMPORTANTE Debemos revisar los comentarios de los commits en el correctivo, para verificar si alguno de ellos contiene modificaciones en el modelo de datos. En ese caso, debemos incluir dichas modificaciones también en el modelo del evolutivo (en el fichero ERWIN o donde corresponda) Si deseamos ver los ficheros modificados entre una versión y otra, seleccionamos ambas versiones con la tecla Control pulsada, y pulsando con el botón derecho sobre una de ellas seleccionamos Compare : En el siguiente cuadro pulsamos sobre Ok : Página 32 de 60

33 En la pantalla que aparece, podemos navegar y ver las diferencias entre los ficheros de las versiones que estamos comparando: Paso 8. Integrar los cambios del trunk en el branch: Una vez que hemos revisado y validado las modificaciones del correctivo, llega el momento de integrar dichas modificaciones en la rama del evolutivo (realizar un Merge Synch ). Para ello, pulsamos con el botón derecho sobre el evolutivo y seleccionamos Team -> Merge : Página 33 de 60

34 En la siguiente pantalla dejamos seleccionada la primera opción, Merge a range of revisions. Nos aseguramos de que esté marcada la casilla Perform pre-merge best practices checks : Página 34 de 60

35 Es posible que salga alguna advertencia como la siguiente, en ese caso pulsamos sobre el enlace Update : Página 35 de 60

36 Pulsamos sobre Ok, de forma que ahora ya no saldrán advertencias: Ahora pulsamos sobre Next y nos pregunta de qué rama queremos obtener los cambios. Normalmente ya aparecerá la rama del correctivo, no será necesario modificarlo: Página 36 de 60

37 Pulsamos sobre Finish, y vemos la pantalla con el resultado de la integración: Página 37 de 60

38 AVISO IMPORTANTE Si en el resumen de la integración aparecen CONFLICTOS durante la integración, debemos resolver los conflictos antes de proseguir con los siguientes pasos. Para más información sobre la resolución de conflictos, consultar el apartado Resolución de Conflictos durante el Merge de este documento. Podemos visualizar más detalles sobre la realización del Merge en la pestaña Merge Results de la zona inferior: Cuando se ha realizado la integración, podemos ver que se han realizado las modificaciones oportunas en nuestro código local del Branch para integrar los cambios: Página 38 de 60

39 Paso 9. Subir los cambios del branch a Subversion: Una vez solucionados los conflictos (si existían), compilado el código y probada la aplicación, podemos proceder a subir los cambios del branch al repositorio. Pulsamos con el botón derecho sobre el evolutivo, y seleccionamos Team -> Commit : Introducimos un comentario explicativo del cambio (indicando el número de revisión que apuntamos previamente), y pulsamos sobre Ok : Página 39 de 60

40 Con esto ya hemos finalizado con la integración Vista gráfica de las revisiones integradas El plugin Subclipse incluye una forma de visualizar de manera gráfica el historial de revisiones, ramas y merges intermedios que se han realizado. Si queremos visualizarlo, pulsamos con el botón derecho sobre el proyecto del evolutivo y seleccionamos Team -> Show Revision Graph : Página 40 de 60

41 NOTA: En ocasiones es posible que salga un error del siguiente tipo: Framework Atlas Si es así, vamos a la perspectiva SVN Repositories, pulsamos con el botón derecho sobre el repositorio y seleccionamos la opción Clear Revision Graph Cache : Si nos pide confirmación, aceptamos: Volvemos a intentar mostrar el gráfico, y ya no deberían surgir problemas: Página 41 de 60

42 En el gráfico que aparece por defecto, no se muestran por defecto las líneas rojas que indican si se han integrado modificaciones del correctivo en el evolutivo. Si deseamos mostrar esa información, pulsamos con el botón derecho sobre el globo verde que queremos actualizar, y seleccionamos Refresh revisión / Merge Info : Página 42 de 60

43 Aparecerán entonces las líneas rojas que indican lo que ya se ha integrado en el branch: 4.3 FASE 2: NORMAS PARA EL RESPONSABLE DE ICM Durante el desarrollo del proyecto con las dos líneas paralelas, el Responsable de Proyecto de ICM es el nexo de comunicación entre ambos proveedores, así como el encargado de comprobar el correcto cumplimiento de la normativa por parte de ambos, y tener el control sobre los entornos de ICM para que no existan conflictos entre las versiones desplegadas en cada entorno. Página 43 de 60

44 NORMA NORMA Framework Atlas ICMControlaCumplimiento Durante el desarrollo del proyecto, el Responsable de Proyecto de ICM es el nexo de comunicación entre ambos proveedores y las áreas de Gestión de Aplicaciones de ICM. El Responsable de Gestión de Aplicaciones de ICM es el encargado de comprobar periódicamente el correcto cumplimiento de la normativa por parte de ambos. El Responsable de Gestión de Aplicaciones de ICM comprobará que el proveedor del evolutivo cumple la normativa de integración periódica de ambas ramas, con especial atención a la que la frecuencia de integración esté dentro del rango establecido. Asimismo, el Responsable de Gestión de Aplicaciones de ICM también comprobará que el proveedor del correctivo cumple la normativa de subida de código a Subversion así como todas aquellas normas que le afecten. ICMGestionaEntornos El Responsable de Gestión de Aplicaciones de ICM, es responsable de gestionar los entornos no productivos de ICM. Durante el desarrollo del evolutivo, cuando sea necesario probar y validar el desarrollo evolutivo realizado, el Responsable de Proyecto de ICM determinará el entorno no productivo apropiado para realizar las pruebas y solicitará al Responsable de Gestión de Aplicaciones de ICM el despliegue de la rama en el entorno no-productivo de ICM para realizar las pruebas del evolutivo. El Responsable de Gestión de Aplicaciones de ICM, dará instrucciones al responsable de Integración del Correctivo para que no utilice ni realice despliegues en el entorno no productivito ocupado para las pruebas del evolutivo. Página 44 de 60

45 NORMA Framework Atlas ICMApruebaEvolutivo El Responsable de Proyecto de ICM, es responsable de aprobar la validación y pruebas de aceptación del evolutivo. Al finalizar la Fase 2 ( Desarrollo del Proyecto e Integración Continua ), el Responsable de Proyecto de ICM: - Requerirá al Responsable de Integración del Proveedor del Evolutivo la documentación asociada a dicho evolutivo, para verificar que se han realizado las pruebas necesarias. - Requerirá que el Equipo Funcional de ICM haya realizado las pruebas de aceptación correspondientes, y haya dado su visto bueno al evolutivo. - Verificados los dos puntos anteriores, autorizará el paso a la fase 3 para la fusión definitiva del evolutivo sobre la rama principal (Trunk), informando al Responsable de Gestión de Aplicaciones de ICM y a ambos responsables del evolutivo y del correctivo, del inicio de la fusión final. Página 45 de 60

46 NORMA 5 FASE 3: FUSIÓN DEL EVOLUTIVO Y EL CORRECTIVO Framework Atlas Es importante destacar que, una vez finalizado el evolutivo, ambas líneas de desarrollo se unen en el trunk (la carpeta v0). Por ejemplo, si el correctivo se desarrollaba sobre la v0 y el evolutivo sobre la v1, al finalizar el evolutivo todos los cambios que se han hecho en v1 se suben a v0 (trunk). 5.1 FASE 3: NORMAS PARA EL RESPONSABLE DEL CORRECTIVO CorrectivoIntegraBranch Al finalizar el desarrollo del evolutivo y pasarlo a producción, el responsable del dicho evolutivo es el encargado de fusionar el Trunk y el Branch en el repositorio de Subversion. La fusión se hará sobre el Trunk. A partir de ese momento el branch del evolutivo estará discontinuado, la única rama de trabajo será el Trunk (la carpeta v0). Por ejemplo, si el correctivo se desarrollaba sobre la v0 y el evolutivo sobre la v1, al finalizar el evolutivo todos los cambios que se han hecho en v1 se suben a v0 (trunk). Por tanto el responsable del correctivo, al actualizar su rama del repositorio de Subversion (svn update sobre la carpeta v0 ) verá que los cambios del evolutivo ya están integrados en dicha rama de desarrollo, y seguirá trabajando sobre ella. 5.2 FASE 3: NORMAS PARA EL RESPONSABLE DEL EVOLUTIVO Una vez finalizado el desarrollo del evolutivo, llega el momento de integrar el Branch y el Trunk, de forma que sólo exista una línea de desarrollo (el Trunk). El responsable del evolutivo será el encargado de esta integración, y a partir de ese momento ambas líneas estarán fusionadas en el Trunk (la carpeta v0 ). La antigua rama del branch estará discontinuada y no podrán subirse modificaciones a ella. Por ejemplo, si el correctivo se desarrollaba sobre la v0 y el evolutivo sobre la v1, al finalizar el evolutivo todos los cambios que se han hecho en v1 se suben a v0 (trunk). Página 46 de 60

47 NORMA Framework Atlas EvolutivoIntegraBranch Al finalizar el desarrollo del evolutivo y pasarlo a producción, el responsable del dicho evolutivo será el encargado de fusionar el Trunk y el Branch en el repositorio de Subversion. La fusión se hará sobre el Trunk. El Responsable de Integración del evolutivo, antes de realizar dicha integración final, lo comunicará al Responsable de Proyecto de ICM para coordinarse y evitar que el responsable del correctivo realice modificaciones mientras se está realizando esta integración. A partir de ese momento el branch del evolutivo estará discontinuado, la única rama de trabajo será el Trunk (la carpeta v0). Por ejemplo, si el correctivo se desarrollaba sobre la v0 y el evolutivo sobre la v1, al finalizar el evolutivo todos los cambios que se han hecho en v1 se suben a v0 (trunk). Para realizar la integración final de los cambios del evolutivo en el Trunk (en la carpeta v0 ), deberán realizarse los siguientes pasos: Paso 10. Realizar un Synch Merge normal: Antes de integrar los cambios en la carpeta v0, debemos realizar un Synch Merge normal en la rama del evolutivo (según se explica en el apartado Actualización Periódica), para asegurarnos que tenemos todos los cambios del correctivo integrados, Paso 11. Subir los cambios del evolutivo al correctivo: Ahora que ya tenemos unificados los cambios del correctivo y el evolutivo en el branch, es el momento de pasar todos estos cambios al trunk. Para ello, pulsamos con el botón derecho sobre el correctivo (v0) y seleccionamos Team -> Merge : Página 47 de 60

48 En la siguiente pantalla dejamos seleccionada la segunda opción, Reintegrate a Branch. Nos aseguramos de que esté marcada la casilla Perform pre-merge best practices checks : Página 48 de 60

49 Es posible que salga alguna advertencia como la siguiente, en ese caso pulsamos sobre el enlace Update : Página 49 de 60

50 Pulsamos sobre Ok, de forma que ahora ya no saldrán advertencias: Ahora pulsamos sobre Next y nos pregunta de qué rama queremos obtener los cambios. Normalmente aparecerá la rama del correctivo, es necesario modificarlo pulsando sobre la opción Select : Página 50 de 60

51 Seleccionamos la rama del evolutivo: Página 51 de 60

52 Pulsamos sobre Finish, y vemos la pantalla con el resultado de la integración: Página 52 de 60

53 AVISO IMPORTANTE Si en el resumen de la integración aparecen CONFLICTOS durante la integración, debemos resolver los conflictos antes de proseguir con los siguientes pasos. Para más información sobre la resolución de conflictos, consultar el apartado Resolución de Conflictos durante el Merge de este documento. Paso 12. Subir los cambios al Trunk: Una vez solucionados los conflictos (si existían), compilado el código y probada la aplicación, podemos proceder a subir los cambios del branch al repositorio. Pulsamos con el botón derecho sobre el correctivo, y seleccionamos Team -> Commit : Introducimos un comentario explicando que estamos realizando la re-integración del branch en el trunk, y pulsamos sobre Ok : Página 53 de 60

54 NORMA Framework Atlas Con esto ya hemos finalizado con la integración. 5.3 FASE 3: NORMAS PARA EL RESPONSABLE DE ICM Durante la integración de ambas líneas de desarrollo, el responsable de ICM controlará que dicha integración se realiza satisfactoriamente, cumpliendo las siguientes normas. ICMGestionaFusion Durante la integración de ambas líneas de desarrollo, el Responsable de Proyecto de ICM controlará que dicha integración se realiza satisfactoriamente. Para ello: Coordinará e informará al Área de Gestión de Aplicaciones de ICM involucrada en el aplicativo Informará al responsable del correctivo de cuándo debe congelar su código para que el responsable del evolutivo realice la integración final Gestionará la puesta en producción de la rama del evolutivo y correctivo fusionadas, realizando la solicitud por GPAP Informará al responsable del correctivo de cuándo se han fusionado correctamente ambas ramas, para que el proveedor del correctivo actualice subversión y así vea los cambios en el trunk. Página 54 de 60

55 NORMA NORMA NORMA Framework Atlas 6 FASE 4: Estabilización 6.1 FASE 4: NORMAS PARA EL RESPONSABLE DEL CORRECTIVO Una vez integrado el evolutivo y pasado a producción comienza la fase de estabilización de la aplicación. Durante esta fase, el responsable del correctivo será el que siga centralizando la recepción de todos los problemas que pudiesen surgir en la aplicación. Si el responsable del correctivo identifica que un problema pudiese deberse a un fallo en la implementación del nuevo evolutivo, se lo comunicará a los Responsables de Proyecto y Gestión de Aplicaciones de ICM para que haga llegar este problema al responsable del evolutivo, que lo corregirá sobre la línea de desarrollo principal (Trunk). CorrectivoMantieneFusion Durante la fase de estabilización de la aplicación, el responsable del correctivo será el que siga centralizando la recepción de todos los problemas que pudiesen surgir en la aplicación. Si el responsable del correctivo identifica que un problema pudiese deberse a un fallo en la implementación del nuevo evolutivo, se lo comunicará al Responsable de Proyecto de ICM para que haga llegar este problema al responsable del evolutivo, que lo corregirá sobre la línea actual de desarrollo de Subversion (el Trunk, la carpeta v0 ). 6.2 FASE 4: NORMAS PARA EL RESPONSABLE DEL EVOLUTIVO EvolutivoEstabilizaAplicacion Durante la fase de estabilización de la aplicación, el responsable del evolutivo será contactado por el Responsable de Proyecto de ICM cuando se identifique que un problema en la aplicación es derivado del desarrollo del evolutivo que se encuentra en fase de estabilización. El responsable del evolutivo, según la relación contractual, arreglará dichos problemas derivados del desarrollo del evolutivo. EvolutivoEstabilizaCommit La resolución de los posibles problemas derivados del evolutivo durante la fase de estabilización se realizará sobre la línea de desarrollo unificada del correctivo y el evolutivo (el Trunk carpeta v0-, la única existente en ese momento). El commit que realiza la corrección deberá ser único, atómico y auto-contenido para evitar problemas al proveedor del correctivo. 6.3 FASE 4: NORMAS PARA EL RESPONSABLE DE ICM Página 55 de 60

56 NORMA Framework Atlas ICMGestionaEstabilizacion Durante la fase de estabilización de la aplicación, el Responsable de Proyecto de ICM será el nexo de unión entre el responsable del correctivo y el del evolutivo. Cuando el responsable del correctivo identifique un problema derivado del desarrollo del evolutivo, será el Responsable de Proyecto de ICM el encargado de gestionar su resolución por parte del responsable del evolutivo. Página 56 de 60

57 7 RESOLUCIÓN DE CONFLICTOS DURANTE EL MERGE Framework Atlas En ocasiones, durante la integración del correctivo en el evolutivo, es posible que se produzcan conflictos en el merge, debido a que en ambas líneas de desarrollo se han modificado los mismos ficheros. La resolución automática de conflictos de Subversion funciona bastante bien, por lo que si no se han modificado exactamente las mismas líneas de código, el merge suele realizarse automáticamente. Sin embargo, si se han modificado las mismas líneas de código (o se ha eliminado un fichero en una rama y en la otra se ha modificado), el responsable de la integración deberá resolver manualmente el conflicto. Durante la realización del merge, si se encuentra con algún conflicto nos preguntará qué hacer: Podemos indicarle que lo resolveremos posteriormente. Al finalizar el merge, podemos visualizar más detalles sobre su realización en la pestaña Merge Results de la zona inferior, y seleccionando el fichero con conflictos resolverlos en ese momento: Página 57 de 60

58 *Nota: Los ficheros con conflicto aparecen marcados con una doble flecha roja en el icono del fichero. Para más información sobre resolución de conflictos durante el merge puede consultarse la página de la documentación oficinal de CollabNet Merge Client denominada Overview of CollabNet Merge Client, en el apartado Resolving Conflicts : Página 58 de 60

59 8 ENLACES DE INTERÉS URL Descripción Documentación official de Subclipse Keeping a Branch in Sync SVN Merging using SubClipse Merging with Subclipse (and Subversion) #svn.branchemerge.basicmerging.stayinsync MEuUjb&freeformpage=Merge%20Client Estrategia de branch y de merge con subversion Overview of CollabNet Merge Client Página 59 de 60

60 A1.1 LISTA DE NORMAS CORRECTIVODEFINERESPONSABLE EVOLUTIVODEFINERESPONSABLE EVOLUTIVOCREABRANCH ICMDEFINERESPONSABLES CORRECTIVOCOMMITATOMICO CORRECTIVOMODIFBBDD CORRECTIVOCOMMITCOMENTARIO EVOLUTIVOINTEGRACIONPERIODICA EVOLUTIVOCOMUNICAINTEGRACION ICMCONTROLACUMPLIMIENTO ICMGESTIONAENTORNOS CORRECTIVOINTEGRABRANCH EVOLUTIVOINTEGRABRANCH ICMGESTIONAFUSION CORRECTIVOMANTIENEFUSION EVOLUTIVOESTABILIZAAPLICACION EVOLUTIVOESTABILIZACOMMIT ICMGESTIONAESTABILIZACION Página 60 de 60