Cambio de versión de GeneXus - Paso 4 - Comparar versión vieja con versión nueva
Paso 4 del ciclo Metodología para el cambio de versión de GeneXus 
En el paso anterior, pudimos crear una build all exitoso de la KB GeneXus, para generar la aplicación y una instalación de la aplicación en un ambiente de pruebas.
Una vez que tenemos la aplicación instalada en la versión vieja y la versión nueva, tenemos que pensar en comparar el funcionamiento de ambas aplicaciones y poder detectar las diferencias.
Las comparación van a ser de diferentes tipos:
Configuración
En este paso se deben comparar los archivos de configuración (web.config, client.cfg, log.config, etc) para estudiar las diferencias entre ambas versiones y entender cuales pueden afectar a la nueva aplicación.
Comparar los temas y archivos css generados en la nueva versión. Identificar las clases que tienen diferencias.
Navegación
Al hacer el REBUILD ALL de una KB en una versión nueva de GeneXus, se hace una re-escritura del 100% del código generado. En esta re-escritura, muchas veces hay cambios en la forma que se acceden a las tablas de la aplicación.
Una forma de identificar estas diferentes formas de navegar las tablas, es el comparador de navegaciones.
Para hacer la comparación, uso KBDoctor, para transformar los archivos de navegación a archivos txt y luego uso algún comparador de texto para encontrar las diferencias.
Algunas de las diferencias que pueden encontrarse se explican por cambios en algusos SACs.
Algunas de las diferencias que pueden encontrarse se explican por cambios en algusos SACs.
Una vez que se identifican objetos con diferencias, hay que estudiarlos y ver si dichos cambios pueden afectar el funcionamiento de la nueva aplicación.
User Controls y External Object.
En el Paso 2, identificamos aquellos objetos que usaban User Controls que cambiaron y también External Objects. Este es el momento de probarlos y ver si funcionan en forma correcta.
Ejemplos de comprobaciones:
- Mandar y Recibir mails
- Grabar y leer planillas de calculo
- Generar PDF (comparar tamaño y presentación)
- Consumir servicios externos
- Grabar archivos de texto
- Hacer upload de archivos
- Ejecutar objetos command line.
Mobile
Si la aplicación tiene componentes mobile, debería probarse si la aplicación SD generada con la versión anterior, sigue funcionando igual con los servicios de la aplicación nueva.
Si se encuentran problemas o diferencias, tendremos que crear una nueva versión de la aplicación SD, para funcionar con los nuevos servicios, lo cual agrega una complejidad adicional al proyecto.
Servicios publicados.
En caso que la aplicación publique servicios web (protocolo SOAP o REST) hay que asegurarse que no tengan diferencias entre la versión nueva y la vieja.
Este es uno de los motivos que mas problemas ha traído en migraciones anteriores.
Es conveniente revisar que los WSDL publicados sigan siendo compatibles con los viejos (aunque tengan diferencias) en caso de los servicios SOAP.
Puede necesitarse ajustar los SDT utilizados para mantener la compatibilidad.
También conviene hacer pruebas para ver si las aplicaciones que hoy consumen servicios de la aplicaciones, siguen funcionando sin necesidad de cambios con la nueva versión. En caso de detectar diferencias, hay que solucionarlas (dejarlo igual que antes) o avisar a todos los clientes que van a tener un cambio que les ocasionará problemas.
User Interface
Hay que probar las pantallas de la nueva aplicación y ver que todo se ve correctamente. Analizar todos los UC que tienen UI que se utilizan y probarlos bien. Ajustar los temas para que se vea correctamente la nueva versión.
Performance
Elegir procesos "pesados" y ejecutarlos en la aplicación vieja y la nueva y comparar cuanto demoran. Si hay los procesos son mas lentas en la nueva versión, hay que identificar el problema y corregirlo.
Resultados
En caso de tener test automáticos, ejecutar todas las pruebas unitarias y de UI y comparar los resultados.
En caso de no tenerlo, es bueno hacer pruebas con procesos críticos de cálculos, sobre todo de importes en la aplicación nueva y en la vieja y chequear que sean iguales.
Conclusiones - Comparar la versión vieja con versión nueva.
Esta etapa podría ser automatizada, sin tantos trabajo humano.
El problema es tener 2 versiones de la aplicación, identificar objetos críticos, ejecutar pruebas que incluyan a dichos objetos críticos y comparar los resultados.
Mi sueño es que todo eso se pueda hacer sin intervención humana, pero falta mucho para eso aun.
Herramientas utilizadas
KBDoctor - Para generar archivos de texto desde las navegaciones
GXTest - Para automatizar pruebas unitarios y de UI.
Comentarios
Publicar un comentario
1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.