Objetivo 

...

• 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.
• 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, existen tres casos en los que las hijas se crearán de forma automática:
  • Si se solicita en la creación una PLU y los grupos lógicos correspondientes a la plataforma y entorno
  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, existen tres casos en los que las hijas se crearán de forma automática:
  • Si se solicita en la creación una PLU y los grupos lógicos correspondientes a la plataforma y entorno seleccionados tienen únicamente los valores "APL" y "BD".
  • Si al solicitar una hija se informa de que ésta es urgente y los grupos lógicos correspondientes a la plataforma y entorno seleccionados tienen únicamente los valores "APL" y "BD".
  • Si para una hija normal solicitada se modifica la urgencia y los grupos lógicos correspondientes a la plataforma y entorno seleccionados tienen únicamente los valores "APL" y "BD".
• 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”

        
        

         

        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:
    • Entorno.
    • Grupo lógico.
    • Nombre del parámetro en el Procedimiento de Instalación y Desinstalación (PID).
    • Identificador del servicio: Indicar que es el nombre del servicio dentro del catálogo.
    • Descripción funcional: Indicar con un mensaje una breve descripción del servicio que debe machear con el identificador del servicio y que para los “servicios rest” sería adecuado poner además la URL a la API facilitada en tiempo de desarrollo.
    • URL proporcionada por la Oficina de Interoperabilidad.

    
    

    El Proveedor de Sistemas tendrá que tener en cuenta estos comentarios a la hora de ejecutar la Petición de Lanzamiento.

    
    

...

• 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.
• Aportar el documento PID como adjunto.

...

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

Estados PL padre

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.

...

• 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 PIDEl 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.

Estado PDTE. INFORMACIÓN

...