Cambiar de version de GeneXus en KB conectada a GXServer
Cuando tenemos una KB conectada a GXServer, surge la dificultad, que hay que migrar "simultaneamente" la KB local y la KB remota a la nueva version de GeneXus.
El proceso de pasar de una version a otra en KB grandes, puede ser mas o menos trabajoso, dependiendo de muchos factores, pero puede demorar varios meses entre migracion, pruebas, ajustes, arreglos e instalacion de la nueva version.
Algunos factores que influyen en esta migracion son:
* External Objects utilizados
* User Controls Utilizados
* Versiones de sistema operativo, base de datos, servidor de aplicaciones web, etc.
Durante el periodo que se realiza la migracion, si bien tratamos de minimizar los cambios que se realicen al sistema, siempre hay cambios obligatorios que hay que realizar.
El escenario planteado es el siguiente:
KBEvo3 - hace ajustes a la aplicación.
KBGX15 - hace cambios debidos a la migración
Hay que mantener la historia de todos los cambios y la historia de los Commits en el server.
La mejor solucion que hemos encontrado es hacer lo siguiente, tomando como ejemplo una migracion de Evo3 y GX15.
Paso 1 - Copiar la KB en GXServer.
Usando el GeneXus Server Storage Migrator Utility copiar la KB de GXServer y copiarla al nuevo server.
Con esto se va a mantener la historia de los commits y las revisiones de todos los objetos. Ademas se va a mantener el GUID de la KB y sus objetos (esto es importante para el paso posterior).
Paso 2 - Crear la KB en GX15 y corregir errores.
Hacer un Create KB from Server y crear la KB en GX15 . Corregir los errores y lograr un build all exitoso. Probar la aplicacion y corregir los errores encontrados.
Esta etapa puede llevar mas o menos tiempo dependiendo del tipo de errores que se encuentren.
Paso 3 - Traer cambios de Evo3 a la GX15.
Este es le paso que yo veía mas difícil y no sabia como hacer. Gonzalo Arcos de GeneXus (GRACIAS!!!) , me pasÓ el pique que si no había cambiado el GUID de los objetos ni de la base de la KB, podía funcionar cambiar el GXServer al que se conectaba la KB local y hacer un UPDATE.
Esto lo hago con un proyecto msbuild que haga:
<Project DefaultTargets="
<Import Project="$(GXDir)\Genexus.
<Import Project="$(GXDir)\Genexus.
<Target Name="OpenKnowledgeBase">
<OpenKnowledgeBase Directory="$(KBDir)"/>
<SetKnowledgeBaseProperty Name="ServerURI" Value="http://Evo3.
<UpdateFromServer ServerUserName="$(
<SetKnowledgeBaseProperty Name="ServerURI" Value="http://GX15.
</Target>
</Project>
Aunque es bastante sencillo, lo explico:
Se abre la KB buscando en el directorio que esta en la variable de ambiente KBdir, que apunta a la KB local GX15
Le cambio la nombre del servidor en Team Development al servidor de Evo3
Hago un Update desde el server viejo, sobre la KB GX15 local
Vuelvo el nombre del servidor al valor que tenia al principio. Y subo esos cambios al server (esto no esta en el script).
Haciendo esto, termino con una KB en GX15, con la historia de los Commits en el server y los cambios de Evo3 y los cambios hechos para la migración todo en una misma KB, y con control de que nada se pasa por arriba.
Que dificultades puedo encontrar?
Puede pasar que en Evo3, me modifiquen objetos que también fueron modificados en GX15.
En la mayoría de los casos, se va a hacer un merge de los objetos.
En caso que no fuera asi, podria hacer un export de la Evo3, importar en GX15 y volver a hacer en forma manual los cambios necesarios para la migración.
Si bien no lo he utilizado en una migración "de verdad", si hice pruebas en laboratorio y ha funcionado muy bien.
Soluciona en forma (mas o menos elegante) el problema de mantener una KB sincronizada con 2 versiones de GeneXus por un periodo limitado de tiempo.
Muy bueno!
ResponderBorrarTenemos una kb em gx ev 2u4 que está colgada en el tiempo.
Usare esto, muchas gracias.
Sandro:
ResponderBorrarEstaria bueno si lo usas que comentaras como te fue, asi aprendemos todos.
Gracias,
Enrique
Hola Enrique, muy interesante el artículo como siempre. Estamos encarando una migración de Ev3 a 16 y necesitamos por unos meses desarrollar funcionalidades nuevas en la KB migrada a 16 y en paralelo continuar el mantenimiento de la aplicación en la KB de Ev3, "actualizando" cada tanto la KB migrada con lo desarrollado en la de Ev3 para finalmente dejar productiva la KB en 16. ¿Te parece que esto que explicaste nos serviría para actualizar regularmente de una KB a otra o bien que nos recomendás?
ResponderBorrarDesde ya. muchas gracias por tu respuesta
Hola, me gustaria saber con quien hablo.
BorrarEn situaciones parecidas a la tuya , lo que hemos hecho, es que todo el grupo de desarrollo, seguia con Ev3 y subia los cambios a Ev3.
Teniamos una maquina de Build, que tenia la KB en Evo3 y otra en GX16, apuntando a GXServer en Evo3.
Esto nos permitia seguir el desarrollo en Evo3, mientras comparabamos las diferencias entre la aplicacion en Evo3 y GX16. Las diferencias de funcionamiento, tratamos de corregirlas en Evo3. En caso de no ser posible, se arreglaban en GX16 (fueron pocas).
Cuando vimos que la version GX16 estaba madura para poner en produccion, migramos la KB en el server de Evo3 a GX16 y todo el grupo empezo a desarrollar tambien con GX16.
Fue un proceso que llevo algunos meses.
Disculpas, no tenía el perfil compartido. Es una buena opción esa que planteas. En caso de no ir por esa: ¿como ves el ir pasando paquetes de objetos de funcionalidades terminadas por XPZ de Ev3 a 16?
BorrarEs una metodologia posible, pero peligrosa, porque al pasar por xpz es muy facil perder correcciones porque se pasen por arriba cambios de otra persona.
BorrarHay que ser muy riguroso en la defincion de los "paquetes de objetos" para que esta metodologia funcione bien y que no queden objetos modificados por el camino.
Lo que nosotros hicimos, durante el periodo en el cual tuvimos las dos KB (evo3 y gx16) en paralelo, pusimos en produccion desde las 2 KB (en directorios virtuales diferentes) por ejemplo, teniamos los webforms en la evo3, pero todos los web services y procesos batch, de la gx16 (que aun seguia conectada al server Evo3).
De esa forma, bajamos el riesgo de poner todo en produccion de una sola vez.