Extracto

Divbox

class	estiloindice

Expandir

title	Índice

Tabla de contenidos

exclude
outline	true
absoluteUrl	true

Proceso

Ayuda relacionada:.*

PL hija (PLH)

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

Generadas por el Grupo Planificador en función de las solicitadas por el peticionario.

En este caso, las Pls hijas se crean en estado Planificable, con idea de que el Grupo Planificador proponga una fecha y que en base a la misma CTI la planifique. Esa fecha de planificación deberá ser validada por el Grupo Planificador.

Generadas automáticamente si se ha solicitado por parte del peticionario una PLU. En este caso, se genera sólo una PL hija (correspondiente a una plataforma, entorno y para todos los grupos lógicos) en un estado en el que CTI planifica y pasa a ejecutar.

Si una PL hija se transforma en una PLU, transicionará automáticamente de estados anteriores al estado en el que CTI planifica, no necesitando aprobación por parte del Grupo Planificador de esa planificación.

Estas transiciones automáticas se harán también en el caso de una PLU que esté pendiente de planificación y que pase a ser normal. En este caso, pasará al estado en el que el Grupo Planificador proponga fechas.

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. Hay que tener en cuenta lo siguiente (esto es de aplicación no sólo a PLs de versión, también a las de datos y de configuración):

Divbox

class	divcontenedor

Extracto

Proceso:

Divbox

style	width: 92%; text-align: left;
class	divcontenido

Image Added Proceso:

excerpt

Titulo pagina

Objetivo

Dar respuesta a las solicitudes de servicios de transición de instalaciones software como consecuencia del desarrollo y evolución de sistemas de información, que llegarán al adjudicatario en forma de peticiones de lanzamiento (PL).

Asegurar que los cambios registrados se prioricen, planifiquen, prueben e implementen, documenten y revisen de manera controlada.

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

Rol	Descripción
Peticionario (*)	Rol solicitante de la PL. Puede ser tanto el Responsable de Producto como el Proveedor (de desarrollo)
Responsable de producto (**)	Rol responsable de la aplicación sobre la que se solicita una PL.
Responsable sistemas (**)	Rol responsable del área de sistemas de la aplicación. Coincide con el responsable de la plataforma en la que se ubica la aplicación
Responsable funcional (***)	Rol responsable funcional de la aplicación sobre la que se solicita una PL.
Grupo planificador	Rol responsable de la correcta gestión y planificación por parte del resolutor
Resolutor	Rol que ejecuta y resuelve la PL. Es el proveedor de sistemas (CTI)
Oficina Técnica de Calidad (OCA)	Rol responsable de la verificación del código entregado por el Proveedor
Oficina Técnica de Interoperabilidad	Rol responsable de verificar en algunos casos información necesaria para los despliegues

(*) Solicitante puede ser tanto el Responsable de producto como cualquier usuario que tenga rol de Jefe de proyecto del área de proyectos, mientras que sólo podrá ser el proveedor de la aplicación sobre la que se requiere el despliegue.

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

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.
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.
La PL se creará en estado ABIERTA Y tendrá enlazada una página de CONFLUENCE con la plantilla del PID. El Proveedor deberá completarla editando la página. Cuando la haya completado accederá en la PL a la acción COMENZAR lo que implicará que a la página del PID le desaparezcan los permisos de edición.|
El Proveedor de Sistemas puede no aceptar la documentación, con lo que será necesario modificar el PÌD (volverá a tener permisos de edición) hasta que se indique que se ha completado la información, momento en el que volverá a estar bajo revisión del Proveedor de Sistemas. Si el Proveedor de Sistemas solicita información, el PID no se tendrá que modificar.
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.
Siempre va a ser necesario solicitar PLs Hijas para que sean creadas por el Grupo Planificador tanto si se trata de una Pl normal como en el caso de una PLU. Ahora bien, en el caso de que se trate de una PLU, las hija se crearán automáticamente sin tener en cuenta los grupos lógicos. El Proveedor de sistemas podrá informar esos grupos lógicos para poder ejecutar las PLs Hijas.
Sólo podrá crearse una PL por entrega a menos que la primera PL se cancele. En ese caso, se podrá crear otra PL usando la misma SVE.
Cuando se finaliza la PL hay que decidir si va a ser necesario continuar con las implantaciones en esa versión, pero hay que tener en cuenta que tendrá que variar la entrega, por lo que será necesaria otra SVE.
En el caso en que la OTI deba indicar información necesaria para los despliegues, se actuará de la siguiente forma:
- Si se trata de una PL normal, el Proveedor de Desarrollo debe incluir en un comentario una tabla con tres columnas, las dos primeras obligatorias y la última opcional con los siguientes datos:
  - - Nombre del parámetro en el Procedimiento de Instalación y Desinstalación (PID).
    - Identificador del servicio
    - Descripción funcional: Indicar con un mensaje una breve descripción del servicio que debe machear con el identificador del servicio. Para los “servicios rest” sería adecuado poner además la URL a la API facilitada en tiempo de desarrollo
      Cuando se creen las Peticiones de Lanzamiento hijas, el Responsable de producto o el Proveedor de Desarrollo deberá mencionar a la Oficina de Interoperabilidad en las que ésta tenga que indicar la URL. La información deberá estar solicitada como mínimo el día antes de la ejecución.
      Para mencionar al grupo en un comentario bastará con acceder a “+” y seleccionar “oficina-interoperabilidad”
      
      Image Modified
      Con esta mención llegará un correo electrónico con ese comentario a todos sus integrantes. La Oficina de Interoperabilidad indicará en un comentario la URL solicitada.
- Si se trata de una PLU, el Proveedor de Desarrollo se pondrá en contacto con la Oficina de Interoperabilidad en el teléfono 605 783 118, y además indicará en un comentario en la Petición de Lanzamiento padre:
  El Proveedor de Sistemas tendrá que tener en cuenta estos comentarios a la hora de ejecutar la Petición de Lanzamiento.

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.

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 Área de Sistemas únicamente despliega el código que se encuentre en la Digital Media Library (DML). La mayoría de aplicaciones hace la entrega en el Gestor de Control de Versiones (GIT), a través del cuál y de manera automatizada, Jenkins lo compila y deposita en la DML. Eso ocurre siempre que la compilación o empaquetado no lo haga el proveedor. Si además en la entrega hay otra serie de archivos como archivos de texto, se deberá hacer una petición a la Oficina de Calidad para que todo pueda entregarse en el GIT (petición para "configurar job de JENKINS").
Por otro lado, existe un grupo de aplicaciones en las que el proveedor es quien realiza la tarea de compilar o empaquetar, y para ello utiliza otro procedimiento. Hasta ahora, el proveedor adjuntaba el código en FARO, o directamente en JIRA en la propia PL. Ahora, el proveedor del software entrega el código fuente en GIT pero además dispone en JIRA de un registro denominado Entrega de Binarios que automáticamente deposita el código en la DML. En estos casos se deberá crear petición a la Oficina de Calidad para "configurar job para entrega de binarios".

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.

Advertencia

En el PID (Procedimiento de Instalación y Desinstalación) siempre habrá que indicar la ruta relativa de la DML que siempre coincidirá con la de GIT. En el caso de que no haya entrega de código fuente, la ruta será la indicada en el registro de entrega de binarios.

La entrega de binarios no siempre conlleva entrega en GIT. Es posible que sólo sea necesario hacer la entrega de binarios, con lo que si no existe el job para el proyecto hay que hacer la petición correspondiente.

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 (PLH): 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 de hasta 72h y podría ejecutarse en menos de 24h en función de a qué hora del día se solicite..
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

En el caso de que una PL se cree como urgente, no será necesario esperar a que la OCA acabe de ejecutar el servicio de verificación de la entrega:

Si la PLU se crea una vez que ya se haya creado la SVE, se permitirá que la PL progrese paralelamente a la verificación de la OCA.

Si la PLU se crea antes de existir la SVE, ésta se creará de manera automática para que sea revisada por la OCA en el momento en el que se ejecute la primera PL hija.

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.

Para que el solicitante pueda crear y seguir un flujo de PL de Incremento de versión en un proyecto de tipo aplicación, es necesario que:

Exista en JIRA una Versión de ese 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" en la que se ha especificado la entrega.
- Si se crea como PLU no es necesaria que la SVE esté Cerrada, ni tan siquiera que exista. Como se ha comentado antes, si la SVE no existiera, se crearía de forma automática al cerrase la primera PL hija. En el caso de que existiera, no es condición necesaria que la SVE esté cerrada que se pueda avanzar con la PL.

El solicitante, ya sea el proveedor o el responsable del producto, crea el tipo de entidad "PL versión" sobre el proyecto de tipo aplicación correspondiente.

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. Al seleccionar la SVE se informará la entrega que se quiere implantar y que corresponderá al código subido al GITLAB.
Plataforma o plataformas en la que se quiere hacer la instalación. Es posible que, sobre todo si es la primera instalación de la aplicación, no aparezca la plataforma "preseleccionada" puesto que aún en CMS no existe la relación entre la aplicación y la plataforma. En este caso, existe la opción de seleccionar otra plataforma, con lo que aparecerán todas las plataformas disponibles.
Entorno o entornos en los que se quiere hacer la implantación.
Si hay o no corte de servicio.

Tras estos pasos, la PL se habrá creado en estado ABIERTA y se habrá creado un enlace con una página de CONFLUENCE (en la página de la plataforma en la que se crea la PL) para que se complete el PID. Una vez completado, será necesario acceder a COMENZAR, momento en el que desaparecen los permisos de edición en el PID y en el que la PL 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 ABIERTA

El proveedor deberá completar el PID en la página de CONFLUENCE enlazada. Aparecen dos páginas enlazadas, una para el PID en sí y la otra la página de la PL que la contiene y donde puede aparecer otra información importante de la PL. Esta página se crea en la página de la plataforma en la que se solicita la PL aunque tiene un enlace a la página de la versión para la que se crea la PL.

Una vez que se ha completado el PID, el proveedor o el Responsable de producto deberán comenzar la PL, lo que implicará que al PID se le quitan los permisos de edición para todo el mundo.

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, es decir, volverá a tener permisos de edición.
Aceptar si la documentación está revisada y correcta.

Advertencia
Recuerda siempre que en el PID deben darse instrucciones concretas al proveedor de sistemas (ni omprobaciones ni notas).

Info
hay una serie de motivos por los que sistemáticamnete se rechaza el PID, lo que conlleva a qeu la PL pase a estado NO ACEPTADA y que haya que rehacerlo. Puedes ver los principales motivos de rechazo accediendo aquí.

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. En este estado, y aunque CTI esté leyendo la documentación, el peticionario de la PL va a poder:

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 Proveedor o el Responsable de producto deben editar de nuevo el PID, de manera que al completar la información ese permiso de edición de nuevo desaparezca.

Puedes ver aquí los motivos de rechazo del proveedor de sistemas.

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:

Debe indicar obligatoriamente el o los entornos, la o las plataformas, los grupos lógicos (eligiendo si quiere una PL Hija para todos los grupos lógicos o bien una por cada uno de ellos) y opcionalmente las agrupaciones de plataformas.

Por cada tripleta (entorno-plataforma-grupo lógico) se creará una PL Hija en estado Planificable.

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.

Una vez que el Responsable de Producto considera que ya no debe haber más implantaciones, podrá finalizar la PL tanto él como el Proveedor para lo cual es imprescindible que todas las PLs hijas estén cerradas.

Ahora bien, dependiendo de cómo se hayan cerrado las hijas se cerrará la padre. Estos cierres se controlan con el campo Resolución que aparece debajo del estado.

Hay tres posibles resoluciones para una PL cerrada en una versión:

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.

A la hora de finalizar a PL, Responsable de producto/Proveedor podrán determinar si es necesaria o no implantar una nueva entrega para esa versión, con lo que será necesaria para la misma una nueva SVE y una nueva PL con implantaciones. En ese caso, la PL primera se cerrará con resolución Parcialmente resuelta.

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

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

Una vez que la PL está cerrada, el Responsable de producto puede finalizar las implantaciones, pasando la versión de En resolución a Implantada, lo que hará que las mejoras e incidencias pasen de estado En versión a Cerradas.

Una vez que la versión esté en estado Implantada, el Responsable de producto puede cerrar la versión siempre que las OTs estén cerradas.

En la siguiente tabla se contemplan los posibles estados de la versión una vez que está En resolución

Estado versión

Acción

Condiciones

Validación

Mensaje

Estado final

EN RESOLUCIÓN

Finalizar (y no sale Finalizar Implantaciones)

Si y sólo si NO HAY SVEs ni PLs relacionadas con la versión

Deben estar las Ots cerradas

La versión se va a finalizar sin haber generado PLs

La versión pasa a estado CERRADA, resolución Cerrada y mejoras, incidencias y no conformidades pasan a CERRADA

EN RESOLUCIÓN

Finalizar implantaciones (y no sale Finalizar)

Si y sólo si HAY PLs relacionadas con la versión

Deben estar las PLs cerradas

Comprueba que las PLs están cerradas

La versión pasa a estado IMPLANTADA y mejoras, incidencias y no conformidades pasan a CERRADA

IMPLANTADA

Finalizar

Si y sólo si HAY PLs relacionadas con la versión

Deben estar las Ots cerradas

Comprueba que las OTs están cerradas

La versión pasa a estado CERRADA, resolución Cerrada

EN RESOLUCIÓN

Cancelar

Siempre (motivo obligatorio)

Si sólo hay SVEs→deben estar cerradas

Si hay PLs →deben estar cerradas con resolución Cancelada

Comprueba que las entidades relacionadas están cerradas

La versión pasa a estado CERRADA, resolución cancelada y mejoras, incidencias y no conformidades pasan a BACKLOG

IMPLANTADA

Cancelar

NO ES POSIBLE

Ancla

planifica

Advertencia
PL hija para la instalación en el entorno de PREPRODUCCIÓN: el plazo de planificación desde que se realiza la Solicitud de PL hija es de 48h a 72h. PL hija para la instalación en el entorno de PRODUCCIÓN: el plazo de planificación desde que se realiza la Solicitud de PL hija es de 48h.

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.

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

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 PARALIZADA

El proveedor de sistemas puede paralizar la ejecución de la PL porque puede haber un motivo de bloqueo de la misma. Una vez se haya eliminado ese motivo, volverá a pasarla a EN RESOLUCIÓN

Estado PDTE. REVISIÓN TÉCNICA

El peticionario 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. Al cerrase la PL hija, se producirá el cambio de versión en CMS en la tripleta (plataforma-entorno-grupo lógico) correspondiente.
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') y la resolución de todas ellas será "No se hará"

ReinstalaciónMarcha AtrásDesinstalaciónSISISINONOSINONO

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.

El proveedor de 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 Planificador que se revisen los parámetros de Complejidad y/o facturación.

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.

Puedes ver un resumen del proceso accediendo aquí.

PLs no ejecutadas por CTI

Lo normal es que el proveedor que hace los despliegues sea CTI, pero hay ciertas plataformas en las que , si bien su administración corresponde a CTI, los despliegues en las mismas se hacen a cargo de los propios proveedores de desarrollo. En estos casos no interviene el Grupo Planificador, siendo el proveedor de sistemas de la plataforma quien ejecuta todas las acciones.

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

Advertencia

Es imprescindible que, hasta que no finalice la compilación del código, no se marque como Urgente una PL. Si se hace, existe un alto riesgo de que se atienda antes de que haya terminado la compilación, y en ese caso quede rechazada porque en el momento de atenderla no haya aún un paquete instalable.

Por tanto, es importante para el correcto desarrollo de los proyectos, el marcar la PLU en el momento adecuado, entendiendo que la U no significa importante, sino Urgente (para acometer cuanto antes).

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.

Cambiar la urgencia de la PL hija tiene repercusiones:
- Si el cambio es a PLU:
  - Si está en estado PLANIFICABLE pasa a estado PDTE. CALENDARIZAR y se suprime el estado CALENDARIZADA.
  - Si está en estado CALENDARIZADA pasa a estado PDTE.COMENZAR RESOLUCIÓN, pudiéndose variar la fecha de inicio estimada.
  - Si está en estado PDTE. COMENZAR RESOLUCIÓN no hay cambio de estado pero se puede variar la fecha de inicio estimada.

- 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

Resumen del proceso de implantaciones

PL de datos

PL de configuración

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

Roles

Rol

Descripción

Peticionario

Rol solicitante de la PL, en este caso el proveedor de sistemas (CTI)

Responsable sistemasRol responsable de la plataforma en la que se hace la modificación o el cambio de configuraciónGrupo planificadorRol responsable de la correcta gestión y planificación por parte del resolutorResolutorRol que ejecuta y resuelve la PL. Es el proveedor de sistemas (CTI)

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.

El solicitante, crea el tipo de entidad "PL sistemas" sobre el proyecto de tipo plataforma correspondiente.

Debe informar de forma obligatoria:

Tipo PL sistemas:

Con aprobación horaria por parte de la STIC.

Sin aprobación horaria por parte de la STIC.

Clasificación PL: dependiendo de la clasificación que se escoja deberán adjuntar un tipo de PID u otro.

Si el tipo PL es con aprobación horaria por parte de la STIC:

Normal
Alta/Baja/Modificación de regla de firewall

Si el tipo es sin aprobación horaria por parte de la STIC:

Alta/Baja/Modificación de recursos físicos
Publicación de icono en plataforma Citrix
Asignación/Liberación de volúmenes en cabinas de disco
Alta/Baja/Modificación de zonas/alias en SAN de los CTIs
Alta/Baja/Modificación una granja en balanceador
Alta/Baja/Modificación/Propagación de VLANs en equipos de conmutación
Alta/Baja/Modificación de registro en DNS corporativo/externo
Alta/Baja/Modificación de configuraciones de ámbitos en NGINX
Alta/Baja/Modificación publicación de acceso externo en PROXY-INVERSO de CTI

ID RFP relacionada: (opcional) RFP de la plataforma que estén en estado "EN RESOLUCIÓN" o "CERRADA".

Plataforma: vendrá ya dada por el proyecto.

Entorno o entornos en los que se quiere hacer la implantación.

Grupo o grupos lógicos en los que se quiere hacer la implantación. Además, será necesario saber si el peticionario quiere una implantación para todos los grupos lógicos seleccionados o una por cada uno de ellos.

Restricción horaria: (opcional)

Si hay o no corte de servicio.

Miembro asignado: (opcional) se podrá indicar miembros de CTI, tanto coordinadores como grupos por tecnologías, para identificarlos.

Aportar el documento PID como adjunto.

Tras estos pasos, la PL se habrá creado y pasará a un estado en el que el proveedor de sistemas (CTI) resolverá.

Al igual que para la PL de incremento versión, este proceso se modela con dos tipos de entidades:

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.

Si todas las Pls hijas están cerradas y no es necesario generar ninguna más, el peticionario puede finalizar la PL.

Hay tres posibles resoluciones para cerrar la PL:

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:

De forma automática cuando se solicita la PL
Mediante la acción de generar PLs hijas estando en resolución.

El ciclo de vida de las PLs hijas va a depender del tipo de la PL:

Si la PL es de tipo 'sin aprobación horaria por parte de la STIC', las PLs hijas son planificadas por CTI y se ejecutan directamente, sin necesidad de aprobación por parte del Grupo Planificador.
Si la PL es de tipo 'con aprobación horaria por parte de la STIC', las PLs hijas son planificadas por CTI, y esa planificación debe ser aprobada por el Grupo Planificador. Cuando las fechas hayan sido aprobadas, las PLs hijas podrán ejecutarse directamente.

En cualquier caso, cuando se ejecuta la PL hija NO hay revisión de la ejecución, pasando directamente al estado CERRADA.

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.

Vídeo formación PLs

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

Ver vídeos

Lucidchart

lcId	a0927943-5729-46ac-85ad-6d4a6f41b5f3
rich-viewer	true
autoUpdate	true
autofit	false
name	Diagrama PL version - C.GTE6Wt_75d
width	1568
convertedFrom	onprem
origParams	eyIiOiIiLCJhdXRvVXBkYXRlIjoidHJ1ZSIsInNpemUiOiI2MDAiLCJzaW1wbGVWaWV3ZXIiOiJ0 cnVlIiwiYXR0YWNobWVudElkIjoiNTAwODUwNTkiLCJ2ZXJzaW9uIjoiNjUifQ==
documentToken	v2_52b312f93116148c3e54609d2214b93ccfd075b4fc362b3f8479e06fb8f4e59f-a=171816341&c=d1873183-daff-4cd4-a0ef-3f5bcb960f8c&d=4143aab9-e31b-4959-aa86-4269155879a0&p=
id	4143aab9-e31b-4959-aa86-4269155879a0
align	Left
height	826

draw.io Diagram

diagramName	Diagrama PL version (from Lucidchart).drawio
revision	1

Diagrama de estado

Lucidchart

lcId	eebc5f11-0013-4b5f-98c5-9afecbae6f6d
rich-viewer	true
autoUpdate	true
autofit	false
name	Estados PL version - peHTAxfOdT4s
width	1462
convertedFrom	onprem
origParams	eyIiOiIiLCJhdXRvVXBkYXRlIjoidHJ1ZSIsInNpemUiOiI2MDAiLCJzaW1wbGVWaWV3ZXIiOiJ0 cnVlIiwiYXR0YWNobWVudElkIjoiNTAwODU1NTciLCJ2ZXJzaW9uIjoiMzQifQ==
documentToken	v2_7420061067f423f58777d5ef5586382ddc68a1bb35243dfe73217b5a819d7880-a=171816341&c=d1873183-daff-4cd4-a0ef-3f5bcb960f8c&d=dbb0d4e7-9fe4-4ffb-9c97-b8f319723509&p=
id	dbb0d4e7-9fe4-4ffb-9c97-b8f319723509
align	Left
height	722

draw.io Diagram

diagramName	Estados PL version (from Lucidchart).drawio
revision	1

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 Área de Sistemas únicamente despliega el código que se encuentre en la Digital Media Library (DML). La mayoría de aplicaciones hace la entrega en el Gestor de Control de Versiones (GIT), a través del cuál y de manera automatizada, Jenkins lo compila y deposita en la DML. Eso ocurre siempre que la compilación o empaquetado no lo haga el proveedor. Si además en la entrega hay otra serie de archivos como archivos de texto, se deberá hacer una petición a la Oficina de Calidad para que todo pueda entregarse en el GIT (petición para "configurar job de JENKINS").
Por otro lado, existe un grupo de aplicaciones en las que el proveedor es quien realiza la tarea de compilar o empaquetar, y para ello utiliza otro procedimiento. Hasta ahora, el proveedor adjuntaba el código en FARO, o directamente en JIRA en la propia PL. Ahora, el proveedor del software entrega el código fuente en GIT pero además dispone en JIRA de un registro denominado Entrega de Binarios que automáticamente deposita el código en la DML. En estos casos se deberá crear petición a la Oficina de Calidad para "configurar job para entrega de binarios".

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.

Advertencia

En el PID (Procedimiento de Instalación y Desinstalación) siempre habrá que indicar la ruta relativa de la DML que siempre coincidirá con la de GIT. En el caso de que no haya entrega de código fuente, la ruta será la indicada en el registro de entrega de binarios.

La entrega de binarios no siempre conlleva entrega en GIT. Es posible que sólo sea necesario hacer la entrega de binarios, con lo que si no existe el job para el proyecto hay que hacer la petición correspondiente.

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 (PLH): 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 de hasta 72h y podría ejecutarse en menos de 24h en función de a qué hora del día se solicite..
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

En el caso de que una PL se cree como urgente, no será necesario esperar a que la OCA acabe de ejecutar el servicio de verificación de la entrega:

Si la PLU se crea una vez que ya se haya creado la SVE, se permitirá que la PL progrese paralelamente a la verificación de la OCA.
Si la PLU se crea antes de existir la SVE, ésta se creará de manera automática para que sea revisada por la OCA en el momento en el que se ejecute la primera PL hija.

Ancla

	contenedores
	contenedores

En el caso de tecnologías de contenedores, y hasta que no haya por parte de la Oficina de Arquitectura una normativa específica, se ha llegado a un acuerso entre el área de Sistemas e Infraestructura Centralizadas y el área de Soluciones Corportaivas y Sociedad Digital, con el beneplácito de la Oficina de Arquitectura.

Accede aquí si queires ver cómo hay que procedoe en el caso de tecnoclogía de contenedores.

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.

Para que el solicitante pueda crear y seguir un flujo de PL de Incremento de versión en un proyecto de tipo aplicación, es necesario que:

Exista en JIRA una Versión de ese 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" en la que se ha especificado la entrega.
- Si se crea como PLU no es necesaria que la SVE esté Cerrada, ni tan siquiera que exista. Como se ha comentado antes, si la SVE no existiera, se crearía de forma automática al cerrase la primera PL hija. En el caso de que existiera, no es condición necesaria que la SVE esté cerrada que se pueda avanzar con la PL.

El solicitante, ya sea el proveedor o el responsable del producto, crea el tipo de entidad "PL versión" sobre el proyecto de tipo aplicación correspondiente.

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. Al seleccionar la SVE se informará la entrega que se quiere implantar y que corresponderá al código subido al GITLAB.
Plataforma o plataformas en la que se quiere hacer la instalación. Es posible que, sobre todo si es la primera instalación de la aplicación, no aparezca la plataforma "preseleccionada" puesto que aún en CMS no existe la relación entre la aplicación y la plataforma. En este caso, existe la opción de seleccionar otra plataforma, con lo que aparecerán todas las plataformas disponibles.
Entorno o entornos en los que se quiere hacer la implantación.
Si hay o no corte de servicio.

Tras estos pasos, la PL se habrá creado en estado ABIERTA y se habrá creado un enlace con una página de CONFLUENCE (en la página de la plataforma en la que se crea la PL) para que se complete el PID. Una vez completado, será necesario acceder a COMENZAR, momento en el que desaparecen los permisos de edición en el PID y en el que la PL 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 ABIERTA

El proveedor deberá completar el PID en la página de CONFLUENCE enlazada. Aparecen dos páginas enlazadas, una para el PID en sí y la otra la página de la PL que la contiene y donde puede aparecer otra información importante de la PL. Esta página se crea en la página de la plataforma en la que se solicita la PL aunque tiene un enlace a la página de la versión para la que se crea la PL.

Una vez que se ha completado el PID, el proveedor o el Responsable de producto deberán comenzar la PL, lo que implicará que al PID se le quitan los permisos de edición para todo el mundo.

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, es decir, volverá a tener permisos de edición.
Aceptar si la documentación está revisada y correcta.

Advertencia
Recuerda siempre que en el PID deben darse instrucciones concretas al proveedor de sistemas (ni omprobaciones ni notas).

Info
hay una serie de motivos por los que sistemáticamnete se rechaza el PID, lo que conlleva a qeu la PL pase a estado NO ACEPTADA y que haya que rehacerlo. Puedes ver los principales motivos de rechazo accediendo aquí.

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. En este estado, y aunque CTI esté leyendo la documentación, el peticionario de la PL va a poder:

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 Proveedor o el Responsable de producto deben editar de nuevo el PID, de manera que al completar la información ese permiso de edición de nuevo desaparezca.

Puedes ver aquí los motivos de rechazo del proveedor de sistemas.

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:

Debe indicar obligatoriamente el o los entornos, la o las plataformas, los grupos lógicos (eligiendo si quiere una PL Hija para todos los grupos lógicos o bien una por cada uno de ellos) y opcionalmente las agrupaciones de plataformas.
Por cada tripleta (entorno-plataforma-grupo lógico) se creará una PL Hija en estado Planificable.

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.

Una vez que el Responsable de Producto considera que ya no debe haber más implantaciones, podrá finalizar la PL tanto él como el Proveedor para lo cual es imprescindible que todas las PLs hijas estén cerradas.

Ahora bien, dependiendo de cómo se hayan cerrado las hijas se cerrará la padre. Estos cierres se controlan con el campo Resolución que aparece debajo del estado.

Hay tres posibles resoluciones para una PL cerrada en una versión:

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.

A la hora de finalizar a PL, Responsable de producto/Proveedor podrán determinar si es necesaria o no implantar una nueva entrega para esa versión, con lo que será necesaria para la misma una nueva SVE y una nueva PL con implantaciones. En ese caso, la PL primera se cerrará con resolución Parcialmente resuelta.

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

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

Una vez que la PL está cerrada, el Responsable de producto puede finalizar las implantaciones, pasando la versión de En resolución a Implantada, lo que hará que las mejoras e incidencias pasen de estado En versión a Cerradas.

Una vez que la versión esté en estado Implantada, el Responsable de producto puede cerrar la versión siempre que las OTs estén cerradas.

En la siguiente tabla se contemplan los posibles estados de la versión una vez que está En resolución

Estado versión	Acción	Condiciones	Validación	Mensaje	Estado final
EN RESOLUCIÓN	Finalizar (y no sale Finalizar Implantaciones)	Si y sólo si NO HAY SVEs ni PLs relacionadas con la versión	Deben estar las Ots cerradas	La versión se va a finalizar sin haber generado PLs	La versión pasa a estado CERRADA, resolución Cerrada y mejoras, incidencias y no conformidades pasan a CERRADA
EN RESOLUCIÓN	Finalizar implantaciones (y no sale Finalizar)	Si y sólo si HAY PLs relacionadas con la versión	Deben estar las PLs cerradas	Comprueba que las PLs están cerradas	La versión pasa a estado IMPLANTADA y mejoras, incidencias y no conformidades pasan a CERRADA
IMPLANTADA	Finalizar	Si y sólo si HAY PLs relacionadas con la versión	Deben estar las Ots cerradas	Comprueba que las OTs están cerradas	La versión pasa a estado CERRADA, resolución Cerrada
EN RESOLUCIÓN	Cancelar	Siempre (motivo obligatorio)	Si sólo hay SVEs→deben estar cerradas Si hay PLs →deben estar cerradas con resolución Cancelada	Comprueba que las entidades relacionadas están cerradas	La versión pasa a estado CERRADA, resolución cancelada y mejoras, incidencias y no conformidades pasan a BACKLOG
IMPLANTADA	Cancelar	NO ES POSIBLE

PL hija (PLH)

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

Generadas por el Grupo Planificador en función de las solicitadas por el peticionario.

En este caso, las Pls hijas se crean en estado Planificable, con idea de que el Grupo Planificador proponga una fecha y que en base a la misma CTI la planifique. Esa fecha de planificación deberá ser validada por el Grupo Planificador.

Generadas automáticamente si se ha solicitado por parte del peticionario una PLU. En este caso, se genera sólo una PL hija (correspondiente a una plataforma, entorno y para todos los grupos lógicos) en un estado en el que CTI planifica y pasa a ejecutar.

Si una PL hija se transforma en una PLU, transicionará automáticamente de estados anteriores al estado en el que CTI planifica, no necesitando aprobación por parte del Grupo Planificador de esa planificación.

Estas transiciones automáticas se harán también en el caso de una PLU que esté pendiente de planificación y que pase a ser normal. En este caso, pasará al estado en el que el Grupo Planificador proponga fechas.

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

Estado PLANIFICABLE

Ancla

	planifica
	planifica

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. Hay que tener en cuenta lo siguiente (esto es de aplicación no sólo a PLs de versión, también a las de datos y de configuración):

Advertencia
PL hija para la instalación en el entorno de PREPRODUCCIÓN: el plazo de planificación desde que se realiza la Solicitud de PL hija es de 48h a 72h. PL hija para la instalación en el entorno de PRODUCCIÓN: el plazo de planificación desde que se realiza la Solicitud de PL hija es de 48h.

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.

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

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 PARALIZADA

El proveedor de sistemas puede paralizar la ejecución de la PL porque puede haber un motivo de bloqueo de la misma. Una vez se haya eliminado ese motivo, volverá a pasarla a EN RESOLUCIÓN

Estado PDTE. REVISIÓN TÉCNICA

El peticionario 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. Al cerrase la PL hija, se producirá el cambio de versión en CMS en la tripleta (plataforma-entorno-grupo lógico) correspondiente.
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') y la resolución de todas ellas será "No se hará"

Reinstalación	Marcha Atrás	Desinstalación
SI	SI
SI	NO
NO		SI
NO		NO

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.

El proveedor de 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 Planificador que se revisen los parámetros de Complejidad y/o facturación.

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.

Puedes ver un resumen del proceso accediendo aquí.

PLs no ejecutadas por CTI

Lo normal es que el proveedor que hace los despliegues sea CTI, pero hay ciertas plataformas en las que , si bien su administración corresponde a CTI, los despliegues en las mismas se hacen a cargo de los propios proveedores de desarrollo. En estos casos no interviene el Grupo Planificador, siendo el proveedor de sistemas de la plataforma quien ejecuta todas las acciones.

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

Advertencia

Es imprescindible que, hasta que no finalice la compilación del código, no se marque como Urgente una PL. Si se hace, existe un alto riesgo de que se atienda antes de que haya terminado la compilación, y en ese caso quede rechazada porque en el momento de atenderla no haya aún un paquete instalable.

Por tanto, es importante para el correcto desarrollo de los proyectos, el marcar la PLU en el momento adecuado, entendiendo que la U no significa importante, sino Urgente (para acometer cuanto antes).

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.

Cambiar la urgencia de la PL hija tiene repercusiones:
- Si el cambio es a PLU:
  - Si está en estado PLANIFICABLE pasa a estado PDTE. CALENDARIZAR y se suprime el estado CALENDARIZADA.
  - Si está en estado CALENDARIZADA pasa a estado PDTE.COMENZAR RESOLUCIÓN, pudiéndose variar la fecha de inicio estimada.
  - Si está en estado PDTE. COMENZAR RESOLUCIÓN no hay cambio de estado pero se puede variar la fecha de inicio estimada.

- 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

Resumen del proceso de implantaciones

PL de datos

PL de configuración

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

Roles

Rol	Descripción
Peticionario	Rol solicitante de la PL, en este caso el proveedor de sistemas (CTI)
Responsable sistemas	Rol responsable de la plataforma en la que se hace la modificación o el cambio de configuración
Grupo planificador	Rol responsable de la correcta gestión y planificación por parte del resolutor
Resolutor	Rol que ejecuta y resuelve la PL. Es el proveedor de sistemas (CTI)

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

Lucidchart

lcId	a973b109-8c0c-4e70-8f96-ab4a06227441
rich-viewer	true
autoUpdate	true
autofit	false
name	Estados PL sistemas - ~WiqcCKdfOAm
width	967
convertedFrom	onprem
origParams	eyJzaW1wbGVWaWV3ZXIiOiJ0cnVlIiwiYXV0b1VwZGF0ZSI6InRydWUiLCJhdHRhY2htZW50SWQi OiI1MDA4NTc4MyIsInNpemUiOiI2MDAiLCJ2ZXJzaW9uIjoiMTgifQ==
documentToken	v2_8e8f9ce2d70d9d13b8afc16261b5a6ca2957b000af07fcb633a22869896d39a7-a=171816341&c=d1873183-daff-4cd4-a0ef-3f5bcb960f8c&d=22f5366d-daf4-4e8e-8820-d19ba1cef17f&p=
id	22f5366d-daf4-4e8e-8820-d19ba1cef17f
align	Left
height	610

draw.io Diagram

diagramName	Estados PL sistemas (from Lucidchart).drawio
revision	1

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

El solicitante, crea el tipo de entidad "PL sistemas" sobre el proyecto de tipo plataforma correspondiente.

Debe informar de forma obligatoria:

Tipo PL sistemas:
- Con aprobación horaria por parte de la STIC.
- Sin aprobación horaria por parte de la STIC.
Clasificación PL: dependiendo de la clasificación que se escoja deberán adjuntar un tipo de PID u otro.
Si el tipo PL es con aprobación horaria por parte de la STIC:
- Normal
- Alta/Baja/Modificación de regla de firewall
Si el tipo es sin aprobación horaria por parte de la STIC:
- Alta/Baja/Modificación de recursos físicos
- Publicación de icono en plataforma Citrix
- Asignación/Liberación de volúmenes en cabinas de disco
- Alta/Baja/Modificación de zonas/alias en SAN de los CTIs
- Alta/Baja/Modificación una granja en balanceador
- Alta/Baja/Modificación/Propagación de VLANs en equipos de conmutación
- Alta/Baja/Modificación de registro en DNS corporativo/externo
- Alta/Baja/Modificación de configuraciones de ámbitos en NGINX
- Alta/Baja/Modificación publicación de acceso externo en PROXY-INVERSO de CTI
ID RFP relacionada: (opcional) RFP de la plataforma que estén en estado "EN RESOLUCIÓN" o "CERRADA".
Plataforma: vendrá ya dada por el proyecto.
Entorno o entornos en los que se quiere hacer la implantación.
Grupo o grupos lógicos en los que se quiere hacer la implantación. Además, será necesario saber si el peticionario quiere una implantación para todos los grupos lógicos seleccionados o una por cada uno de ellos.
Restricción horaria: (opcional)
Si hay o no corte de servicio.
Miembro asignado: (opcional) se podrá indicar miembros de CTI, tanto coordinadores como grupos por tecnologías, para identificarlos.
Aportar el documento PID como adjunto.

Tras estos pasos, la PL se habrá creado y pasará a un estado en el que el proveedor de sistemas (CTI) resolverá.

Al igual que para la PL de incremento versión, este proceso se modela con dos tipos de entidades:

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.

Si todas las Pls hijas están cerradas y no es necesario generar ninguna más, el peticionario puede finalizar la PL.

Hay tres posibles resoluciones para cerrar la PL:

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:

De forma automática cuando se solicita la PL
Mediante la acción de generar PLs hijas estando en resolución.

El ciclo de vida de las PLs hijas va a depender del tipo de la PL:

Si la PL es de tipo 'sin aprobación horaria por parte de la STIC', las PLs hijas son planificadas por CTI y se ejecutan directamente, sin necesidad de aprobación por parte del Grupo Planificador.
Si la PL es de tipo 'con aprobación horaria por parte de la STIC', las PLs hijas son planificadas por CTI, y esa planificación debe ser aprobada por el Grupo Planificador. Cuando las fechas hayan sido aprobadas, las PLs hijas podrán ejecutarse directamente.

En cualquier caso, cuando se ejecuta la PL hija NO hay revisión de la ejecución, pasando directamente al estado CERRADA.

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.

Vídeo formación PLs

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

Ver vídeos

Lucidchart

lcId	eebc5f11-0013-4b5f-98c5-9afecbae6f6d
rich-viewer	true
autoUpdate	true
autofit	false
name	Estados PL version - peHTAxfOdT4s
width	1462
convertedFrom	onprem
origParams	eyJzaW1wbGVWaWV3ZXIiOiJ0cnVlIiwiYXV0b1VwZGF0ZSI6InRydWUiLCJhdHRhY2htZW50SWQi OiI1MDA4NTU1NyIsInNpemUiOiI2MDAiLCJ2ZXJzaW9uIjoiMjcifQ==
documentToken	v2_7420061067f423f58777d5ef5586382ddc68a1bb35243dfe73217b5a819d7880-a=171816341&c=d1873183-daff-4cd4-a0ef-3f5bcb960f8c&d=dbb0d4e7-9fe4-4ffb-9c97-b8f319723509&p=
id	dbb0d4e7-9fe4-4ffb-9c97-b8f319723509
align	Left
height	722

draw.io Diagram

diagramName	Estados PL version (from Lucidchart).drawio
revision	1

Ayuda relacionada:

Enlace
Enlace

Propiedades de página

hidden	true

Descripción

Dar respuesta a las solicitudes de servicios de transición de instalaciones software como consecuencia del desarrollo y evolución de sistemas de información, que llegarán al adjudicatario en forma de peticiones de lanzamiento (PL).

Asegurar que los cambios registrados se prioricen, planifiquen, prueben e implementen, documenten y revisen de manera controlada.

Categoría

Productos

Subcategoría

Despliegues

Modificado

Modifieddate

Divbox

class	ir-arriba

modifieddate

HTML

<script>
/*------*/
/* JS para botón para Subir al inicio de la página (fixed esquina derecha abajo)*/
/*------*/
$(document).ready(function(){
	$('.ir-arriba').click(function(){
		$('body, html').animate({
			scrollTop: '0px'
		}, 300);
	});

	$(window).scroll(function(){
		if( $(this).scrollTop() > 0 ){
			$('.ir-arriba').slideDown(300);
		} else {
			$('.ir-arriba').slideUp(300);
		}
	});
});
</script>

Propiedades de página

hidden	true

Categoría

Gestión de servicios

Subcategoría

Actividad planificada

Modificado

Accesos directos de espacio

Árbol de páginas

Historial de página

Versiones comparadas

Clave

Image Added Proceso:

Titulo pagina

Objetivo

Alcance

PL de incremento

versión

Roles

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

Diagrama de flujo

Diagrama de estado

Ciclo de vida

Servicio de Verificación de entrega (SVE)

Estados PL padre

Estado ABIERTA

Estado PDTE. REVISIÓN

Estado NO ACEPTADA

Estado PDTE. INFORMACIÓN

Estado PLANIFICABLE

Estado EN RESOLUCIÓN

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

PL hija (PLH)

Estado PLANIFICABLE

Estado PDTE. CALENDARIZAR

Estado CALENDARIZADA

Estado PDTE. COMENZAR RESOLUCIÓN

Estado EN RESOLUCIÓN

Estado PARALIZADA

Estado PDTE. REVISIÓN TÉCNICA

PLs no ejecutadas por CTI

Cambio en la urgencia de la PL

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

Roles

Requisitos para el ciclo de vida de la PL sistemas

Diagrama de flujo

Diagrama de estado

Estado EN RESOLUCIÓN

PL hija sistemas (PLH sistemas)

Estado PDTE. CALENDARIZAR

Estado CALENDARIZADA

Estado PDTE. COMENZAR RESOLUCIÓN

Estado EN RESOLUCIÓN

Vídeo formación PLs

Diagrama de estado

Ciclo de vida

Servicio de Verificación de entrega (SVE)

Estados PL padre

Estado ABIERTA

Estado PDTE. REVISIÓN

Estado NO ACEPTADA

Estado PDTE. INFORMACIÓN

Estado PLANIFICABLE

Estado EN RESOLUCIÓN

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

PL hija (PLH)

Estado PLANIFICABLE

Estado PDTE. CALENDARIZAR

Estado CALENDARIZADA

Estado PDTE. COMENZAR RESOLUCIÓN

Estado EN RESOLUCIÓN

Estado PARALIZADA

Estado PDTE. REVISIÓN TÉCNICA

PLs no ejecutadas por CTI

Cambio en la urgencia de la PL

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

Roles

Requisitos para el ciclo de vida de la PL sistemas

Diagrama de flujo

Diagrama de estado

Estado EN RESOLUCIÓN

PL hija sistemas (PLH sistemas)

Estado PDTE. CALENDARIZAR

Estado CALENDARIZADA

Estado PDTE. COMENZAR RESOLUCIÓN

Estado EN RESOLUCIÓN

Vídeo formación PLs