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 de incremento versión 

Roles

...

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

Requisitos para el ciclo de vida de la PL incremento versión:

• La gestión de cambios debe siempre hacerse en una aplicación.
• Debe determinarse claramente la entrega que se quiere implantar.
• La entrega debe constar de 4 dígitos, los tres primeros vienen dados por el código de la versión que incluye los evolutivos y correctivos. La versión debe estar en estado En resolución.
• El código debe entregarse en el GITLAB siguiendo la normativa del área de Gobernanza.
• El proveedor debe realizar el PID (Procedimineto de instalación y desinstalación)
• Es requisito imprescindible para crear una PL que la OCA haya hecho la verificación del código a entregar, que se modelará en otra entidad, el Servicio de Verificación de Entrega (SVE).
• Para el caso de las PLUs, NO será necesario que previamente haya una SVE.
• El peticionario siempre debe solicitar la implantación en uno o varios entornos y en una o varias plataformas. No es obligatorio que indique los grupos lógicos.

...

Diagrama de flujo

Diagrama de estado

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.

...

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 (SVE) 

Ver en servicios OCA.

...

En el siguiente enlace, puedes consultar el manual del JIRA , herramienta en la que se ha modelado este proceso.

...

Tras estos pasos, la PL se habrá creado y pasará a un estado en el que el proveedor de sistemas (CTI) deberá revisar la documentación aportada (sobre todo para asegurarse de que las plataformas y los entornos solicitados son a los que se hace referencia en el PID).

Estados PL padre

Estado PDTE. REVISIÓN 

El proveedor de sistemas revisa el PID, pudiendo:

...

• Cambiar la PL a PLU, lo que supondrá una variación en el límite de tiempo que tiene CTI para leer y aprobar la documentación. En el cambio a PLU  se generará automáticamente una PL hija sólo para un entorno y para todos los grupos lógicos.
• Solicitar PLs hijas, que serán generadas por el Grupo Planificador una vez que CTI haya revisado y aprobado el PID. Para la solicitud de hijas, debe indicarse de forma obligatoria la o las plataformas, el entorno o los entornos y la restricción horaria en la que se quiere hacer la implantación. Existe igualmente la posibilidad de solicitar la PL Hija como PLU.

Estado NO ACEPTADA

el solicitante debe adjuntar un nuevo PID.

Estado PDTE. INFORMACIÓN

CTI puede solicitar información desde cualquier estado y el solicitante debe completar esa información.

Estado PLANIFICABLE

Si el peticionario aún no ha solicitado PLs hijas, puede hacerlo en este estado tantas veces como desee.
En el momento en el que se hayan solicitado PLs hijas, el Grupo Planificador procederá a crearlas, para ello:

...

El hecho de generar PLs hijas hace que la PL cambie a estado EN RESOLUCIÓN. 
El peticionario puede en cualquier momento cambiar la urgencia de la PL pasándola a PLU, lo que conllevará la creación automática de la PL Hija si no estuviera creada ya. En el caso de que ya existiera, podría cambiar la urgencia de la PL Hija.

Estado EN RESOLUCIÓN

Estado asignado al informador y que indica al solicitante que ya existen PL hijas. Al igual que en el estado anterior, el peticionario puede solicitar PLs hijas tantas veces como desee (tanto normales como PLU), y el Grupo Planificador podrá generar las PLs hijas.

...

• Resuelta si todas las PLs hijas están resueltas.
• Parcialmente resuelta si alguna PL hija está resuelta y alguna cancelada.
• Cancelada si todas las PLs hijas están canceladas.

Ciclo de vida de la versión al finalizar la PL

Partíamos de versiones En resolución para poder generar PLs.

...

PL hija (PLH)

Como hemos adelantado, las PLs hijas se crean de dos formas:

...

Los estados por los que pasa la PL hija por tanto son:

Estado PLANIFICABLE

Al generarse la PL hija está en estado PLANIFICABLE si se ha solicitado una PL hija no urgente.

El Grupo Planificador solicita planificación a CTI indicándole una fecha en base a la restricción horaria del peticionario.

Estado PDTE. CALENDARIZAR

CTI 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 Planificador  debe aprobar o no aprobar las fechas que propone.  En caso de no estar conforme con las fechas, CTI deberá volver a planificar.

Estado PDTE. COMENZAR RESOLUCIÓN

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

...

Hasta este estado, el peticionario podrá cambiar la urgencia de la PL.

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 peticionario debe revisar la ejecución y aceptar o no aceptar la solución técnica.

...

El Grupo Planificador 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.

Cambio en la urgencia de la PL

Como ya hemos comentado, el peticionario puede en cualquier momento cambiar la urgencia de la PL y de la PL hija (hasta el estado EN RESOLUCIÓN).

• Cambiar la urgencia de la PL tiene como repercusiones:
  • Si está en estado PDTE. REVISIÓN, el tiempo de lectura de la documentación variará. Si ya ha pasado de ese estado, en la PL no hay repercusión.
  • Se creará una PL hija automáticamente si es que se cambia a PLU. Si el cambio es al contrario, la PL hija pasará a un estado en el que intervenga el Grupo Planificador.

...

• • Si el cambio es de PLU a PL:
    • Si está en estado PDTE. CALENDARIZAR à pasa a estado PLANIFICABLE.
    • Si está en estado PDTE. COMENZAR RESOLUCIÓN pasa a estado PLANIFICABLE

PL de modificación/configuración de software base (PL sistemas)

Roles 

El Responsable de sistemas podrá ejecutar las mismas acciones que cualquier usuario que tenga rol JP sistemas.

Requisitos para el ciclo de vida de la PL sistemas

• La gestión de cambios debe siempre hacerse en una plataforma.
• Es opcional relacionar la PL con la RFP de la plataforma sobre la que se hace el lanzamiento.
• El peticionario debe indicar el o los entornos y los grupos lógicos, así como pedir si quiere ejecuciones para todos los grupos lógicos o por cada uno de los grupos lógicos solicitadas.

Diagrama de flujo

Diagrama de estado

En el siguiente enlace puedes consultar el manual de JIRA, donde se ha modelado este proceso.

...

• PL:  es la contenedora del alcance de la PL, donde se podrán generar implantaciones que no se hayan solicitad en la creación.
• PL hija (PLH): una subtarea de la PL por cada instalación en una Plataforma, entorno, grupo lógico o conjunto de grupos lógicos. Estas subtareas se crean de manera automática al crear la PL sistemas padre.
  
  

Estado EN RESOLUCIÓN

En este estado pasan a poder ejecutarse las PLs hijas creadas de manera automática con la creación de la PL. En este estado es posible generar PLs hijas que no correspondan a las creadas con los datos solicitados en la creación de la PL. Es posible generar hijas con la misma tripleta que ya se hubiera solicitado anteriormente.

...

• Resuelta si todas las PLs hijas están resueltas.
• Parcialmente resuelta si alguna PL hija está resuelta y alguna cancelada.
• Cancelada si todas las PLs hijas están canceladas.

PL hija sistemas (PLH sistemas)

Las PLs hijas se crean de dos formas:

...

Los estados por los que pasa la PL hija por tanto son:

Estado PDTE. CALENDARIZAR

CTI  propone una fecha de inicio estimada y una fecha fin estimada.

Estado CALENDARIZADA

El Grupo Planificador debe aprobar o no aprobar las fechas que propone.  En caso de no estar conforme con las fechas, CTI deberá volver a planificar.

Estado PDTE. COMENZAR RESOLUCIÓN

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

En este estado, el proveedor sistemas podrá cambiar tanto la fecha de inicio estimada como los grupos lógicos.

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.

Video formación PLs

En el espacio de Ayuda Jira/Confluence podrás ver un video explicativo del proceso de gestión de lanzamientos.

...