Objetivo 

Alcance 

...

Las peticiones de lanzamiento se clasifican por tipificaciones:

• Peticiones de lanzamiento de incremento de versión

...

• (PL incremento versión).  Aplican sobre todas las aplicaciones

...

• centralizadas

...

• que

...

• deben tener desarrollo y evolución

...

• , es decir, versiones en las que se incluyan evolutivos y correctivos.
• Peticiones de lanzamiento para modificación/configuración de software base (PL sistemas). Aplican sobre todas las plataformas centralizadas sobre las que se quieren hacer cambios menores, es decir, sin que sea necesaria una petición de plataforma.
• Peticiones de lanzamiento para modificaciones de datos (PL datos). Aplican sobre las aplicaciones centralizadas sobre las que se requieren peticiones o incidencias de datos que requieren implantación.
• Peticiones de lanzamiento para cambios de configuración (PL configuración). Aplican sobre todas las aplicaciones centralizadas sobre las que se requieren peticiones de configuración.

PL incremento versión

Roles

...

(***) A efectos del flujo en la herramienta, dicho rol no posee acciones

...

Ciclo de vida 

Cuando el proveedor acaba un desarrollo y necesita hacer un despliegue  en unos de los entornos de la STIC, entrega el código para que el proveedor de sistemas que gestiona la plataforma donde va a hacerse el despliegue, lo  ejecute en los entornos solicitados por el proveedor, siempre bajo la supervisión del Responsable de Producto.

...

Hay que tener en cuenta que además de la entidad en la que la OCA verifica el código (SVE=Servicio de Verificación de entrega), e el proceso de gestión de lanzamientos se articula en JIRA con dios dos tipos de entidades:

• PL:  es la contenedora del alcance de la PL, sobre la que revisará la documentación (PID), se solicitarán y generarán implantaciones.
• PL Hija: una subtarea de la PL por cada acto de ejecución de cada  instalación en una Plataforma, entorno, grupo lógico o conjunto de grupos lógicos. Cada una de estas entidades puede contener una o más ejecuciones, la primera siempre correspondiente a una instalación. El hecho de que no se acepte la solución por parte del peticionario, puede llevar a ejecutar una desinstalación, marcha atrás o reinstalación que serán controladas en la PL Hija como ejecuciones de la misma.

Por otra parte, cualquier PL incremento versión puede tener dos tipo:

• Normal: tienen un plazo de ejecución entre 24 y 48 horas.
• Urgente: En este caso la PL debe ejecutarse en el menor tiempo posible, no pudiendo asumirse el plazo de ejecución normal. Hay que tener en cuenta que la ejecución urgente de una PL incrementa los costes de gestión incurridos por este lanzamiento y supone un mayor riesgo de indisponibilidad del servicio. Los motivos por los que puede ser necesaria una PL urgente son:

A continuación se describe el flujo para la SVE, teniendo en cuenta que puede crearse en cualquier momento en el que se conozcan los dígitos de la entrega, pero que no podrá ser asignada a la Oficina Técnica de Calidad hasta que el código no haya sido entregado en el repositorio correspondiente.

Servicio de Verificación de entrega (SVS) 

Diagramas de Flujo para la PL y la PL Hija

Figura 1. Diagrama flujo PL.

...

Figura 2. Diagrama flujo PL Hija.

Tabla de estados y acciones

En el siguiente enlace al manual JIRA se detalla los estados, acciones y roles que pueden actuar en cada punto del flujo.

Descripción del

...

flujo 

Prerrequisitos

Para que el solicitante pueda crear y seguir un flujo de PL de Incremento de versión es necesario que:

...

• La PL si se ha solicitado en algún momento como PLU queda con el campo PLU =SI.
• La PL Hija cambia el valor a PLU = NO cada vez que finaliza una ejecución, por lo que el solicitante debe volver a solicitar PLU en la PL Hija si así lo desea.
• En la tabla de ejecuciones se graba el valor de PLU que tiene en el estado EN RESOLUCIÓN.
• Tanto en la PL como en la PL Hija, el proveedor Sistemas dispone de una acción en la que informará que se ha comunicado con el solicitante.

...