Protocolo Actualización

Recursos por parte de GPS

GPS: Software

• Última release de gpsnode y/o portal Java.
• Procedimiento utilizando la herramienta de actualización (ver https://gps-plan.com/ayuda/kgps/actualizacion-con-gps-agent)
• mail plantilla de convocatoria Actualización
• ¿Cómo actualizar?

GPS: Personal

• Técnico de Sistemas (Migración/Administrador de sistemas)

• CONSULTOR/SOPORTE (Coordinación de la operación y pruebas funcionales)

Recursos por Parte de Cliente

Cliente: Hardware

• Máquina con los requisitos establecidos previamente.

Cliente: Software

• Usuario de Active Directory que simula a un usuario real.

Cliente: Personal

• Administrador de Sistemas (Mover archivos en caso necesario, asistencia con configuración de DNS, DHCP, Active Directory…)

• Usuarios Clave de la Herramienta para validaciones funcionales, tanto de producto como de integración con SAP.

Pasos a Realizar

1. GPS + KeyUsers: Iniciar solicitud de cambio de versión en el cliente.
2. GPS + KeyUsers: Justificar el cambio. Tomar nota del motivo de la actualización.
3. GPS: Informar al departamento de sistemas de los nuevos requisitos técnicos si los hubiera.
4. GPS Informar a KeyUser y SuperUser de las diferencias existentes entre su versión actual y la nueva que se pondrá (release notes en github) y solicita aprobación cambio de versión en Desarrollo / Pre-producción. how to?
5. SuperUser: Valida la solicitud de cambio de versión.
6. GPS + SuperUser: Consensuar fecha de instalación.
7. GPS: Se coordina un equipo de desarrollo y soporte para que estén activos durante la instalación. Si se trata de producción se debe incluir siempre a una persona del equipo de sistemas para posibles reinicios de la máquina o restaurar la BD etc.
8. Actualización en el entorno de desarrollo (ver más abajo pasos del punto Pasos en el día de la actualización)
9. Realización de pruebas básicas de funcionamiento por parte del equipo funcional de GPS. (pendiente crear un formulario específico para esto.)
   • Comprobar si el cambio motivo de la instalación se ha resuelto.
   • Acceso LDAP / OAuth2
   • Pasar por los maestros principales (web y/o windows…)
   • Previamente, sacar unos contadores (de un profesional y en el gantt web), y después de la actualización comprobar si siguen los contadores.
   • Test de variables de nómina: Antes y Después.
   • Funcionamiento marcajes.
   • Aplicar cualquier incidencia.
   • Nóminas en el portal.
   • Importación y exportación por ejemplo SAP.
   • Extracción de los informes más usados (pdt decidir cuales).
   • Formularios de vacaciones.
   • Si tiene App: solicitar un permiso, por ejemplo: un permiso por días desde la APP que dure por ejemplo 7 días, y tras aprobarlo, comprobar que queda una unica incidencia de 7 días introducida y no 7 incidencias de un día.
   • Si hay scripts de servidor que se ejecuten (querycustom) comprobar alguno que sigan funcionando.

* Revisar el anexo *NOMBRECLIENTE*_Pruebas en la documentación interna para más información.

10. Key-Susers: Solicitar conformidad por parte del cliente de que se ha validado la versión en el entorno de test. *OBLIGATORIO PARA ACTUALIZACIÓN EN PRODUCTIVO*
11. SuperUser. Solicitar fecha y hora (prohibido Jueves, Viernes, previos a festivos y periodos vacacionales. El tiempo de parada estimado será de 1 hora) de actualización en producción, con conformidad tanto de los usuarios clave, como del departamento de sistemas, recordando los nuevos requisitos si fuese necesario. En esta solicitud de fecha, se debe informar nuevamente de la versión que se va a instalar, los cambios que incluye, y el tiempo de parada previsto, así como la existencia del plan de contingencia si hubiere. Se enviará un recordatorio en Outlook con esta información de manera que avise automáticamente al cliente media hora antes de la instalación.

Pasos en el día de la actualización:

1. Recordatorio en el día de la actualización de que nuestro equipo va a realizar el cambio a la hora convenida
2. Si es en desarrollo se recomienda solicitar una restauración de la BD y configuraciones que sean posibles trasladar de producción en ese entorno. Para asegurar datos frescos.
3. Si es en Producción: asegurar la existencia de un backup de menos de 24h antes.
4. Descargar scripts y archivos de actualización y modificarlos según las necesidades del cliente.
5. Actualizar versión.
6. Pruebas preliminares por parte de GPS. Definir lista de pruebas GPS
7. Pruebas por parte del cliente.

Casos en los que se debe retroceder versión instalada

Si tras una instalación ocurre una de las siguientes casuísticas, se debe retroceder la versión inmediatamente:

• No arranca BOLD o alguna de sus partes fundamentales (app, portal, planificador, versión web)
• No se puede calcular la nómina o los contadores de los empleados
• No se pueden logar los usuarios de la manera acostumbrada (oauth o similares)
• Se pierden las configuraciones de los usuarios
• ….

Diagrama de Flujo

En este enlace se encuentra el esquema original:
https://lucid.app/lucidchart/68abba79-7502-497e-9d1e-b11fad04fb8e/edit?invitationId=inv_4a04688f-3e66-4ace-88b8-de81520f15da

Was this article helpful?

0 out Of 5 Stars

5 Estrellas		0%
4 Estrellas		0%
3 Estrellas		0%
2 Estrellas		0%
1 Estrellas		0%

5 Enviar

How can we improve this article?

How Can We Improve This Article?

Submit