Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

...

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

...

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  lo ejecute en los entornos solicitados por el proveedor, siempre bajo la supervisión del Responsable de Producto.

...

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:

...

  • 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 

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

...


...


Descripción del flujo para PL y

...

PL

...

Hijas



Figura 1. Diagrama flujo PL.

...

Figura 2. Diagrama flujo PL Hija.

Tabla de estados y acciones

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

Descripción del flujo 

...

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

...