...

La PL de incremento de versión aplica sobre todas las aplicaciones de la STIC centralizadas y que se han considerado que deben tener desarrollo y evolución. Esto se traduce en que en el sistema JIRA está dada de alta como proyecto.

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, ambos roles tienen los mismos permisos 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

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.

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), e proceso de gestión de lanzamientos se articula en JIRA con dios 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 acto de ejecución de instalación en una Plataforma, entorno, grupo lógico o conjunto de grupos lógicos.

Diagramas de Flujo

Figura 1. Diagrama flujo PL.

...