Objetivo 

Alcance 

Las peticiones de lanzamiento se clasifican por tipificaciones:

• Peticiones de lanzamiento de incremento de versión (PL 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

(*)  En la documentación usaremos la palabra solicitante queriendo indicar que las acciones las puede realizar tanto el Responsable de producto (y cualquier jefe de proyecto del área de Proyectos) como el proveedor (de desarrollo).

(**)  A efectos del flujo en la herramienta, los permisos del Responsable de Sistemas son los mismos que los que tiene cualquier jefe de proyectos del área de Sistemas

(***) 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.

Por tanto, será necesario saber la normativa de gestión de entregas y qué requerimientos debe cumplir el proveedor para que el código que ha desarrollado pueda ser desplegado satisfactoriamente:

• Debe estar clara la entrega que se quiere desplegar, Siempre va a constar de cuatro dígitos, donde los tres primeros vienen dados por el código de la versión. Por tanto, debe existir una versión en estado "En resolución"  para determinar los tres primeros dígitos. El cuarto dígito se informará de forma secuencial teniendo en cuenta que para una versión no puede haber más de una petición de lanzamiento abierta.
• El proveedor debe entregar el código siguiendo la normativa establecida por el área de Gobernanza (https://ws001.sspa.juntadeandalucia.es/unifica/web/gobernanza/gestion-de-entregas)
• El proveedor debe realizar el procedimiento de Instalación y desinstalación (PID), es decir, debe describirse el proceso de despliegue sobre la plataforma que previamente se habrá construido o modificado siguiendo el proceso de Gestión de Plataformas.
• No es posible solicitar una PL sin que la OCA realice una verificación del código entregado. Básicamente, la verificación de la entrega consta de las siguientes tareas:
  • Verificación estructura correcta del repositorio GIT
  • Verificación campos del fichero Readme.md
  • Verificación Cumplimiento de la Normativa Oracle
  • Verificación uso correcto de  Gitflow
  • Verificación estructura de los archivos pom.xml y build.xml
  • Compilaciones JENKINS
  • Verificación y validación de calidad estática del código

Mientras la OCA no ejecute su verificación es imposible avanzar con la PL. Ahora bien, el veredicto de la OCA puede ser conforme o no conforme. En cualquier caso, a excepción de que la no conformidad se deba a que la compilación en JENKINS falla, será posible seguir con el despliegue del código.

La verificación que hace la OCA del código y la PL están relacionadas y tienen un vínculo común, la entrega, de forma que para una entrega sólo es válida una SVE y una PL, a menos que la PL se cancelara y no llegara a ejecutarse.

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), el proceso de gestión de lanzamientos se articula en JIRA con 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  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:
• Hay que solucionar una incidencia lo antes posible
• Hay que instalar lo antes posible para cumplir cronograma de la STIC
• Hay que instalar lo antes posible para cumplir necesidades impuestas por el SAS 

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) 

Descripción del flujo para PL y PL Hijas

Figura 1. Diagrama flujo PL.

Figura 2. Diagrama flujo PL Hija.

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

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

• Exista en JIRA una Versión de un proyecto de aplicación en estado "En resolución".
• Exista en JIRA una SVE asociada a una versión en estado Cerrado con resolución "Conforme", "No conforme" o "No aplica".
  • Si se crea como PLU no es necesaria que la SVE esté Cerrada, ni tan siquiera que exista. Ver subflujo PLU.

Crear PL

El solicitante, ya sea el proveedor o el responsable del producto, realiza logon en JIRA y crea una nueva entidad PL sobre el proyecto aplicación necesario.

Debe informar obligatoriamente:

• ID versión relacionada. Es la versión sobre la que se está solicitando una implantación. La versión debe estar en estado "EN RESOLUCIÓN".
• SVE de la versión. La SVE es la verificación de la entrega que realiza la OCA. Su resolución podrá ser Conforme, no Conforme, o No aplica. Con esas tres resoluciones se podrá abrir una PL. 
• Corte de servicio. Elegir entre SI/NO.
• Aportar el documento PID.

Estado PDTE. REVISIÓN 

El proveedor de sistemas revisa el PID, pudiendo:

• Solicitar información, al solicitante si tiene dudas.
• No aceptar la documentación, teniendo que aportar el solicitante un nuevo PID.
• Aceptar si la documentación está revisada y correcta.

Al finalizar la revisión de la documentación la PL estará en estado PLANIFICABLE que indica al solicitante que se ha finalizado el ciclo de lectura de documentación y ya ha sido aprobada.

Estado PLANIFICABLE

Estado asignado al grupo planificador 

Acción EDITAR

El solicitante podrá cambiar a PLU. Ver subflujo PLU

Acción SOLICITAR INFORMACIÓN

El proveedor sistemas podrá pedir aclaraciones de documentación al solicitante una vez haya finalizado la revisión de la documentación. De hacerse se activará el atributo de aclaración de dudas tras la revisión.

Acción SOLICITAR PLs Hijas

Tanto el Responsable de Producto como el Proveedor deben Solicitar Implantación.

Dicha acción está disponible mientras la PL está en:

• PDTE. REVISIÓN: el proveedor de sistemas está revisando la documentación.
• PLANIFICABLE: el proveedor de sistemas ha finalizado la revisión de la documentación.
• EN RESOLUCIÓN: ya se ha creado al menos una PL HIJA. 

Al solicitar implantación se debe indicar obligatoriamente:

• PL Hija urgente. Ver subflujo PLU
• Plataforma. Por defecto será la plataforma de la aplicación. Podrá seleccionar una o varias.
• Entorno. Podrá seleccionar varios.
• Restricción horaria.

Cuando se solicita una implantación se actualiza el atributo "Solicitada Implantación" = SI.

Acción GENERAR PLs hijas

El grupo de lanzamientos podrá ir generando las ejecuciones a medida que se lo soliciten o de manera proactiva.

Dicha acción está disponible mientras la PL está en:

• PLANIFICABLE: el proveedor de sistemas ha finalizado la revisión de la documentación.
• EN RESOLUCIÓN: ya se ha creado al menos una PL HIJA. 

Al generar ejecución se debe indicar obligatoriamente:

• Plataforma. Por defecto será la plataforma de la aplicación. Podrá seleccionar una o varias.
• Entorno. Podrá seleccionar varios.
• Grupo Lógico
  
  • Se debe indicar si se quiere una única PL Hija con 1 o n-Grupos Lógicos o una PL hija por cada GL indicado.

Y opcionalmente, se podrá seleccionar si se requiere Agrupación de plataforma.

Al Generar PLs hijas la PL estará en estado EN RESOLUCIÓN y la PL Hija en estado PLANIFICABLE.

Estado EN RESOLUCIÓN

Estado asignado al informador y que indica al solicitante que ya existen PL Hijas.

PL HIJA

Estado PLANIFICABLE

Al generarse la PL Hija está en estado PLANIFICABLE.

El Grupo de Lanzamientos Solicita Planificación al proveedor de sistemas.

Estado PDTE. CALENDARIZAR

El proveedor de sistemas recibe la solicitud de planificación del Grupo de Lanzamientos y propone una fecha de inicio estimada y una fecha fin estimada.

Estado CALENDARIZADA

El Grupo de Lanzamientos debe Aprobar o No Aprobar fechas. En caso de No Aprobar volverá a Pdte. Calendarizar.

Estado PDTE. COMENZAR RESOLUCIÓN

Una vez la fecha está aprobada, la PL HIJA quedará pendiente de iniciar la resolución.

Estado EN RESOLUCIÓN

El proveedor de sistemas comienza la resolución, realizando las actividades programadas en la documentación.

Al finalizar la resolución debe informar si se han producido errores y los comentarios que considere necesario.

Estado PDTE. REVISIÓN TÉCNICA

El solicitante debe revisar la ejecución y aceptar o no aceptar la solución técnica.

• Si acepta la solución técnica, la PL HIJA pasa a Estado CERRADA con resolución RESUELTA.
• Si no acepta solución técnica se pregunta al solicitante si quiere, reinstalación con o sin marcha atrás, si quiere desinstalar o si no quiere hacer nada.
  • Si se requiere reinstalación o desinstalación la PL Hija pasará a estado PDTE. CALENDARIZAR y de ahí a PDTE. COMENZAR RESOLUCIÓN, es decir, no hay intervención del grupo de lanzamientos.
  • Si no se requiere ni reinstalación ni desinstalación, la PL Hija se cerrará y cerrará automáticamente todas las PL Hijas de la PL (PL Hijas 'hermanas').

Al finalizar cada ejecución se graba en una tabla visible los siguientes datos:

• Tipo de actividad: Instalación, Reinstalación, Marcha atrás, Desinstalación.
• Entorno: Entorno en el que se ha ejecutado la PL Hija.
• Fecha inicio: Fecha inicio real de la ejecución de la PL Hija.
• Fecha fin: Fecha fin real de la ejecución de la PL Hija.
• Complejidad: Complejidad de la PL Hija. Por defecto siempre es NO.
• Facturable: por defecto Facturable es Instalación y Desinstalación.
• PLU: Informa si la ejecución ha sido solicitada como Urgente.
• HBS: Valor de cada ejecución en función de los parámetros establecidos Prioridad (PLU), Complejidad, Horario.

Acción EDITAR

• El proveedor sistemas:
  • Podrá solicitar una revisión de la fecha de inicio estimada siempre y cuando esta fecha no haya llegado.
  • Podrá cambiar los Grupos Lógicos si no ha comenzado la resolución.
• El solicitante podrá:
  • Cambiar una PL Hija a Urgente. Ver subflujo PLU

Acción SOLICITAR REVISIÓN

El proveedor sistemas dispondrá durante todos los estados de la PL Hija y hasta 10 días después de finalizar el mes, la acción Solicitar Revisión.  Con esta acción podrá solicitar al grupo de lanzamiento que se revisen los parámetros de Complejidad y/o facturación.  

Al solicitar revisión, se activará el atributo "Revisión solicitada".

Acción EDITAR EJECUCIONES

El Grupo de Lanzamientos dispondrá de una acción para actualizar la tabla de ejecuciones si el proveedor sistemas así se lo ha solicitado. Los cambios quedarán registrados en el histórico de cambios.

Acción FINALIZAR PL

La PL se finaliza de manera manual por el solicitante, y sólo se podrá realizar si todas las PLs Hijas han sido finalizadas.

Subflujo CANCELACIÓN 

Una PL podrá ser cancelada en cualquier estado de la PL por el solicitante siempre y cuando:

• No tenga PL hijas.
• De tener PL Hijas estas se encuentren Cerradas con cualquier resolución.
  • Las PL Hijas se pueden cancelar en cualquier estado previo a EN RESOLUCIÓN.

Subflujo PLU

1) Una PL se puede crear con prioridad alta (urgente)

• No es necesario que esté creada o finalizado la SVE correspondiente (sin embargo no se podrá cerrar la PL hasta que la SVE exista).
• Al crearla como PLU, el solicitante deberá completar obligatoriamente:
  • Plataforma. Por defecto aparecerá la plataforma asociada a la aplicación. Podrá solicitar otra plataforma si lo desea. Pero sólo se podrá seleccionar una.
  • Entorno. Sólo se puede seleccionar uno.
  • Motivo. Debe elegir motivos de un desplegable.
  • Información adicional. Debe informar nombre y teléfono de contacto.

Al finalizar la creación, el campo PLU estará informado a SI en la PL y se generará automáticamente una PL Hija para la Plataforma - Entorno - y todos los grupos lógicos. La PL Hija:

• • Estará identificada como PLU.
  • Se creará en estado PDTE. CALENDARIZAR, y una ver el proveedor sistemas la calendarice pasará automáticamente a PDTE. COMENZAR RESOLUCIÓN.

2) Una PL creada con prioridad normal se le podrá aumentar la prioridad, para ello

• Mientras se está revisando la documentación, el solicitante dispone de la acción EDITAR en la que podrá seleccionar PLU, informando todos los atributos anteriormente descritos.
• Si ya se ha revisado la documentación y está en estado PLANIFICABLE o bien EN RESOLUCIÓN, podrá Solicitar una Implantación Urgente informando todos los atributos anteriormente descritos.

3) Una PL Hija podrá ser PLU si:

• Se ha solicitado desde la PL.
• Mediante la acción editar el solicitante cambia el valor a PLU = SI.

Aspectos a tener en cuenta:

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