El objetivo de este proceso es gestionar las releases del proyecto, definiendo como se crea, consulta y recupera cada release del proyecto.

Los siguientes son los roles participantes en este proceso:

Cuándo se ejecuta esta tarea

La creacion y liberación de una release, se podrá producir, en los siguientes momentos del ciclo de vida del código del proyecto :

• cuando se haya finalizado el desarrollo de un conjunto de funcionalidades de la aplicación (puede englobar varios sprints) y vayamos a pasarlo al entorno de preproduccion (pruebas de usuario)
• cuando se hagan cambios a la versión mostrada al usuario, por los errores detectados por éste o por pequeños cambios solicitados por él.
• cuando se hayan finalizado las pruebas de usuario y se quiera sacar una versión a producción.
• cuando haya cambios en la versión subida a produccion (bug detectado).

Así que este proceso se ejecutará dos veces uno para preproducción y otro para producción, como MINIMO. A esto lo denominaremos versiones. Aparte, durante el desarrollo, puede surgir la necesidad de crear ramas distintas, para congelar una versión del proyecto, que contenga cierta funcionalidad, por ejemplo para probar nuevas interconexiones, que no se saben si finalmente se realizarán, y no se quiere entrar en conflicto con la rama de desarrollo actual. A esto lo denominaremos ramas.

La única diferencia entre ramas y versiones es conceptual, para el servidor de versiones Subversion son exactamente la misma cosa.

¿Que significa crear una release?

Crear una rama del repositorio del proyecto, etiquetada. Con lo cual pasaremos a tener dos versiones del proyecto, el tronco que colgará de la carpeta /Proyecto/Fuentes y las versiones, que colgarán de /Versiones, o de /ramas en el caso en que queramos crear una rama. En el tronco del proyecto seguiremos desarrollando el proyecto y en la versión tendremos el código que “ve” el usuario.

Nombrado de las versiones

Para crear las etiquetas de cada versión usaremos 3 números separados por puntos (x.y.z), de menos significativo a más significativo significan:

• Z: Build (empezará en cero, e irá aumentando de uno en uno por cada parche que se publique para solucionar cambios no planificados, como son los bugs o cambios funcionales mínimos).
• Y: Release (empezará en cero, e irá aumentando en uno por cada cambio planificado, acumulación de nuevas funcionalidades, etc.)
• X: Versión (empezará en uno, y sólo cambiará cuando haya cambios radicales en la aplicación, como cambios de arquitectura o diseño o cambios funcionales importantes).

Para la versiones a PREPRODUCCION, pondremos o bien la versión X.Y.Z.beta para la primera subida o la versión acabada en X.Y.Z.CRx, siendo la x el número de Release candidata.

Para la versiones a PRODUCCION, no habrá terminación.

Qué versionar

La rama /Proyecto (que incluye el SW y también la documentación).

Una vez aclarados los conceptos, explicamos la tarea paso a paso.

Normalmente YA estará creada la versión en el JIRA, ya que las historias y sus posteriores jiras de desarrollo han tenido que ser creados en la fase de requisitos. Ahora bien si es una versión de PREPRODUCCION no estará creado. O bien puede ser una versión de corrección que no se haya tenido en cuenta. Dependiendo del caso que sea, optaremos entre dos alternativas, para decidir si la versión tiene padre o no:

• Si es una version “1.0.X” de PRODUCCION colgará del raiz.
• Si es una versión de PREPRODUCCION se asociará como hija a la versión de PRODUCCION “1.X.0” que se está desarrollando

Por ejemplo si estamos creando la 1.0.0.beta:

nos iriamos a JIRA y lo meteriamos nueva.

Una vez creada se podrá poner esta versión en el campo “Versión Fijada”, en la resolución de JIRA.

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

En Label se especificará PRE si es para el entorno de PREPRODUCCION y PRO si es para el entorno de PRODUCCION.

Lo primero que haremos antes de liberar cualquier release, es ver si la version que se va a etiquetar, funciona correctamente en desarrollo y tiene todas las funcionalidades que se quieren pasar.

Es probable que esté suficientemente probada en los servidores locales de los desarrolladores, pero la configuración en los servidores de desarrollo es diferente y similar a la de explotacion / preproduccion con lo que antes de sacar un tag nos aseguraremos de que está funcionando correctamente en desarrollo.

Las subidas a desarrollo se hacen automáticamente todos los dias por el Jenkins. Si hace falta hacer otra subida seguir el proceso de subida al contenedor de desarrollo descrito en el punto 3 de Instalar Aplicación.

Pasos para hace el Tag:

• 1. Hacer un “Svn..Checkout” de lo que se quiere versionar. Por ejemplo, si el proyecto es PROTOTIPO y queremos hacer un tag del tronco principal (para sacar la primera version a PREPRODUCCION) se haría de “https://svn.um.es/svn/PROTOTIPO/proyecto”. En esa carpeta tendremos el tronco principal.

Si lo que queremos es pasar a una versión candidata CR o hacer un cambio de versión “leve” de lo que está en producción cogeremos la última de las versiones (beta, CR o 1.0.X) de versiones: “https://svn.um.es/svn/PROTOTIPO/versiones/1.0.0.beta/” o “https://svn.um.es/svn/PROTOTIPO/versiones/1.0.0.CR/”

• 2. Hacer un “Branch/tag…” de la carpeta “proyecto” o “1.0.0.beta”, recién descargada.

La dirección a la que se hará , será a partir de la raiz “https://svn.um.es/svn/PROTOTIPO/” en la primera subcarpeta:

• versiones. Si es una subida a PREPRODUCCION o PRODUCCION
• ramas. Si es un cambio para probar una funcionalidad temporalmente.

En la segunda subcarpeta se pondrá la versión directamente, como se ha explicado anteriormente, quedando por ejemplo:

En el comentario especificaremos la version subida y el codigo de JIRA al que esta asociada esta tarea (ver el punto 1).

En caso de hacerlo con subversion en linea de comandos lo que se haría es ejecutar el comando: “svn copy urlREPOsvn/proyecto /versiones/1.1.0.beta”

Para hacer los despliegues de la aplicación seguir el proceso. Preparar entorno de ejecución , que a su vez abrirá una nueva tarea.

Habrá que informar a los desarrolladores de que la última versión de PREPRODUCCION o PRODUCCION ha cambiado, para que actulizen su entorno de trabajo a la rama en la que se ha publicado (en caso de que sea necesario por ser un desarrollador “involucrado”).

Se mandará un email al grupo de trabajo.

El desarrollador, simplemente en el Eclipse, o bien

• se hará una descarga de un proyecto SVN con la nueva URL de PREPRODUCCION o PRODUCCION. Como se indica en la GT Incorporarse a un proyecto existente en un repositorio SVN

• en caso de que YA tenga una versión de PREPRODUCCION O PRODUCCION, hará un switch a la nueva rama.

En ocasiones será necesario volver atrás de la versión publicada, en PREPRODUCCION o PRODUCCION. Una situación en la que podemos recuperar una release es en el caso en que descubramos que la versión en producción tiene un fallo importante que no podemos resolver inmediatamente y deseemos volver a la versión anterior. O también puede ser interesante probar una funcionalidad con una release anterior a la que se esté trabajando en el entorno local del desarrollador, para comprobar por ejemplo si realmente funcionaba.

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

En Label se especificará PRE si es para el entorno de PREPRODUCCION y PRO si es para el entorno de PRODUCCION.

Para hacer las pruebas en el entorno local de un desarrollador, antes de pasarla o porque sea el objetivo final esa prueba, seguir la GT Incorporarse a un proyecto existente en un repositorio SVN.

Dentro de la rama principal tendremos las subcarpetas ramas y versiones con las distintas versiones de los proyectos, de la que escogeremos la release a recuperar.

Una vez probado podremos subir a PREPRODUCCION / PRODUCCION la versión que deseemos, de la misma forma que hemos subido una versión a producción Instalar Aplicación

En caso de que se quiera hacer con linea de comandos se puede hacer por ejemplo con un “svn export -r REV URL”

Distinguiremos dos casos: que se quiera consultar release para ver los cambios realizados (incidencias/historias resueltas) o para ver los ficheros que se han modificado / añadido sin mostrar información de por qué se realizaron.

Para ver el número de incidencias resueltas en una versión usaremos el JIRA. Ahora bien el JIRA, depende de que se haya utilizado correctamente MEDEA (todas las subidas a subversion tienen un JIRA asociado que se ha dado por resuelto. Si queremos ver la información “real” de los cambios subidos usaremos Tortoise SVN. Será para casos excepcionales en los que haya habido cambios no trazados correctamente en el JIRA

• Uso de JIRA.

Para ver los cambios en JIRA, seguir los siguientes pasos

1. Seleccionamos el proyecto:

Seleccionamos la version.

Seleccionamos notas de publicacion.

Nos aparecerán todas las incidencias bugs y mejoras asociadas a esa versión.

• Uso de Tortorise SVN.

Para ver los cambios asociados a una versión, por ejemplo la 1.0.0. beta, usaremos la opción de “Show Log…”.

Ahi nos aparecerá el número de revisión en la que se hizo el tag 1.0.0.beta. Es la primera línea que aparece en azul.

En el ejemplo la 3729.

Usaremos ese número para hacer comparaciones con otra revision que nos interese (para ver los cambios realizados desde la revision origen a la revision destino) mediante la opción “Show Range..”.

Por ejemplo si queremos ver los cambios desde el inicio del proyecto (revisión 1) hasta la version 1.0.0.beta hariamos:

OjO La opcion “Stop on copy/rename”. Debe de estar DESMARCADA .

Si queremos los ficheros que están contenidos en una release, bastaría con descargarse la versión deseada y contabilizar los ficheros con cualquier herramienta del sistema operativo. Tambien se podria hacer con el Tortoise SVN.. haciendo boton derecho “Show log…”, dando a “Next 100” hasta llegar a la revision inial, boton derecho de la primera linea de la version y hacer “Compare with previus revision” y seleccionar en el rango para que sea entre la primera y la ultima revision.

Ahora bien si lo que se quiere es comparar dos versiones (ficheros modificados desde una versión a otra), lo haremos con el Tortoise SVN de la siguiente manera:

Supongamos que queremos compara las versiones 1.0.0.beta con la 1.0.0.CR

Aparecerán una lista de ficheros modificados:

En multiples ocasiones puede suceder que tengamos dos ramas con cambios en cada una de ellas y queramos unificarlas en una.

Por ejemplo, una vez tengamos una rama en PREPRODUCCION, puede suceder que se hagan cambios en la rama que se va a volver a enseñar al cliente, por los fallos detectados, mientras otra parte del equipo de desarrollo sigue trabajando en la siguiente entrega de la aplicación.

Una vez aprobados los cambios por el cliente, sean bug o nuevas funcionalidades, querremos incorporar estos cambios al tronco principal del proyecto para que sean recogidos en posteriores versiones. Para ello haremos un merge de las dos ramas, el tronco principal y la rama de producción. Lo vemos con un ejemplo:

Cada participante en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

Si no se tiene en el espacio de trabajo, hacer un “Svn…CheckOut” de la rama “destino”, a la que se le van a “añadir”,los cambios hechos en la otra rama. Por ejemplo de “https://svn.um.es/svn/PROTOTIPO/proyecto/” (caso puesto de ejemplo de pasar al trunk los cambios hechos en otras versiones).

Si ya se tiene hacer un “Svn…Update”, para obtener la última versión subida.

No situamos en la carpeta “destino”, con el botón derecho realizamos la acción “Merge…”.

De las dos opciones cogeremos la que nos interese según sean tronco /rama o dos ramas distintas las que se estén mezclando.

En esta ventana indicaremos la rama “origen” de la que queremos coger los cambios:

En caso de conflicto aparecerán la siguiente ventana

en la que se podrá seleccionar marcar como hecha la mezcla, quedarse con la copia de trabajo o con la remota. Los conflictos se pueden resolver en este momento o en el siguiente paso de esta tarea.

Una vez finalizado el merge, en nuestro espacio de trabajo se habrán descargado los cambios hechos en la otro rama. Esto no quiere decir que se hayan subdido la mezcla todavía, quiere decir que la mezcla esta actualmente en NUESTRO espacio de trabajo. Para que esté subida, habrá que hacer un commit de los cambios detectados.

Por último tendremos que hacer commit de los cambios que se han “mezclado”, para que estén disponibles para el resto de desarrolladores.

En caso de haberse detectado conflictos se pueden solucionar en esta fase. En caso de tenerlos, es importante comprobar que lo que se ha subido una vez resuelto a la rama comun funciona correctamente.

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.Gestionproyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja QS.

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

• project = ClaveDelProyecto
• Disciplina-Proceso = Gestión de la configuración - GC-Gestión Releases

Pulsa el botón Search

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

Numero de subcarpetas en la carpeta versiones que hay.

Numero de subcarpetas en la carpeta ramas que hay.

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

• project = ClaveDelProyecto
• Disciplina-Proceso = CFG-Gestión Releases
• label = MER

Pulsa el botón Search

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

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

• project = ClaveDelProyecto
• Disciplina-Proceso = CFG-Gestión Releases
• label = PRE

Pulsa el botón Search

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

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

• project = ClaveDelProyecto
• Disciplina-Proceso = CFG-Gestión Releases
• label = PRO

Pulsa el botón Search

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