Cambiar de versión de GeneXus: Que preguntas debo hacerme?

Problema: Tengo una KB Genexus y la estoy generando con la version N (sin errores y esta en producción) y necesito parasarla a la version M con M > N. 

Antes de cambiar de versión, intento siempre contestar las siguientes preguntas. 

Los usuarios van a poder ejecutar simultáneamente la version anterior y la nueva?

Siempre conviene que los usuarios puedan seguir ejecutando por un tiempo limitado, hasta estabilizar la nueva versión, tanto la version anterior como la nueva. De esta forma, cada vez que aparece alguna dificultad o diferencia, se puede volver al sistema anterior y permitir que el usuario no se tranque en su trabajo. Este tipo de problemas, deberia tener una prioridad alta para su resolución pues el objetivo es sacar de produccion la version vieja lo antes posible. 

Alguna funcionalidad del sistema anterior, no va a existir mas en la version nueva? 

Si fuera asi, conviene evaluar si esta funcionalidad es indispensable y si asi lo fuera, hay que desarrollarla con la nueva version de GeneXus. Por ejemplo, si estoy migrando desde GeneXus Evo3 a GeneXus 17 y tengo un programa generando WinForms, debo reprogramar para tener la misma funcionalidad que tenia en el WinForm pero con WebForms o con una aplicación Mobile.  Tambien pueden existir limitaciones de seguridad que exijan reprogramar parte de nuestro sistema. 

Que componentes externos utiliza mi KB? 

Debo hacer un inventario de todos los componentes externos que utilizo para desarrollar y para ejecutar mi aplicacion:

Programas externos
User Controls
Patterns
Modulos
Data Types especificos (ExcelDocument, File, Directory, XMLReader, XMLWriter, etc). 
Versiones de software usado (version de Base de datos, servidor web, compilador, etc, etc). 

Hice alguna personalizacion en la version de GeneXus anterior que debo llevar a esta nueva version?

Con el pasar de los años, es comun que se hagan cambios en determinados lugares, archivos de configuracion especificos, etc que deberán reflejarse en el nuevo ambiente de especificacion / generacion / ejecucion. 
Por ejemplo:
   Cambie algun dkt de los patterns utilizados?
   Hice algun cambio al web.config, client.cfg que deba ser reflejado? 
   Utilice algun archivo flag para cambiar el comportamiento de GeneXus?

Cuales SACs pueden afectar?  Que objetos debo revisar?

Esta es la etapa mas difícil de todas y que seria bueno poder automatizar. Hay que revisar todos los SACs de compatibilidad, entre la version de GeneXus anterior y la nueva y ver que me puede afectar. 

Cosas que afectan:

Cualquier cosa que cambie el nombre de los objetos que ve el usuario, por ejemplo, cambios en namespaces, nombre de packages en java, objetos que cambian de modulo (por ejemplo el SDT Messages). 
Cambio de comportamiento. Los UC que vienen con GeneXus tienen cambios en su comportamiento y hay que seguirlos de cerca. Por ejemplo, el FileUpload, ha tenido cambios en los últimos Upgrades. 
Propiedades nuevas, propiedades que no existen mas, o que se mueven de lugar. 
Funcionalidades deprecated. 

Hay muchos mas. 

Conociendo la KB (y que componentes utiliza) y revisando los SACs puedo estimar que cosas voy a tener que testear con mas cuidado y que cosas voy a tener que reprogramar. 

Me gustaría contar con una herramienta (KBCompatibiltyChecker) que automatizara un poco este proceso. 

Funcionaria asi:

Dado una KB en la version de GeneXus N, me pregunta a que version la quiero pasar, por ejemplo M. 

Esta herramienta, hace una análisis estático de código, y le pone una etiqueta o categoría a mis objetos. 
Ejemplo de etiquetas: 
UC:FileUpload
UC:ExcelDocument
EO:FirmoXML
SDT:Messages

Por otro lado (y ésta es la parte mas difícil de lograr), los SACs también tienen etiquetas puestas por el equipo de soporte (o por los usuarios y aprobado por soporte) de los componentes afectados y si afectan la compatibilidad o no. 

Entonces tenemos:
Una lista de objetos etiquetados con los componentes que usan
Una lista de SACs etiquetados que afectan la compatibilidad y fueron detectados entre la version N y la M de GeneXus. 

La herramienta lo que debería hacer es un listado de los objetos que debo revisar, con una pista de que es lo que hay que revisar.

GeneXus siempre persigue automatizar los pasos automatizables del proceso de desarrollo. Creo que ésta es una oportunidad de automatizar este chequeo que nadie hace pues es demasiado trabajoso. Puede ayudar mucho a pasar KB viejas a versiones mas nuevas de GeneXus, reutilizando su conocimiento. 

Hoy encontramos muchos de estos problemas en etapas de testeo y de ejecución y son mucho mas caros de arreglar. 

Que consideraciones de seguridad debo tener?

En todas las migración que he participado, siempre los controles de seguridad se han endurecido y muchas veces afectan el funcionamiento del sistema. Si la migración implica el cambio de version de servidor WEB (IIS, tomcat, etc)  o de version de compilador (java, .net, etc) siempre vienen con mejoras en la seguridad, que hacen la aplicación mas segura y complica un poco al usuario. 
El SecurityScanner ahora integrado a GeneXus puede ayudar a encontrar alguno de estos problemas.

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.

Entradas más populares de este blog

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Aplicación monolítica o distribuida?

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.