El objetivo de este proceso es el disponer de un entorno de ejecución conforme a los requisitos que cumple la release a liberar. Para crear ese entorno habrá que seguir los siguientes pasos

• Obtener un contenedor de aplicaciones y una base de datos (comprobar que Sistemas ha creado las tablas y en caso necesario el contenedor de aplicacion)
• Cargar la base de datos con las tablas necesarias y a su vez con los datos necesarios.
• Instalar la aplicacion en el contenedor.

Estos tres puntos se corresponden con las tres tareas del diagrama. Una vez hecho esto tendremos como resultado una aplicación en un contenedor ya sea de PREPRODUCCION o PRODUCCION.

Los siguientes son los roles participantes en este proceso:

Las tres tareas están muy interrelacionadas, por lo que para este caso agruparemos las 3 tareas en un solo JIRA.

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

• 1. Comprobar que la base de datos está creada

Por defecto el entorno estará creado, al pedir una nueva aplicación. En este paso comprobaremos que ha sido creado correctamente y ejecutaremos los scripts de creación de base de datos.

Si la subida es a DESARROLLO, comprobaremos que existe en la base de datos “ISIS” el schema de nuestra aplicación.

Si la subida es a PREPRODUCCION, comprobaremos que existe en la base de datos “VENUSCK” el schema de nuestra aplicación.

Si la subida es a PRODUCCION, comprobaremos que existe en la base de datos “VENUS” el schema de nuestra aplicación.

Para las pruebas de migración a Linux la BD es VENUSLX.

• 2. Comprobar que el contenedor de aplicaciones está creado

Para probar que el contenedor esta creado, tenemos la url que nos proporciona sistemas. Si es en desarrollo/preproducción:

Si la aplicación se llama nombreaplicacion

Para pruebas (DESARROLLO)

http://nombreaplicacionpruebas.um.es/nombreaplicacion/servlet/SnoopServlet

http://nombreaplicacionpruebas.um.es/nombreaplicacion/servlet/TestDataSource

Para pruebas (PREPRODUCCION)

http://nombreaplicaciontest.um.es/nombreaplicacion/servlet/SnoopServlet

http://nombreaplicaciontest.um.es/nombreaplicacion/servlet/TestDataSource

Para producción (PRODUCCION)

http://nombreaplicacion.um.es/nombreaplicacion/servlet/SnoopServlet

http://nombreaplicacion.um.es/nombreaplicacion/servlet/TestDataSource

Para las pruebas de migración a Weblogic hay que solicitar a Sistemas un servidor “nombreaplicacionpruebaswl.um.es”.

En esa base de datos ejecutaremos los scripts de creación de base de datos que tengamos en nuestra carpeta “BBDD”. Distinguimos dos casos:

• si no hay ninguna tabla creada (tablas nuevas), se ejecutarán tal y como vienen.

• si ya hay tablas creadas (es la segunda subida o mas a produccion), haremos lo siguiente para ver las posibles modificaciones realizadas.

Compararemos la version actual del proyecto (de la que se acaba de hacer el tag), con la ultima version anterior del proyecto que hay subida en PREPRODUCCION, mediante Tortoise SVN. Mark as compare compare url.

Con esto nos saldrá la lista de cambios que tenemos que ejecutar en VENUSCK o en VENUS.

Hay que ejecutarlos para garantizar que tenemos la version del codigo de BD correcta. Si se ha olvidado algo se deberá de añadir a la rama BD de PREPRODUCCION o PRODUCCION que luego se actualizará al hacer el merge al tronco principal.

Importante: en caso de que no existan esos script, o no se han actualizado porque no se ha seguido MEDEA:

Si estamos subiendo a PREPRODUCCION los cogeremos de la base de datos y los AÑADIREMOS a subversion (commit) a la rama de PREPRODUCCION (betas y CRs)y los ejecutaremos. Si estamos subiendo a PRODUCCION los cogeremos de la base de datos de VENUSCK y los AÑADIREMOS a subversion a la rama de produccion (1.0.0) y los ejecutaremos. Esto es importante para que queden versionados en el sistema.

Si estamos subiendo a PREPRODUCCION informaremos a Sistemas para que cambien el origen de datos de la aplicacion en DESARROLLO para que apunte a VENUSCK en vez de a ISIS. En los ordenadores locales seguirán funcionando con la versión de ISIS.

Cuando se suba por primera vez a PREPRODUCCION, se desactiva la publicación al contenedor de desarrollo de la rama de principal de desarrollo, para que no se “machaque” con la version que queremos enseñar al usuario, ya que comparten el mismo contenedor.

Se seguirán haciendo las tareas de calidad y compilado de la rama principal , pero sin llegar a subirla al contenedor.

Ahora bien una vez que el usuario ha probado la aplicación, quizás nos interese volver a tener esa subida, ya que la versión en preproducción ya no tenga sentido.

Para ello volveriamos a cambiar la url del datasource del contenedor de pruebas a DESARROLLO y bastaria con borrar el fichero

preproduccion.deploy.flag

que se encuentra en la rama de desarrollo (suele ser web_egeria) dentro del nombre del proyecto.

En caso necesario se hará una primera inserción de datos en VENUSCK o en VENUS. Esta inserción inicial de datos será necesaria en caso de que se utilicen datos que no son tratados por la aplicacion.

Por ejemplo, los permisos de usuarios. Tablas donde se guardan los permisos, que se le dan a los usuarios según el rol que tengan. Rol de administrador tiene permisos para estas paginas. Si no se tienen cargados nadie podrá acceder a la aplicación a insertar datos.

Estos scripts de carga de la aplicación deben de estar en el archivo \\carga_inicial.sql
que se encuentra en la rama BD de la aplicación.

Procedimiento de Paso a Producción de una Aplicación (ENS)

Una vez creado el TAG, subiremos el proyecto al contenedor correspondiente (PREPRODUCCION O PRODUCCION).

Hay que explicar la nueva forma de desplegar aplicaciones con Jenkins.

Hay que explicar la nueva forma de desplegar aplicaciones con Jenkins.

Tanto si vamos a publicar a PREPRODUCCION o PRODUCCION , si no existe la tarea Nombreaplicacion-Preproduccion__NOMBREGRUPO o Nombreaplicacion-Produccion_NOMBREGRUPO en el Jenkins habrá que crearla para permitirnos subidas rapidas a los contenedores.

• Si ya existen pasar al paso 2.

• Si no existen crearlas con los siguientes pasos

En la url |crear nuevo proyecto explica como crear una nueva tarea en el Jenkins.

Se creará una tarea Nombreaplicacion_preproduccion_nombregrupo o Nombreaplicacion-preproduccion_nombregrupo copia de Prototipo_preproduccion_MNCS o Prototipo_produccion_MNCS respectivamente.

Luego se pasará a configurar como se explica en configurar nuevo proyecto

en el que modificaremos las url del svn para que apunten en la primera a :

https://svn.um.es/svn/NOMBREAPLICACION/versiones/ETIQUETA_CREADA/Nombreaplicacion-project

donde ETIQUETA_CREADA es el tag recién creado.

y en la segunda a:

https://svn.um.es/svn/NOMBREAPLICACION/web_egeria/NOMBREAPLICACION en caso de que sea a PREPRODUCCION

o bien a https://svn.um.es/svn/NOMBREAPLICACION/web_iuturna/NOMBREAPLICACION en caso de que sea a produccion

Despues de hacer esto pasar al paso 3, directamente.

No situamos en el proyecto Jenkins correspondiente

Y una vez alli cambiamos el campo URL del repositorio a “https://svn.um.es/svn/PROTOTIPO/versiones/1.0.0.beta/fuentes/Prototipo-project” si es la version 1.0.0.beta la que queremos publicar. Si no esta creado el tag ir a Crear Tag Version

Si lo que se está subiendo a PRODUCCION es un proyecto de servicios o conlleva cambios en un proyecto de servicios de los que depende a su vez terceras aplicaciones, el proceso de subida a produccion conllevará más cosas.

Puede llevar cambios en terceras partes (modificar librerias “clientes” del servicio en los servidores de desarrollo / produccion del ejb_interfaces, publicar en Maven la libreria “cliente”, modificar librerias “cliente” manualmente en otras aplicaciones, publicar wsdl, generar clientes nuevos, dar permisos al servidor.

Un proceso que puede llevar muchos puntos, que a su vez son puntos en los que se puede producir un error.

Lo más adecuado es tener una lista de puntos en la Wiki del proyecto especificando PUNTO POR PUNTO los pasos que hay que seguir para hacer la subida de ese proyecto concreto a produccion / preproduccion.

En el Jenkins pulsaremos el botón “Ejecutar Tarea”, que publicará el proyecto en caso de que no tenga errores:

Se comprobará que todo se ha subido correctamente. Se hará un primera prueba de que la aplicación esta correctamente desplegada.

Puede ser que haya fallos en la configuración de ficheros del sistemas, librerias compartidas no subidas etc etc, por lo que habra que consultar los logs de produccion / desarrollo para ver las causas de los distintos fallos.

En caso de que sea una nueva version a PRODUCCION:

Mediante JIRA podemos indicar que la version ha sido correctamente liberada. También habrá que mandar correos informando que la nueva o la nueva versión de la aplicación está disponible.

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 DSP.

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

• project = ClaveDelProyecto
• Disciplina-Proceso = Despliegue-DSP-Preparar entorno de Ejecucion
• 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 = Despliegue-DSP-Preparar entorno de Ejecucion
• label=PRO

Pulsa el botón Search

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