Cambio de versión de GeneXus - Paso 3 : Build exitoso de la KB en la nueva versión

Paso 3 del ciclo Metodología para el cambio de versión de GeneXus 



Ya tenemos una nueva instalación de GeneXus completa y operativa y una lista primaria de las cosas que vamos a tener que testear. 

Ahora llega un paso que puede ser sencillo, que es el de lograr un BUILD ALL exitoso en la nueva versión.  Dependiendo de cuan grande sea el salto entre versiones de GeneXus, puede ser desde muy difícil a trivial. 

La idea aca es trabajar en una COPIA de la KB original. La forma de lograr esta copia puede ser CLONANDO la KB original o volviendo a bajar la KB en caso que se utilizando GXServer. 

Habitualmente lo que hago en esta etapa es: 

  • Si uso GXServer  -->     Create KB From Server
  • si no                     --->    Clonar la KB original usando KBClone 
  • Export de todos los objetos y la KB (para recurrir en caso que algo salga mal). 
  • Abrir la KB con la nueva versión de GX 
  • Crear una versión congelada en la nueva KB (para volver en caso de meter la pata y tener una forma de saber que objetos cambie)
  • (Paso opcional) Importar todos los objetos sobre si mismo. Esto obliga a salvar y volver a validar todos los objetos. 
  • Cambiar la propiedad de Reorganize Server Tables en NO (para no hacer reorganizaciones sin querer, por ahora la base de datos, se sigue reorganizando desde la KB vieja). 
  • Create Database Tables (para asegurarse que no hay inconsistencias en la base de datos).
  • Build All 
  • Corregir todos los errores y nuevos warnings del Create Database y Build All (de ser posible en la KB Original, sino en la KB Nueva). 
Repetir todas los pasos necesarios hasta tener un build all exitoso. 

Una vez logrado un build sin errores, es conveniente ejecutar un KBCompress que comprime la KB, defragmenta los indices en la base de datos SQL Server de la KB y ademas hace algunos chequeos de integridad de la KB. 

Limpieza (opcional) 

Algo que aparece mucho en esta etapa, es que hay en la KB algunos objetos que no son necesarios y que podrían borrarse. Hay que evaluar si es un buen momento para hacer limpieza.  Por un lado evita corregir cosas que no se usan, pero por otro lado aumenta el riesgo del cambio de versión, pues podemos borrar cosas que se necesitan. 

Cosas que pueden borrarse sin mucho riesgo: 
  • Atributos que no están en ninguna tabla
  • Variables definidas y no usadas en los objetos
  • Objetos no alcanzables

Conclusiones - Paso 3 - Build exitoso

La salida esperada de esta etapa es una KB en la nueva versión, sin errores y optimizada como para poder empezar a hacer las comparaciones entre la aplicación vieja y la nueva. 

Es una etapa que puede automatizarse muchísimo, pues con poco esfuerzo, se puede crear un script que haga todos los pasos (menos el de corregir los errores)

Herramientas que se pueden utilizar en esta etapa. 





 

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

Aplicación monolítica o distribuida?

Imagen
En los últimos tiempos, hemos escuchado muchas opiniones sobre cómo es conveniente diseñar nuestras aplicaciones, desde el punto de vista de su arquitectura en la ejecución.  Históricamente las aplicaciones eran monolíticas (una aplicación que se instalaba en una computadora y hacia todo lo que necesitaba) y en forma más recientes se esta optando por hacer aplicaciones distribuidas en varias computadoras, dividas en servicios independientes (algunos lo llaman microservicios). Al ser tan variadas las aplicaciones que realizamos, es claro que no hay una solución optima para todos los casos, sino que tenemos que adoptar (y adaptar) la arquitectura que mas nos convenga para cada caso. También hay que entender que entre una aplicación monolítica y una aplicación totalmente basada en microservicios hay una gran variedad de combinaciones posibles, pues no hay que hacer binaria la elección. El problema.  Es una realidad, que los sistemas de información cada día abarcan más...
Leer más

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

Imagen
Esta teoría no es mia, sino que se la escuché por primera vez a Andrés Acosta. Varias generaciones de niños en Montevideo, crecieron viendo un programa de televisión llamado Cacho Bochinche, donde había un juego donde habia que patear penales a un arco con un golero de goma. La falla fundamental del mismo, es que en vez de premiar a quienes metian goles, se premiaba a quienes logran pegarle un pelotazo al golero y tirarlo al suelo. O sea, quien pateaba en forma mas burda y fuerte, era el ganador. Para complicar mas la situación, muchas veces cuando un niño no lograba voltear al muñeco, el animador del programa (el inefable Cacho de la Cruz que hacía de juez), le pegaba o empujaba al golero para tirarlo al suelo y de forma de dejar contento al niño que estaba haciendo pucheros. Por lo tanto se promueven varios valores, que han logrado calar muy profundo en las generaciones de niños telespectadores: a) Es bueno patear fuerte y al medio b) Tirar a colocar es de maricones c) El golero es ...
Leer más

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

Imagen
Algunas veces en el código tenemos que poner una fecha como constante. Una alternativa a esta función, es usar el formato #yyyy-mm-dd# , como constante. Por ejemplo:   &InitialDate =# 2007 - 01 - 01 # &DateTime = #2020-01-01 10:00:00# Esta funcionalidad está desde hace varias versiones, pero por algún motivo, no se usa demasiado. He visto que usan ymdtod(2020,01,01) que para mi queda bastante mas confuso. Más información en el siguiente link: Date Constants
Leer más