Metodología de actualización de versión de GeneXus.

Hace unos dias, hice un pequeño relevamiento sobre como manejan los cambios de versión en GeneXus. Me da la sensación que hay mucho para mejorar en la forma en que se hacen los cambios de version y lo primero que quería era tener la opinion de algunos.
Respondieron al cuestionario 22 personas. Muchas Gracias! a quienes se tomaron el tiempo para responder.
Hago un breve resumen de las preguntas y respuestas. 

 ¿Con que frecuencia cambian la version de GeneXus?

Hay muchas situaciones diferentes. 
La mayoría de quienes respondieron, dijeron que instalaban la version cuando salia o casi cuando salia.
Hay gente que migra cada un periodo de 2 años y otros es mas a demanda, de nuevas funcionalidades, de bug arreglados o de estabilidad de la version.

  Que proceso/metodología usan para cambiar de versión? Explique brevemente los pasos que sigue

En las respuestas no hay un patrón claro de como hacer un cambio de version.
Para algunos es instalar la nueva versión y convertir la KB sobre la que están trabajando.
Varios hacen comparaciones de navegaciones.
Todos hacen muchos testing comparando, pero pocos tienen test automatizados.
Algunos prueban si los servicios WEB nuevos y viejos son iguales.
Arman ambientes de testing en el cliente para comparar la version nueva con la vieja.
Quienes usan jenkins o procesos de integración continua, da la sensación que les da menos trabajo hacer los cambios de version.

Usan herramientas externas para cambiar de versión?. Cuales son?

La mayoría no usa herramientas extras. 

Los demás han utilizado: 

• Comparador de navegaciones.
• DBComparer
• SOAPui
• SOA Cleaner
• Beyond Compare
• KBDoctor
• GXTest
• Jenkins
• Mergely 

Con qué dificultades se han encontrado en el cambio de versión?

Esta fue una de las preguntas en las cuales escribieron mas cosas. 

La mayoria dice que antes los cambios eran mas disruptivos y ahora los cambios son menos. 

Varios hablaron de pequeñas diferencias en las navegaciones

Problemas en "cosas externas", como .DLL, Stored Procedures, JAR. 

Una mención especial llevan los User Controls pues varios lo nombraron como causantes de problemas. 

GXFlow y GAM son nombrados como que tuvieron diferencias en el comportamiento. 

Diferencias en los web services publicados

Problemas para consumir web services de terceros con el código viejo. 

Controles de Seguridad (403)

Problema de memoria y generación de SDT. 

Me llamó la atención que nadie hizo mención explícita a que las pantallas quedaban mal o feas. 

Que verificaciones hacen al instalar una nueva version de GeneXus?

Hay una gran dispersión en las respuestas. 

Algunos testean toda la aplicación, otros un ciclo completo de la misma y otros hacen poco testeo y pasan a producción. 

En algún caso, instalan en paralelo con la aplicación anterior. 

Estudiar las Releases Notes. 

Comparación de navegaciones. 

Pocos tienen los test automatizados. 

Cuanto duran los proyectos de cambio de versión?. 

Hay gran variabilidad, algunos son de 2 a 3 días, hasta 8 meses. 

Los factores que afectan son el tamaño de la KB y el salto tecnológico que hay entre la versión anterior y la nueva. 

Comentarios adicionales

Estos los pongo casi todos, porque son bien diferentes entre si. 

Algunos dicen que faltan herramientas para automatizar ciertos controles. 

Otros que es mas fácil migrar en las últimas versiones, por lo que ven recomendable estar siempre en la última versión. 

Debería existir un informe de "impacto " de KB de una versión a otra, en particular si cambian algún criterio interno de GX, ej. manejo de Subtipos, optimización de navegaciones . consultas Query. Que el usuario GX no sabe si algo de la nueva version de GX, le puede afectar, y por tanto GX debería informar cuando hace el impacto de migración.

Seria bueno automatizar mas los procesos de conversion y la detección de diferencias entre una aplicación nueva y la vieja.

La versión 16 ha resultado muy estable y no hemos tenido problemas al ir subiendo de upgrades.

Estaría bueno alguna herramienta que compare las navegaciones de cada objeto en 2 kb diferentes.

- Creo importante destacar que el cliente debe jugar un rol muy importante en la migración de un sistema. Es quien debe en parte o en su totalidad financiar la migración, y debe jugar un rol activo en las pruebas de QA del Sistema. Al menos en mi empresa no migramos aplicaciones a costo nuestro. 

- En sistemas críticos obviamente se recomienda hacer una etapa de QA del ciclo completo de la aplicación, probar todos los módulos, su funcionamiento, su performance, que el backend, frontend y la(s) aplicación(es) móvil(es) asociadas operen como debe ser. 

- En los proyectos a medida que uno desarrolla para un cliente, es importante en el acuerdo o contrato comentar que puede ser necesaria la migración del sistema a una nueva versión. Especialmente cuando vende un proyecto Web que tiene o podría tener una parte móvil.

Es probable que aun sigamos usando una metodología incorrecta ya que en mi caso comence a usar GX en la version 1.x siento que con el paso del tiempo voy descubriendo novedades muy interesantes que se sienten como “sueltas” por el hecho de no encontrar un area de documentacion especifica para estos cambios, sino documentos por separado, que me dejan la idea de “puede que me este faltando todavía 1 punto mas...”

La parte de los servicios creo que es la más dolorosa. Luego me muevo con mucho cuidado con el GAM

Si se minimizaran los bugs en los upgrades se alcanzaría la productividad que promete la herramienta.

En la ev3 nos quedamos en el U13, no seguimos actualizando en la Gx16 u 9 ( y queremos cambiar ) Esto sucede en entornos de vstudio, y de eclipse también. Pero son mas tangibles los errores, Uno ve el código real que ejecuta y hay menos capas para controlar. 

Recomiendo estar siempre en la última versión, de esta manera el cambio de versión es transparente, así comenzamos en GX15 y llegamos a GX16U10.

Tiene sus pro y contras.

No necesariamente migró todo, por ejemplo tengo algunas que aún tengo en evo3, que para hacer pequeños cambios no se justifica migrar

El cambio frecuente y la prueba frecuente de la KB "Modelo" vs la versión BETA, tratando de informar cada error.

Resúmen

Si bien son muy pocos casos y las respuestas son sobre todo de gente que hizo varios cambios de versiones, se nota que el cambio de versión en un trabajo importante y que hay cosas para automatizar. 

Creo que es el caso ideal para los test de regresión que puedan generarse en forma mas o menos automática, de forma que algo que se ejecuta en un sistema, se pueda volver a ejecutar en el otro y poder comparar el resultado. 

Voy a seguir estudiando un poco el tema para ver si puedo formalizar el proceso y buscar posibles automatizaciones. 

Vuelvo a agradecer a quienes contestaron el cuestionario.