Normas: NOR06-Normativa de solicitud de despliegues€¦ · SUBDIRECCIÓN GENERAL DE SISTEMAS DE...

22 2-- - NN N

OO ORR R

00 066 6-- - NN N

oo orr r mm m

aa att t ii i v

v v aa a dd d

ee e ss s

oo oll l ii i cc c ii i tt t uu udd d

dd dee e

dd dee ess s p

p pll l ii i ee egg g

uu uee ess s -

- - 00 022 2-- - 00 0

00 0-- - 11 1

55 500 0

44 411 155 5

SUBDIRECCIÓN GENERAL DE SISTEMAS DE INFORMACIÓN PARA LA SALUD C/ Micer Mascó, 31 46010 Valencia Tel. 96 386 80 81 - Fax 96 386 82 29

Conselleria de Sanitat - Misser Mascó, 31 y 33 • 46010 VALÈNCIA • Tel. 96 386 66 00 • Fax 96 386 66 07

Normas:

NOR06-Normativa de solicitud de despliegues

Nombre Archivo NOR06-Normativa de solicitud de despliegues

Versión 02.00

Estado final Publicado

Fecha Impresión 15/04/2015 13:21:00

Fecha Salvado 15/04/2015 12:11

Fecha Caducidad y/o Revisión

Ruta


2-NOR06-Normativa de solicitud de despliegues-02-00-150405 Página 2 de 31 Fecha de la última modificación: 15/04/15 Autor: Jose María Cubel Navarro

CONTROL DEL DOCUMENTO A. Versiones Publicadas del Documento

Versión Fecha1 Promotor Descripción de la Versión

01.00 7/10/2011 Laura Casanova Versión Inicial 01.01 17/10/2011 Laura Casanova Contemplando comentarios de la presentación a los

Propietarios de Servicios de CS del 14/10/2011 02.00 15/04/2015 Raúl Jiménez Introducción a la Herramienta de Gestión de Entregas.

Definición más completa de la entrega. Revisión de diagramas.

B. Documentos relacionados

Título o nombre del fichero Naturaleza de la relación

[Ref.1] 3-PE03-Procedimiento de Despliegues

Procedimiento de despliegues, utilizado por los técnicos que ejecutan los despliegues.

[Ref.2] Ficha de Diseño Ficha a completar para la preparación del entorno para el despliegue de nuevas aplicaciones.

[Ref.3] 2-NOR01 Normas Estándares Desarrollo e Implantación

Normas que los Sistemas de Información deben seguir en su ciclo de vida, principalmente desarrollo y despliegue, para su perfecta adaptación a los diferentes entornos corporativos del CPD del Centro de Informática de la Consellería de Sanidad con el propósito que la implantación sea lo más homogénea posible.

C. Destinatarios del documento

Categorización de Seguridad2 Lista de Distribución3:

o Dirigido a: o Restringido a:

D. Participantes en la Edición

Rol4 Nombre Organización / Puesto

Redactor Jose María Cubel GEES

E. Estatus de la versión en edición

Estado final5 V6 Fecha7 Autor Rol Observaciones del Estado final

Borrador 02.00 24/03/2015 Jose María Cubel GEES Introducción a la Herramienta de Gestión de Entregas. Definición más completa de la entrega. Revisión de diagramas.

Visado Aprobado 02.00 15/04/2015 Raúl Jiménez GEES Publicado 02.00 15/04/2015 Jose María Cubel GEES Revisado

1 Fecha: en la que se publica la versión del documento 2 Categorización de Seguridad: ALTO si un riesgo de seguridad supone un perjuicio muy grave para la AVS, MEDIO para un perjuicio

grave y BAJO para un perjuicio limitado. 3 Lista de Distribución: En caso que la distribución no se corresponda con el estándar de derechos de acceso, identifique las personas o

roles a los que positivamente se debe otorgar acceso y a cuales restringirlo. 4 Rol: Registre su rol en la edición de este documento: Promotor, Redactor, Revisor, Publicador 5 Estado final: Borrador / Visado / Aprobado / Publicado / Revisado 6 V: Versión Mayor y Menor 7 Fecha: Especificar la fecha del Estado final

BAJO



Índice 1 PROPÓSITO DEL DOCUMENTO ......................................................................................................................... 4

2 ÁMBITO Y APLICACIÓN ........................................................................................................................................ 5

3 INTRODUCCIÓN ...................................................................................................................................................... 6

4 CONCEPTOS PREVIOS ......................................................................................................................................... 7

4.1 FUENTES DE LA APLICACIÓN ................................................................................................................................ 7 4.2 TIPOS DE ENTREGAS ............................................................................................................................................ 7 4.3 REQUISITOS DEL ENTREGABLE ............................................................................................................................ 9 4.4 APLICACIÓN PARA LA GESTIÓN DE ENTREGAS ................................................................................................... 12 4.5 DESPLIEGUE DE UNA VERSIÓN DE UNA APLICACIÓN .......................................................................................... 12

5 VENTANAS DE DESPLIEGUES. ........................................................................................................................ 13

6 DESPLIEGUE EN EL ENTORNO DE TEST ...................................................................................................... 14

6.1 TAREA 10: APROBACIÓN TÉCNICA DE LA SOLICITUD DE DESPLIEGUE .............................................................. 15 6.2 TAREA 20: PLANIFICACIÓN Y REALIZACIÓN DE LAS PRUEBAS DE IC ................................................................. 15 6.3 TAREA 30: APROBACIÓN DE LAS PRUEBAS DE IC ............................................................................................. 16 6.4 TAREA 40: REVISIÓN Y PROGRAMACIÓN DEL DESPLIEGUE ............................................................................... 16 6.5 TAREA 50: DE EJECUCIÓN DEL DESPLIEGUE .................................................................................................... 16 6.6 TAREA 60: VALIDACIÓN FUNCIONAL DE LA VERSIÓN DESPLEGADA .................................................................. 17 6.7 TAREA 70: PROGRAMACIÓN DE LA REVERSIÓN DEL DESPLIEGUE ..................................................................... 18 6.8 TAREA 80: REVERSIÓN DEL DESPLIEGUE .......................................................................................................... 18 6.9 TAREA 90: VALIDACIÓN FUNCIONAL DE LA VERSIÓN ANTERIOR DE LA APLICACIÓN TRAS LA REVERSIÓN, POR

PARTE DEL PS ............................................................................................................................................................. 18 6.10 TAREA 100: PROGRAMACIÓN DEL RE-DESPLIEGUE EN TEST .......................................................................... 19 6.11 TAREA 110: RE-DESPLIEGUE EN TEST ............................................................................................................ 19 6.12 TAREA 120: REVISIÓN POST-IMPLANTACIÓN DEL DESPLIEGUE EN TEST ........................................................ 19 6.13 TAREA 125: ANÁLISIS DE BBDD EN TEST ....................................................................................................... 19

7 DESPLIEGUE EN EL ENTORNO DE PRE-PRODUCCIÓN ........................................................................... 20

7.1 TAREA 10: APROBACIÓN TÉCNICA DE LA SOLICITUD DE DESPLIEGUE EN PRE-PRODUCCIÓN ................... 21 7.2 TAREA 20: PROGRAMACIÓN PETICIÓN DE DESPLIEGUE EN PRE-PRODUCCIÓN ................................................ 22 7.3 TAREA 30: EJECUCIÓN DEL DESPLIEGUE EN EL ENTORNO DE PRE-PRODUCCIÓN ........................................... 22 7.4 TAREA 40: PROGRAMACIÓN DE LAS PDG ......................................................................................................... 23 7.5 TAREA 50: EJECUCIÓN DE LAS PDG ................................................................................................................. 23 7.6 TAREA 60: APROBACIÓN DE LAS PDG .............................................................................................................. 23 7.7 TAREA 70: PROGRAMACIÓN DE LA REVERSIÓN Y RE-DESPLIEGUE ................................................................... 23 7.8 TAREA 80: REVERSIÓN, MEDIDA DE TIEMPOS Y RE DESPLIEGUE ...................................................................... 23 7.9 TAREA 110: PROGRAMACIÓN DEL DESPLIEGUE EN EL ENTORNO DE FORMACIÓN ........................................... 23 7.10 TAREA 120: DESPLIEGUE EN EL ENTORNO DE FORMACIÓN ............................................................................. 24 7.11 TAREA 130: REVISIÓN POST-IMPLANTACIÓN ..................................................................................................... 24 7.12 TAREA 135: ANÁLISIS DE BBDD EN PRE-PRODUCCIÓN ................................................................................... 24

8 DESPLIEGUE EN EL ENTORNO DE PRODUCCIÓN ..................................................................................... 25

8.1 TAREA 10: APROBACIÓN TÉCNICA DE LA SOLICITUD DE PETICIÓN DE DESPLIEGUE EN PRODUCCIÓN. ............ 26 8.2 TAREA 20: APROBACIÓN DE NEGOCIO, VALIDACIÓN Y PROGRAMACIÓN DEL DESPLIEGUE. .............................. 26 8.3 TAREA 30: EJECUCIÓN DEL DESPLIEGUE EN PRODUCCIÓN .............................................................................. 27 8.4 TAREA 40: VALIDACIÓN FUNCIONAL .................................................................................................................. 27 8.5 TAREA 50: EJECUCIÓN Y VALIDACIÓN DE LA REVERSIÓN DEL DESPLIEGUE. .................................................... 27 8.6 TAREA 60: REALIZACIÓN DE INFORME POSTERIOR AL DESPLIEGUE. ................................................................ 27 8.7 TAREA 65: ANÁLISIS DE BBDD EN PRODUCCIÓN ............................................................................................. 28

9 RESUMEN DE TAREAS Y TIEMPOS DE EJECUCIÓN ................................................................................. 29

1.1 FLUJO NORMAL DE DESPLIEGUES ................................................................................................................... 30 1.2 FLUJO URGENTE DE DESPLIEGUES ................................................................................................................ 31



1 Propósito del documento

En este documento se describe de forma detallada la normativa a seguir para la solicitud y

la ejecución del despliegue de las aplicaciones en los distintos entornos en el Sistema de

Información de CS.

El objeto de este documento es establecer una normativa para la ejecución de despliegues en

los diferentes entornos de CS con el objetivo de asegurar la integridad de las aplicaciones entre

los diferentes entornos, garantizando que se despliega lo mismo en todos ellos, e intentando

mejorar la eficiencia y calidad del proceso de despliegue.



2 Ámbito y Aplicación

El documento está dirigido a todas las personas involucradas en la solicitud de un

despliegue de una aplicación así como a los técnicos encargados de validar, programar y ejecutar

el despliegue.



3 Introducción

Se define como despliegue al conjunto de pasos que se realizan en la CS para poner en

funcionamiento un paquete de entrega o entregable en los distintos entornos de la infraestructura

del CPD de la CS.

Se define como paquete de entrega o entregable al conjunto de ficheros formado por:

Fuentes de la aplicación. En el apartado “4.1 - Fuentes de la aplicación” se explica

en detalle este tipo de ficheros.

Binarios a desplegar. Son el resultado de compilar y empaquetar los fuentes de la

aplicación. La existencia de este tipo de ficheros en el paquete de entrega debe tender

a desaparecer, ya que una de las funciones de GEES es generar estos ficheros. Para

productos cerrados (cuyos fuentes no son propiedad de CS), no se exige el código

fuente para compilarlo.

En el apartado “4.2 - Tipos de entregas¡Error! No se encuentra el origen de la

referencia.” se definen los requisitos que deben cumplir los ficheros del entregable.

Se definen como actores en la ejecución del despliegue:

Propietario del Servicio [PS] de CS: El técnico responsable de la aplicación por parte de

la CS, o persona en quien delegue.

Técnico de la empresa [TE]: El técnico responsable de la aplicación por parte de la

empresa desarrolladora.

Técnico de análisis de GEES [TA]: Los técnicos responsables de hacer el análisis de la

entrega en el entorno IC (Inspección Continua) y las Pruebas de Garantía en pre-

producción.

Técnico de operación de GTEC [TO]: El técnico responsable de la ejecución del

despliegue de la aplicación.

Glosario de acrónimos:

ACAI: Auditoría de Calidad Interna

IC: Inspección Continua.

GSCI: Servicio de Gestión de Sistemas del Centro de Informática de CS.

GEES: Grupo de Gestión de Entrega y Evaluación de Software (pertenece al GSCI)

GTEC: Grupo de Gestión Tecnológica (pertenece al GSCI).

PDG: Pruebas de Garantía, realizadas en el entorno de Preproducción.



4 Conceptos previos

4.1 Fuentes de la aplicación

Se define como fuentes de la aplicación, cualquier fichero necesario para conseguir el

correcto empaquetado de la aplicación y obtener su modelo de datos asociado, así como

cualquier fichero necesario en tiempo de ejecución para su correcto funcionamiento.

Por tanto, esta definición engloba el propio código, los scripts para empaquetar y compilar la

aplicación, las sentencias SQL (tanto scripts de creación del modelo de datos de la versión inicial

como los scripts que modifican el modelo en las sucesivas versiones de la aplicación) y otros

recursos (ficheros de configuración, ficheros estáticos -frontend files-, documentación).

Cada versión de los fuentes es almacenada por el personal de GEES en un repositorio de

código.

Una aplicación contendrá una sola tecnología de compilación. Por ejemplo, no podrá existir

una aplicación con tecnología JEE y Oracle Developer. A efectos de entrega, se considerarán dos

aplicaciones distintas.

4.2 Tipos de entregas

En función del contenido que incluya una entrega, se puede clasificar en las

siguientes categorías.

Completa: Incluye todo el contenido de los fuentes de la versión. Debe incluir el

histórico de SQLs.

Parcial: Es un subconjunto de los fuentes de la aplicación. Independientemente del

número de ficheros que se entreguen, estos deberán respetar la estructura de la

entrega completa.

Adicionalmente, en caso de que la entrega presente errores detectados antes de ser

desplegada en test es posible realizar entregas de corrección de errores

Notas:

Tanto la entrega completa como la entrega parcial deberá proporcionar un número de

versión distinto a los ya entregados. Sólo se permite usar un número de versión ya

entregada para correcciones de errores.

No se permiten entregas parciales para corrección de código fuente de aplicaciones

Java.



La modalidad de entregas parcial será la que se utilice normalmente para

despliegues de aplicaciones basadas en Oracle Developer o despliegues que sólo

contengan scripts de BBDD.

En la siguiente imagen se muestran ejemplos de entregas parciales y completas:

Entrega completa

La versión 01.02.00. Incluye todos los ficheros

de la aplicación. Incluye SQLs de versiones

anteriores.

Entrega parcial

La versión 01.02.01 no incluye todos los

ficheros de la aplicación. Mantiene la estructura

de directorios.



4.3 Requisitos del entregable

Independientemente del tipo de entrega que se realice, siempre deberá cumplir los

siguientes requisitos:

1. Los ficheros de la entrega deben cumplir la normativa de desarrollo e implantación ([Ref.3]

2-NOR01 Normas Estándares Desarrollo e Implantación)

2. Cada entrega debe incrementar el número de versión, no se permite la entrega de dos

versiones con distinto código fuente y mismo número de versión excepto si la entrega se

fue incorrecta, tal como se explica en 4.2.

3. El versionado de las aplicaciones debe cumplir el siguiente patrón.

MM.mm.pp

Donde:

MM: versión Mayor. Es un número (00, 01, 02,…) en secuencia cronológica que

identifica grandes cambios en el servicio.

mm: versión Menor. Es un número (00, 01, 02,…) en secuencia cronológica que

identifica mejoras funcionales menores en el servicio.

pp: versión Parche. Es un número (00, 01, 02,…) en secuencia cronológica que

identifica cambios en el servicio correspondientes a la resolución de errores.

Las versiones de entregas planificadas en el Plan de Entregas de un servicio dispondrán de

la numeración mayor y menor que corresponda y la 00 para el número de parche.

Cada intento de una nueva entrega deberá estar asociado a una numeración “MM.mm.pp”

único. Así, por ejemplo, si una entrega no supera algunas de las pruebas, o hubiera que echar

marcha atrás del entorno de producción, y hubiera por tanto que devolverla a la empresa

adjudicataria para su corrección, la próxima entrega deberá tener una numeración de versión

diferente, bien incrementándole uno al “pp”, o re planificar el Plan de Entregas para incluir los

requisitos en una entrega Mayor o Menor posterior.

4. El fichero de fuentes debe proporcionarse como un único fichero comprimido. Los formatos

válidos para este fichero son zip, gzip o tar-gzip. El formato rar no es un formato válido.

5. El contenido del fichero de fuentes debe ser mínimo. No se permite la existencia de

contenido generado a partir de la compilación o empaquetado del código. Son ficheros que

no aportan nada y sólo contribuyen a aumentar el espacio de archivado.

Ejemplos de contenido no permitido:



o Directorios que se generan al empaquetar (target o bin).

o Ficheros compilados (class, war, ear)

o Ficheros de configuración del IDE usado en su desarrollo (.project, .settings,

.classpath).

o Ficheros de configuración de repositorios de versiones (.svn, .git, .cvs...).

6. Los fuentes de la aplicación deberán seguir la siguiente estructura para facilitar la

generación de los binarios y su despliegue en los distintos entornos:

/source código compilable, scripts de compilación, tests unitarios

/sql SQLs de la aplicación

/static ficheros estáticos para desplegar en los frontales web

/config ficheros de configuración (una carpeta por entorno, TEST,

PRE, PRO)

/doc documentación de la aplicación

Si alguna aplicación no necesita alguno de los directorios anteriores pueden

suprimirse.

Para entregas cuya base tecnológica sea Oracle Developer, se propone la siguiente

estructura organizativa.

/source/forms código fuente forms (*.fmb)

/source/reports código fuente reports (*.rdf)

/source/menu código fuente menus (*.mmb)

/source/lib librerías de la aplicación y olb’s (fuentes y ejecutables)

/sql SQLs de la aplicación.

/static ficheros estáticos para desplegar en los frontales web

/config ficheros de configuración (para cada entorno)

/doc documentación de la aplicación



Ejemplos de estructuras de entregas:

JEE con Maven

(un solo módulo)

JEE con Maven

(multimódulo)

Oracle Developer

7. La estructura de directorios de la aplicación debe mantenerse entre versiones para permitir

la automatización de las tareas de compilación y despliegue.

8. En la entrega siempre deben proporcionarse todos los fuentes de la aplicación, aunque los

cambios introducidos en la versión sean mínimos. Sólo se aceptan entregas parciales

cuando la tecnología es Oracle Forms y cuando se entregan sólo SQLs, estáticos o

propiedades. En estos casos, la jerarquía de directorios también deberá mantenerse

intacta y se indicará explícitamente que la entrega es parcial.

9. Los ficheros que no se encuentren en los fuentes o no se puedan obtener a partir de ellos,

no se podrán utilizar en el despliegue. Si la entrega es parcial sólo podrán usarse los

archivos de esa entrega.

10. No se impone ninguna estructura organizativa, aunque se aconseja utilizar una estructura

que se adapte a las necesidades de esta normativa y que resulte sencillo describir las

instrucciones necesarias para desplegar la aplicación.

11. Todos los scripts de BBDD deberán seguir el formato especificado en ([Ref.3] 2-NOR01

Normas Estándares Desarrollo e Implantación). Los fuentes deben contemplar el



versionado de las SQLs. Véase apartado 3.3.3 Versionado de scripts de BBDD de dicho

documento.

4.4 Aplicación para la gestión de entregas

Como parte del Portal del Desarrollador (https://phasic.san.gva.es) se dispone de una

aplicación encargada de gestionar homogéneamente todas las entregas y verificar el cumplimiento

de los requisitos definidos anteriormente. La URL de acceso a esta aplicación es la siguiente:

https://phasic.san.gva.es/delivery

Esta aplicación permite entregar tanto los fuentes como los binarios de la entrega, así como

especificar las instrucciones de despliegue para los diferentes entornos e información relevante

para llevar el despliegue a cabo.

A cada entrega se le asociará un identificador de entrega único que se utilizará como

referencia al solicitar los despliegues.

4.5 Despliegue de una versión de una aplicación

El despliegue de una nueva aplicación o de una nueva versión existente, requiere que por

parte del PS se soliciten los siguientes tickets de cambio (RFC):

1. Sólo en el caso de que sea una nueva aplicación, RFC - Alta de nueva aplicación,

adjuntando la ficha de diseño ([Ref.2] Ficha de Diseño).

2. Preparación de la entrega a través de la herramienta de gestión de entregas. Este paso lo

podrá realizar tanto el PS como el TE.

3. RFC- Petición de despliegue en el entorno de TEST. Los pasos a realizar en el entorno de

TEST, aparecen detallados en el punto 6.

4. RFC- Petición de despliegue en el entorno de PREPRODUCCION. Los pasos a realizar en

el entorno de PREPRODUCCIÓN, aparecen detallados en el punto 7.

5. RFC- Petición de despliegue en el entorno de PRODUCCION. Los pasos a realizar en el

entorno de PRODUCCIÓN, aparecen detallados en el punto 8.



5 Ventanas de Despliegues.

Las ventanas establecidas para los despliegues en TEST, PRE, PRO y FOR serán las que a

continuación se muestran, teniendo en cuenta que para las aplicaciones críticas en PRO se

aplicará otra ventana. Se consideran como aplicaciones críticas SIA, GAIA, CRC, SIP, HSE.

Despliegues de aplicaciones en PRO:

o Aplicaciones críticas (SIA, GAIA, CRC, SIP, HSE): miércoles y jueves a partir

de las 22:00

o Resto de aplicaciones: lunes a jueves de 15:00 a 20:00

Despliegues de aplicaciones en TEST

o Lunes a Viernes, de 15:00 a 20:00

Despliegues de aplicaciones en PRE

o Lunes a Viernes, de 08:00 a 20:00

Despliegues de aplicaciones en FOR

o Lunes-Viernes fuera de los horarios de las reservas de Formación hechas

por los PS (Web calendar).

Nota: El intervalo mínimo de tiempo que ha de pasar entre despliegues de aplicaciones

críticas será de una semana. El objetivo es asegurar la detección de la causa de los problemas

que pudieran surgir.

Despliegues en TEST

Despliegues en PRE

Despliegues en FOR

Despliegues en PRO

Despliegues en PRO/ Aplicaciones críticas

hora/día LUNES MARTES MIÉRCOLES JUEVES VIERNES

8:00-15:00

15:00-20:00

20:00-22:00

22:00-8:00



6 Despliegue en el entorno de test En el siguiente diagrama, se muestran las distintas etapas que existen en el procedimiento

de despliegue de una aplicación en el entorno de TEST:



El PS creará un ticket de la categoría [Cambio].Despliegue en TEST desde la plantilla

correspondiente (Despliegue en TEST)

En la solicitud se debe incluir:

Formato solicitud:

Descripción: [Plataforma][Despliegue][TEST] nombre_aplicación Versión.

Donde:

Plataforma: NISS / ALSIS / NEOS / LOGIS / BI. (Si la plataforma es el

NISS, puede obviarse.)

Tipo: Cambio

Pestaña Propiedades:

o Nombre de la aplicación

o Ejecución de pruebas (indicar si se requieren pruebas por parte de CATS o

de otro tipo).

Incluir referencia del identificador de entrega

6.1 Tarea 10: Aprobación Técnica de la solicitud de despliegue

Esta tarea la realiza un TO.

Se valida la información del despliegue referente al entorno de TEST en la

aplicación de gestión de entregas, determinadas por el identificador de entregas.

Si se requiere información adicional se solicitará al peticionario (en este caso el TO

pasará el ticket a estado “Pendiente por usuario”). Cuando el PS incluya la

información solicitada reactivará el ticket.

Si no se completa la información requerida, el TO rechaza el RFC.

Si el despliegue sólo incluye ficheros ejecutables (.ear, etc.), el TO eliminará las

tareas de reversión y redespliegue, ya que no se considera necesaria la ejecución

de las mismas (aunque sí es de obligado cumplimiento su inclusión en la entrega).

6.2 Tarea 20: Planificación y realización de las pruebas de IC

En esta tarea se copian los ficheros al entorno de IC para versionarlos. Posteriormente, el TA (GEES) comprobará si la aplicación debe analizarse en el entorno de IC, las aplicaciones que se analizan son los desarrollos a medida en Java o PHP.

Si la aplicación a desplegar no pasa análisis en el entorno de IC, el TA eliminará la

tarea siguiente de aprobación de las pruebas de IC (Apartado 6.3)



Si la aplicación a desplegar pasa análisis en el entorno de IC, se planificarán y

ejecutarán las pruebas de IC y se registrarán los resultados.

6.3 Tarea 30: Aprobación de las pruebas de IC

El Responsable de GEES recibirá los resultados de la pruebas de IC.

a. Si los resultados de IC no son satisfactorios :

o El Responsable de GEES rechazará la solicitud de despliegue y cierra el ticket sin

éxito.

o El despliegue no se ejecutará.

b. Si los resultados son satisfactorios :

o El Responsable de GEES aprueba la tarea.

o Pasa a realizarse la Tarea 40.

6.4 Tarea 40: Revisión y programación del despliegue

Estas tareas las realiza un TO

1. Se programa el despliegue.

o Si el TO considera necesaria la asistencia durante el despliegue del TE lo indicará en

la petición con 24 horas de antelación.

o En caso de que el responsable de sistemas decida la re-programación del

despliegue, se avisará al PS.

2. Se copiarán los ficheros a desplegar (ubicados en el entorno de IC) a los diferentes

servidores del entorno de TEST:

6.5 Tarea 50: de Ejecución del Despliegue

El TO ejecutará el despliegue en la fecha programada. El orden de ejecución será el

indicado en las instrucciones de despliegue de la entrega.

o Se ejecutarán los scripts (que deben estar perfectamente probados en los entornos de

desarrollo de las empresas) y en función del resultado de la ejecución se realizarán

distintas operaciones:

1. Si el resultado de la ejecución es OK.

o Se finaliza la tarea.

o Automáticamente, se pasa a la tarea siguiente, y se envía un correo al PS

indicándole que puede iniciar las pruebas funcionales.



2. Si el resultado de la ejecución es con errores (KO):

o Se cambia el estado del ticket a “Pendiente por usuario”.

o El PS evalúa el error y decide qué acción tomar:

1. Si da por válido el despliegue, lo indica en el ticket y reactiva el ticket.

El TO finaliza la Tarea y se pasa a la tarea siguiente,

automáticamente se envía un correo al PS indicándole que puede

iniciar las pruebas funcionales.

2. Si no da por válido el despliegue.

Se pasa la tarea a estado “Reversión necesaria”

Se ejecutará la reversión y se cerrará el ticket sin éxito.

6.6 Tarea 60: Validación Funcional de la versión desplegada

El PS debe realizar esta tarea.

La Validación funcional de la versión desplegada implica:

1. Validar la funcionalidad de la aplicación.

2. Validar las integraciones con otras aplicaciones.

En función del resultado de la Validación se deben realizar varias acciones:

Si las pruebas funcionales son satisfactorias:

o El PS debe pasar la tarea a estado “Aprobada”

o Automáticamente, se pasa a la tarea siguiente y se ejecutará la reversión.

Si las pruebas funcionales no son satisfactorias:

o El PS debe pasar la tarea a estado “Reversión necesaria”.

o Automáticamente se pasa a la tarea siguiente, se ejecutará la reversión y se cerrará

el ticket sin éxito

Si las pruebas funcionales no son satisfactorias pero el PS decide generar un parche:

o El PS debe pasar la tarea a estado “En espera de parche”

o Automáticamente, se eliminarán el resto de tareas y se cerrará el RFC sin éxito. No

se ejecutará la reversión, y se quedará a la espera de una nueva RFC con el

parche, en el que se incluirá el nuevo parche, y la reversión completa de la versión

más el parche.



6.7 Tarea 70: Programación de la reversión del despliegue

o El TO programa la reversión del despliegue en TEST.

o Si considera necesario la asistencia durante el despliegue del TE lo indicará en la petición

con 24 horas de antelación.

o En caso de que el responsable de sistemas decida la re-programación del despliegue, se

avisará al PS

6.8 Tarea 80: Reversión del despliegue

El TO ejecuta la reversión en la fecha programada con los ficheros almacenados en el entorno de

IC.

En función del resultado de la reversión, se realizan las siguientes actividades:

1. Si el resultado es correcto se pasas a la tarea 90 (Validación funcional de la versión tras la

reversión).

2. Si el resultado es incorrecto (KO):

o Se notifica el resultado incorrecto al PS a través de la herramienta CA y se deja el

ticket en “Pendiente por usuario”.

o El PS verifica los logs para saber el tipo de error y en función del mismo, decide si.

El error no indica que la reversión sea incorrecta, por lo que se actuaría

como si el resultado fuera correcto, aunque en este caso el PS debe

indicarlo en el ticket.

El error indica que la reversión es incorrecta,

Se cierra el ticket y se marca en el campo Código de finalización, sin éxito.

(El PS debe solicitar un RFC parche para volver a la aplicación a la versión

anterior antes del despliegue y cuando se ejecute con éxito entonces

solicitar un nuevo despliegue de la versión con los scripts corregidos)

6.9 Tarea 90: Validación funcional de la versión anterior de la

aplicación tras la reversión, por parte del PS

La Validación funcional de la versión anterior la realiza el PS y en esta fase pueden darse dos

situaciones:

1. En el caso de que la Validación funcional sea conforme (OK):

o Se pasará el estado de la tarea a “Aprobada”



o Se pasa a la tarea siguiente y se ejecutará el redespliegue.

2. En el caso de que la Validación funcional no sea conforme (KO):

Se cierra el ticket y se marca en el campo Código de finalización, sin éxito. (El PS debe

solicitar un RFC parche para volver a la aplicación a la versión anterior antes del

despliegue y cuando se ejecute con éxito entonces solicitar un nuevo despliegue de la

versión con los scripts corregidos).

6.10 Tarea 100: Programación del re-despliegue en TEST

Se actúa de igual forma que en el paso 40, del flujograma.

6.11 Tarea 110: Re-despliegue en TEST

Se actúa de igual forma que en el paso 50, del flujograma.

6.12 Tarea 120: Revisión post-implantación del despliegue en TEST

Esta tarea se realiza en GTEC

GTEC revisa cómo ha ido el despliegue de la nueva versión.

Si el resultado de la revisión es conforme, se aprueba la tarea y se cierra el ticket.

Si el resultado de la revisión no es conforme, GTEC se pondrá en contacto con el PS

6.13 Tarea 125: Análisis de BBDD en TEST

Esta tarea se realiza en GEES

GEES analiza el esquema de BBDD asociado a la versión instalada.

Si el resultado de la revisión no es conforme, GEES se pondrá en contacto con el PS

El ámbito de los análisis queda restringido a BBDD Oracle y PostgreSQL, excluyendo

aplicaciones de datamart y productos no desarrollados a medida.



7 Despliegue en el entorno de Pre-producción

En el diagrama se muestra las distintas etapas del procedimiento de despliegue en

Preproducción:

Informe

Aprobada

Finalizada

Asignado

Pte. Aprobación y Planificación

Aprobada

Cerrado (con éxito)

Cerrado (sin éxito)

Programado / En implantación

Error

Rechazada

10. Aprobación técnica de la Solicitud de despliegues

SISTEMAS

20. Programación del despliegue

SISTEMAS

30. Ejecución del despliegue

SISTEMAS

40. Programación de Pruebas de Garantía

GEES

50. Ejecución de Pruebas de Garantía

GEES

60. Aprobación de resultados de Pruebas de Garantía

GEES

70. Programación de la reversión y redespliegue

SISTEMAS

80. Reversión, medida de tiempos y redespliegue

SISTEMAS

120. Despliegue en FOR

SISTEMAS

130. Revisión post-implantación

SISTEMAS

135. Análisis de BBDD

GEES

110. Programación del despliegue en FOR

SISTEMAS

Finalizada

Finalizada

Aprobada

Finalizada

Finalizada

Finalizada

Finalizada

Finalizada

Finalizada

Reversión necesaria


Finalizada

Ejecutar reversión del despliegue en FOR

Error



El PS creará un ticket de la categoría [Cambio].Despliegue en PRE desde la plantilla

correspondiente (Despliegue en PRE):

Formato solicitud:

[Plataforma][Despliegue][PRE] nombre_aplicación Versión.

Dónde:

Plataforma: NISS / ALSIS / NEOS / BI / LOGIS... (Si la plataforma es el

NISS, puede obviarse)

Tipo: Cambio



o Versión a desplegar

o Incluir referencia del identificador de entrega

7.1 Tarea 10: Aprobación Técnica de la solicitud de despliegue en

PRE-PRODUCCIÓN

La petición de despliegue será asignada a un TO quien pasará a realizar las validaciones

del despliegue.

Se valida la información del despliegue referente al entorno de PRE en la aplicación de

gestión de entregas, determinadas por el identificador de entrega.

El TO relacionará este ticket como hijo del ticket de despliegue de la misma versión en

TEST.

Nota: La forma de especificar el acumulado de versiones es, Si el despliegue 01.00.03

incluye el despliegue 01.00.02, la solicitud de despliegue se debe especificar que el despliegue

incluye estás dos versiones, esto es: [Plataforma][Despliegue] [Entorno] nombre_aplicación

01.00.02+01.00.03.

Por ejemplo:

o TEST: despliegue 01.00.01



o PRE: despliegue 01.00.01



o PRE: despliegue 01.00.03 Rechazamos el despliegue porque no se ha hecho el

despliegue de la versión 01.00.02 en PRE.

Si se requiere información adicional se solicitará al peticionario (en este caso el TO pasará

el ticket a estado “Pendiente por usuario”). Cuando el PS incluya la información solicitada

reactivará el ticket.

Si no existe entorno en FOR o no está actualizado, se eliminan las tareas relacionadas con

este entorno.

Si no se subsana la falta de información, o se ha abierto en esta categoría por error el

Estado final de salida será “Rechazada”.

7.2 Tarea 20: Programación petición de despliegue en Pre-producción

El TO realiza la programación del despliegue y se notifica al PS.

Si el TO considera necesaria la asistencia durante el despliegue del TE lo indicará en la

petición con 24 horas de antelación.

En caso de que el responsable de sistemas decida la re-programación del despliegue, se

avisará al PS.

7.3 Tarea 30: Ejecución del despliegue en el entorno de Pre-

producción

El TO ejecutará el despliegue en la fecha programada, midiendo la duración del despliegue. El

orden de ejecución será el indicado en las instrucciones de despliegue de la entrega.

Si el resultado de la ejecución es correcto (OK), se finaliza la tarea y se pasa a la

programación de las PDG.

Si el resultado de la ejecución es con errores (KO):

o Se cambia el estado del ticket a “Pendiente por usuario”.

o El PS evalúa el error y decide qué acción tomar:

1. Si da por válido el despliegue, lo indica en el ticket y reactiva el ticket.

El TO finaliza la Tarea y se pasa a la tarea siguiente,

2. Si no da por válido el despliegue.

Se pasa la tarea a estado “Reversión necesaria”

Se ejecutará la reversión en TEST y PRE y se cerrará el ticket sin

éxito.



7.4 Tarea 40: Programación de las PDG

Esta tarea la realiza un TA de GEES, consistente en el plan de pruebas y programar las PDG.

7.5 Tarea 50: Ejecución de las PDG

El TA ejecuta las pruebas y envía los resultados a la empresa responsable de la aplicación

para que esta genere el informe de PDG.

El ticket queda en estado “Pendiente por proveedor” hasta que se recibe el informe.

7.6 Tarea 60: Aprobación de las PDG

Esta tarea la realiza un TA.

Si las PDG se han superado con éxito, se aprueba la tarea y se pasa a la siguiente.

Si los resultados de las PDG no son satisfactorios o las pruebas no han funcionado, se

ejecutará la reversión en los entornos de PRE y TEST, y se cierra el ticket sin éxito.

7.7 Tarea 70: Programación de la reversión y re-despliegue

El TO programa la reversión y re-despliegue. Se notificarán al PS.

7.8 Tarea 80: Reversión, medida de tiempos y re despliegue

El TO ejecuta la reversión en PRE, midiendo el tiempo, en esta misma tarea se aprueba o

rechaza la duración

Si el resultado es correcto (OK) se realiza el redespliegue y se pasa a la siguiente tarea.

Si el resultado de dicha ejecución es con errores (KO), se deberá:

o Identificar la causa del problema.

o Contactar con el PS para que verifique y confirme si la reversión es o no correcta:

Si es correcta la reversión aunque han salido errores entonces se procederá

a realizar el re-despliegue y se finaliza la tarea.

Si no es correcta la reversión, se cierra el RFC sin éxito.

El PS debe solicitar un RFC parche para volver a la versión anterior

antes del despliegue y se debe comenzar el proceso desde TEST

7.9 Tarea 110: Programación del despliegue en el entorno de

Formación

El TO programa el despliegue en el entorno de FOR.



7.10 Tarea 120: Despliegue en el entorno de Formación

El TO ejecuta el despliegue en el entorno de FOR.

Si el despliegue finaliza correctamente, se finaliza esta tarea.

Si el despliegue no finaliza correctamente, se hace la reversión en FOR, se marca como

estado de la tarea “Error”, pero se continúa con la tarea siguiente.

7.11 Tarea 130: Revisión post-implantación

Esta tarea se realiza en GTEC

GTEC revisa cómo ha ido el despliegue de la nueva versión.

Si el resultado de la revisión se conforme, se aprueba la tarea y se cierra el ticket.

Si el resultado de la revisión no es conforme, GTEC se pondrá en contacto con el PS.

7.12 Tarea 135: Análisis de BBDD en Pre-producción








8 Despliegue en el entorno de Producción

En el diagrama vemos las distintas etapas del procedimiento del despliegue de una aplicación

en el entorno de Producción:

Informe

Aprobada

Finalizada

Aprobada

Cerrado (sin éxito)

Error30. Ejecucion del despliegue

20. Aprobacion de negocio y ejecucion del despliegue

Finalizada

Finalizada

Finalizada


SISTEMAS

35. Validacion Funcional

SOLICITANTE

SISTEMAS

40. Ejecucion y validacion de la Reversion del despliegue

SISTEMAS

50. Aprobacion post implantacion

SISTEMAS

55. Análisis de BBDD

GEES

Pte. Aprobación y Planificación

Programado / En implantación

10. Aprobacion Tecnica Solicitud del despliegue

SISTEMAS

Asignado

Cerrado (con éxito)

Finalizada

Finalizada

Solicitar y ejecutar parche de reversión

Informe

Error

Finalizada

Error

El PS creará un ticket de la categoría [Cambio].Despliegue en PRO desde la plantilla

correspondiente (Despliegue en PRO)

Formato solicitud:

[Plataforma][Despliegue][PRO] nombre_aplicación Versión.

Dónde:

Plataforma: NISS / ALSIS / NEOS / BI / LOGIS... (Si la plataforma es el NISS, puede

obviarse.)



Tipo: Cambio



o Versión a desplegar

o Ejecución de Pruebas (indicar si se requieren pruebas por parte de CATS o

de otro tipo).

o Identificador entrega.

8.1 Tarea 10: Aprobación técnica de la solicitud de petición de

despliegue en Producción.

La petición de despliegue será asignada a un TO quien pasará a realizar las validaciones

del despliegue.

El TO relacionará este ticket con el ticket de despliegue de la misma versión en PRE.

Se valida la información del despliegue referente al entorno de PRO en la aplicación de

gestión de entregas, determinadas por el identificador de entrega.

Si se requiere información adicional se solicitará al PS y el ticket pasará a estado

“Pendiente por usuario”. Cuando el PS incluya la información solicitada reactivará el ticket.

Si no se subsana la falta de información se rechazará.

Se propone una fecha de despliegue.

Si la previsión de la duración del despliegue excede la ventana y pone en peligro el

servicio, se rechazará.

Nota: Si es necesario por la criticidad de la aplicación, se realizará un documento con el plan

de acciones del despliegue, incluyendo los pasos a realizar y el responsable de cada uno de

ellos, que se seguirá en la ejecución del mismo

8.2 Tarea 20: Aprobación de negocio, validación y programación del

despliegue.

GTEC programa el despliegue en PRO.

Si GTEC considera necesario la asistencia durante el despliegue del TE lo indicará en la

petición con 24 horas de antelación.

En caso de que el responsable de sistemas decida la re-programación del despliegue, se

avisará al PS.



8.3 Tarea 30: Ejecución del despliegue en Producción

El TO realiza el despliegue.

Si el resultado de dicha ejecución es OK, se pasa a la validación funcional.

Si el resultado de dicha ejecución es con errores (KO), GTEC se pondrá en contacto con el

PS. y se pasa a la tarea de Ejecución de la Reversión.

8.4 Tarea 40: Validación Funcional

El PS el responsable de esta tarea

La Validación funcional de la versión desplegada implica:

o Validar la funcionalidad de la aplicación.

o Validar las integraciones con otras aplicaciones.

En función del resultado de la Validación se deben realizar varias acciones:

Si las pruebas funcionales son satisfactorias:

o El PS pasa la tarea a Estado “Aprobada” y se pasa a la tarea de Realización del

informe. (no se ejecutará la reversión)

Si las pruebas funcionales no son satisfactorias:

o Cambiar el estado de la tarea a “Reversión necesaria”.

o Se pasa a la tarea ejecución de la reversión.

8.5 Tarea 50: Ejecución y validación de la reversión del despliegue.

Si la validación funcional o el despliegue no han funcionado correctamente, se ejecuta la

reversión del despliegue en PRO.

Tras la reversión se valida con quien corresponda que ha funcionado correctamente y se

cierra el RFC sin éxito.

El PS deberá solicitar la reversión también en los entornos de PRE y TEST.

En caso de que la validación funcional de la reversión no fuera correcta, el PS debe

coordinar las operaciones oportunas hasta que la aplicación funcione correctamente

8.6 Tarea 60: Realización de informe posterior al despliegue.

Durante unos días tras el despliegue, el TA elaborará un informe post-implantación. Una vez

finalizado, se adjunta el informe y se cierra el RFC.



8.7 Tarea 65: Análisis de BBDD en Producción








9 Resumen de tareas y tiempos de ejecución

En este último punto, se representan gráficamente las tareas en una escala de tiempo, de

forma que se pueda ver de forma sencilla la sucesión de las actividades en el tiempo, así como los

tiempos totales de ejecución de los despliegues.

Se distinguen los despliegues normales y los urgentes. Para que un despliegue sea

considerado como urgente debe estar relacionado con una incidencia de alta prioridad.

22 2-- - NN N

OO ORR R

00 066 6-- - NN N

oo orr r mm m

aa att t ii i v

v v aa a dd d

ee e ss s

oo oll l ii i cc c ii i tt t uu udd d

dd dee e

dd dee ess s p

p pll l ii i ee egg g

uu uee ess s -

- - 00 000 0

00 011 1

-- - 11 111 111 1

00 000 077 7

2-NOR06-Normativa de solicitud de despliegues-01-00-111007 Página 30 de 31 Fecha de la última modificación: 15/04/15 Autor: David García Navarro

1.1 Flujo NORMAL de despliegues



1.2 Flujo URGENTE de despliegues

5

Normas: NOR06-Normativa de solicitud de despliegues€¦ · SUBDIRECCIÓN GENERAL DE SISTEMAS DE...

Documents

Transcript of Normas: NOR06-Normativa de solicitud de despliegues€¦ · SUBDIRECCIÓN GENERAL DE SISTEMAS DE...