Historial de página

...

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

...

Los motivos por los que la documentación asociada a la PL se rechaza, se resumen en:

• Incongruencias entre lo que se indica en la PL y lo que se registra en el PID:
  • Entornos diferentes (o no reflejados en el PID), información de si existen o no cortes de servicio o incluso plataformas distintas. Recordad siempre que es fundamental elegir bien la plataforma en la creación de la PL porque el PID se crea en la página de la plataforma.
  • Versiones o entregas diferentes.
  • Observaciones registradas en la PL que son incoherentes con lo que se indica en el PID. Recordad que esas observaciones nunca pueden suponer una ampliación o modificación de lo que se indica en el PID, en todo caso una restricción.

• Falta de especificación de forma explícita de parámetros solicitados en pasos del PID para cada uno de los entornos. Será motivo de rechazo que estos parámetros vengan indicados a modo de ejemplo.

• Incongruencias en la codificación entregada por el proveedor. En el caso de que no se especifique ninguna referencia concreta al respecto, la codificación utilizada es pk15.( NLS_LANG=SPANISH_SPAIN.WE8ISO8859P15)

• Incongruencia entre los nombres de los scripts indicados en el PID y los que se adjuntan en la herramienta. Recordad que para las PLs de datos no deben adjuntarse scripts en la PL, sólo se considerarán válidos los aportados en la SVD puesto que pasan la revisión de la Oficina de Calidad. Será por tanto motivo de rechazo solicitar en el PID la ejecución de un script que no se haya adjuntado a la SVD. Será igualmente motivo de rechazo solicitar la ejecución de parte de scripts.

• No indicar en la PL el campo de planificación detallada si se indica en el PID la necesidad de una planificación por fases para realizar validaciones.

• La no existencia de esquemas de BBDD y plataforma destino necesarios en la ejecución de cada paso del PID.

• Incluir en el PID información de instalaciones completas en versiones no iniciales. Recordad qué si la versión a instalar no corresponde con un despliegue inicial, el PID sólo debe indicar los cambios que se deben realizar en esta instalación exclusivamente, con lo que es una mala práctica “copiar y pegar” la documentación de despliegues anteriores.

• No incluir un procedimiento de marcha atrás. Recordad que nunca hacer un backup de la BBDD o de un servidor de aplicaciones es un procedimiento autorizado de marcha atrás.

• Solicitar la modificación de los .WAR y/o .EAR

• No reflejar la información de los datasources necesitados y de cómo instalarlos tratándose de una versión inicial.

• Solicitar regenerar por pl más de 20 escenarios.

• Marcar en una PL de datos el campo de ventana horaria sin haber acordado una ventana de ejecución.

• No tener el código a desplegar en el repositorio de software habitual (DML).

• Que los cambios solicitados en la PL no estén en concordancia con la normativa recomendada (por ejemplo, que se indique que se haga con TOAD).

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:

...