En el proceso de gestión de lanzamientos, el primer paso es que el proveedor de sistemas (CTI) revise la documentación del despliegue que se registra en el PID (Proceso de Instalación y Desinstalación). Esta revisión puede conllevar la aprobación o rechazo de la misma, lo que tiene como consecuencia tener que rehacer el PID.
Motivos de rechazo |
---|
Incongruencias entre lo que se indica en la PL y lo que se registra en el PID:
|
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. También lo será 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 que, 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 hacer un backup de la BBDD o de un servidor de aplicaciones nunca 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). Las aplicaciones usadas para el despliegue de las PLs son:
|
|
Falta de instrucciones o medios en el PID para crear usuario APP/OWNER, si fuera necesario. |
Os recordamos que el PID es la documentación que sigue el proveedor de sistemas para hacer el despliegue, con lo que es importante darle en él instrucciones concretas, evitando las comprobaciones y las notas.