Historial de página
...
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 |
(*) 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.
...
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:
...
- 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:
...
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.
...
- 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
Asignación/Liberación de volúmenes en cabinas de disco
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.
...
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2