1. Introducción - Ayuntamiento de Madrid

ANEXO a la Guía de Estándares
Manual de Peticiones de Entregas y Despliegues
1
Índice
1.
Introducción _______________________________________________ 3
2.
Descripción del procedimiento en Remedy _______________________ 4
3.
Organización de desarrollo __________________________________ 11
4.
Nuevos grupos de asignación en Sistemas-3N ___________________ 11
2
1. Introducción
El objetivo de este documento es describir el nuevo procedimiento a seguir para los pases a
producción de las aplicaciones web.
El nuevo procedimiento se basa en el uso de la herramienta Remedy a través de la cual y
mediante una Petición de Servicio los equipos de desarrollo comunicarán los pases a
producción de las aplicaciones web J2EE. En un primer momento, el procedimiento va a dar
cobertura a los pases a producción de aplicaciones J2EE dentro del ámbito de servidores WAS,
con la intención posterior de generalizar su uso para los demás entornos.
Para la puesta en funcionamiento de este procedimiento se van a dar de alta en Remedy
nuevos grupos de asignación dentro de Sistemas-3N (ver Anexo apartado 2). Asimismo se va a
crear una nueva organización de soporte denominada “Desarrollo-EntregaAplicacionesWeb”
bajo la cual estarán las distintas unidades de desarrollo de IAM que podrán hacer peticiones de
servicio para el despliegue de aplicaciones (ver Anexo apartado 1). Esta nueva categorización
mantiene la organización de grupos de desarrollo con la que se está trabajando actualmente a
través del buzón corporativo IAM Tecnología Web Solicitudes con el fin de afectar lo menos
posible al procedimiento actual de entrega de aplicaciones y de documentación, conservando,
por tanto, la actual estructura de recursos NAS.
En términos generales el procedimiento a seguir es el siguiente: las unidades de desarrollo
harán una petición de subida a producción de una aplicación al grupo de sistemas “SICAMTecnología-CECADE (Centro de Calidad de Entregas)”. En la petición, además de la aplicación,
versión, entorno donde se pide la subida (inicialmente sólo estará habilitado para producción),
se indicará dónde se encuentra la documentación asociada. Esta documentación se presentará
de manera única y conjunta tanto para la parte de aplicativo como de base de datos. El grupo
de sistemas “SICAM-Tecnología-CECADE” hará una revisión de la entrega y si todo está
correcto y acorde a la normativa a seguir, asignará las tareas necesarias a los distintos grupos
para su ejecución (base de datos, despliegue de aplicación,
asignación de almacenamiento, etc..). Si la documentación o la entrega no son correctas
“SICAM-Tecnología-CECADE” dejará la petición en estado de “Pendiente” indicando al equipo
de desarrollo que subsane dicha situación. Igualmente si durante la ejecución de alguna de las
tareas asignadas se produjera un fallo o faltase algún tipo de información, el grupo que tenga
asignada dicha tarea la dejará en estado “Pendiente”, indicando al equipo de desarrollo que
subsane dicha situación. La entrega podrá también ser rechazada lo cual implicaría “Cancelar”
la petición a nivel de Remedy. Si la petición se rechaza es necesario hacer una nueva entrega
de aplicativo con una versión posterior. El rechazo de una entrega se puede producir por
ejemplo si no supera las pruebas de sistemas. No obstante, en la mayoría de los casos en los
que se encuentre un error, las tareas se quedarán en estado pendiente de subsanación.
3
Hay que destacar que los pases a producción llevarán implícita la tarea de pruebas de sistemas
del aplicativo. Por lo tanto, se tendrá que tener en cuenta a la hora de la planificación del
proyecto que las peticiones de pase a producción se tienen que hacer con el tiempo suficiente
para pasar las pruebas.
2. Descripción del procedimiento en Remedy
A continuación se describen los pasos del nuevo procedimiento en la herramienta Remedy.
1. Las Unidades de desarrollo crean una petición de servicio para el paso a producción
con toda la información necesaria. Se accede desde la Consola de gestión de tickets en
Remedy:
2. Una vez que aparece la consola, en el menú de funciones generales seleccionamos
nuevo ticket.
4
3. Sobre el área Información del ticket, es obligatorio rellenar los campos que están
marcados con asterisco:
 Resumen: Se escribirá resumidamente lo que se pretende con esta petición. Si
se quieren hacer aclaraciones adicionales, se puede utilizar el campo opcional
Notas.
5
 Impacto: del menú desplegable que emerge pulsando la flecha (Ayuntamiento,
Junta,…) se elige el ámbito al que afecta la aplicación.
 Urgencia: Se seleccionará la que corresponda del menú desplegable. Con el
Impacto y Urgencias seleccionados, automáticamente se rellenarán los
campos de Prioridad e Importancia.
4. Sobre la pantalla correspondiente a la pestaña Usuario, se introduce el usuario AYRE
de la persona que está creando el ticket nuevo y se pulsa en el botón Buscar,
automáticamente se rellenarán todos los campos relativos a esta pestaña.
5. A continuación se va a la pantalla correspondiente a la pestaña Clasificación:
6
 Tipo de servicio: Seleccionar Petición de servicio.
 Categorización de producto: A elegir del menú (ver anexo apartado 1),
Además de los 3 niveles de categorización es necesario utilizar dos campos
más, que podrían ser los que en esta pestaña tienen la denominación
“modelo” y “versión” que pasarían a denominarse “aplicación” y “versión”, y
deben ser campos de texto libre
 Categorización operacional:
Nivel 1: Seleccionar Entrega de aplicaciones
Nivel 2: Seleccionar Producción. (En el futuro se incluirán más categorías nivel
2)
 Origen: Otros
6. Seguidamente se pasa a la pantalla de la pestaña Asignación:
7
 Persona asignada al ticket: Empresa de soporte=IAM, Organización de
Soporte=Sistemas-3N, Grupo asignado=SICAM-Tecnología-CECADE. (en el
anexo, apartado 2, se detallan las características de este grupo)
 Propietario del ticket: Empresa de soporte=IAM, Organización de soporte del
propietario= Desarrollo-EntregaAplicacionesWeb, los grupos de propietarios y
los propietarios son los que aparecen en el apartado 1 del anexo.
7. Puede ser muy útil la pantalla que se abre con la pestaña Información de trabajo
 Información de trabajo: Se debe utilizar rellenando los campos Resumen,
Notas para ampliar la descripción del resumen y notas del ticket, por ejemplo
rutas de acceso a las carpetas donde se encuentran las aplicaciones y la
documentación.
 Archivos adjuntos: Si son necesarios se pueden adjuntar en la pestaña de
información de trabajo
8
8. Una vez cumplimentados los datos descritos, se salva y se cierra, y la petición de
servicio será remitida al grupo SICAM-Tecnología-CECADE:
9
9. El grupo asignado, SICAM-Tecnología-CECADE, analiza la petición y la documentación
adjunta, si no cumple los requisitos de la normativa o falta alguna información, la
petición se queda en estado de “pendiente” y se reasigna a la misma persona de
Desarrollo que la inició, cumplimentando en información de trabajo los campos
necesarios para describir las correcciones que deben hacerse o la información que
falta.
10. Desde SICAM-Tecnología-CECADE, cuando se da por válida la entrega se generan las
tareas necesarias para la puesta en producción del aplicativo a través de plantillas
definidas al efecto o bien de forma individual. Los grupos de asignación de sistemas
que pueden intervenir son los siguientes:
 SICAM-BBDD: En el procedimiento se encargan de tareas asignadas cuando el
pase tiene actividades de creación, modificación, copias, aplicación de scripts,
etc., relativos a bases de datos utilizadas por la aplicación objeto del pase a
producción
 SICAM-Tecnología-Despliegues: es el encargado de desplegar las aplicaciones
en los servidores de aplicaciones WAS, según el manual de instalación que
debe estar documentado en la petición de servicio.
 SICAM -Tecnología-Productos: se encarga, en caso de ser requerido en el pase,
de intervenciones con productos software relacionados con la aplicación
objeto de pase a producción, como por ejemplo, Documentum, BPM-SOA
(TIBCO), Actuate, Adobe, etc
 SICAM-Tecnología-Pruebas: Grupo que se encarga de la planificación de
pruebas, verificación y/o elaboración de scripts, elaboración de proyectos en
Quality Center, ejecución de pruebas (unitarias, stress, rendimiento,
estabilidad, regresión), etc.
11. Si alguna de las tareas no finaliza por encontrar algún problema, existen dos
alternativas:
 Si se trata de un fallo leve (como puede ser por ejemplo falta de
documentación, error en un script de base de datos, mal empaquetado del
.ear, etc …) la tarea se quedará en estado de “Pendiente” solicitándole al
usuario de desarrollo que hizo la petición que subsane el fallo y genere nuevo
ticket asociado al que está en curso cuando esté solucionado el problema
 Si se trata de un fallo grave (como por ejemplo que no supere las pruebas de
sistemas por fallos en la ejecución de la aplicación…), la petición se cerrará con
el estado de “Cancelado”, rechazándose por tanto la subida a producción del
aplicativo y se devolverá a desarrollo. Esto supone que para volver a hacer una
petición de subida a producción de esta aplicación se deberá crear una nueva
petición de servicio asignada al grupo “SICAM-Tecnología-CECADE” con una
nueva versión de aplicación. No obstante, en la mayoría de los casos, los fallos
10
que suelen producirse son leves y pueden subsanarse sin tener que dar de alta
una nueva petición de servicio con una nueva versión de la aplicación.
3. Organización de desarrollo
En la tabla siguiente se muestran los tres niveles que se proponen para la organización de los
grupos de desarrollo. Estos niveles están asociados a la categorización de producto exigida en
la clasificación del ticket dentro de Remedy.
4. Nuevos grupos de asignación en Sistemas-3N
Se proponen una serie de grupos en Sistemas-3N para la ejecución de las diferentes tareas
asociadas al procedimiento de despliegue de aplicaciones. Algunos de estos grupos ya existen
actualmente en SICAM y otros son nuevos y por tanto habrá que darlos de alta:
 SICAM-Tecnología-CECADE: Grupo encargado de revisar la entrega de la aplicación:
empaquetado, documentación, etc.
 SICAM-BBDD (Grupo ya existente en sistemas-3N) : En el procedimiento se encargan
de tareas asignadas cuando el pase tiene actividades de creación, modificación, copias,
aplicación de scripts, etc., relativos a bases de datos utilizadas por la aplicación objeto
del pase a producción
 SICAM-Tecnología-Despliegues: es el encargado de desplegar las aplicaciones en los
servidores de aplicaciones WAS, según el manual de instalación que debe estar
documentado en la petición de servicio.
 SICAM-Tecnología-Productos(Grupo ya existente en Sistemas-3N): se encarga, en caso
de ser requerido en el pase, de intervenciones con productos software relacionados
con la aplicación objeto de pase a producción, como por ejemplo, Documentum, BPMSOA (TIBCO), Actuate, Adobe, etc
 SICAM-Tecnología-Pruebas: Grupo que se encarga de la planificación de pruebas,
verificación y/o elaboración de scripts, elaboración de proyectos en Quality Center,
ejecución de pruebas (unitarias, stress, rendimiento, estabilidad, regresión), etc.
Asimismo se ha de cambiar la denominación del grupo de asignación SICAM-TecnologíaAplicaciones por SICAM-Tecnología-Incidencias que será el encargado de atender las
incidencias cómo hasta ahora, e independiente de los pases a producción de aplicativos.
11