Desarrollando desde la trinchera.

En esta etapa hay que hacer una lista de cuales serian los chequeos que hay que realizar y comparar entre la versión vieja y la versión nueva de la aplicación. Release Notes.  Leer las Release Notes de la versión e identificar que es lo que pueda afectar a mi aplicación.  ¿Que hay que buscar?.  Hay que leer bien todas los SACs que están en la sección "Consideraciones de compatibilidad"  de todas las Releases Notes para encontrar que nos puede afectar. Listar los objetos que puedan verse afectados por estos problemas de compatibilidad.  User Controls En el paso anterior, cuando generamos el entorno de desarrollo, comparamos la instalación vieja y la nueva de GeneXus y podemos ver los UC que cambiaron. Listar los objetos que usen los UC que cambiaron.  API de la KB.  Agregar a la lista de objetos a probar:  Objetos main con protocolo HTTP (comparar respuestas) Objetos main con protocolo SOAP (WSDL y comparar respuestas) Objetos main command line (probarlos).  Conviene hacer

La primera etapa que hay que lograr en un proyecto de cambio de versión, es una instalación de GeneXus que tenga todo lo necesario para poder desarrollar, especificar, generar, compilar, empaquetar, instalar y probar la aplicación en la nueva versión, sin errores.  Pre-requisitos.  Leer con cuidado todos los pre-requisitos necesarios para la nueva versión e instalarlos. La información de esto, puede estar desparramada por varias paginas y diferentes sitios web.  Los pasos que realizamos aquí son:  Bajar la nueva versión y otras cosas necesarias.  GeneXus Ir al Download Center de GeneXus y bajar la nueva versión y paquetes relacionados. En mi caso tengo que bajar  GeneXus GeneXus Platform SDK GAM para Oracle GXFlow para Oracle  Releases Notes de la versión Bajar versiones compatibles de los patrones utilizados En caso de usar algún patrón de la comunidad, es necesario bajar un instalador compatible con la versión.  Workwithplus, K2btools, Ignia, etc, etc.  Control de Usuario (UC) comp

Hace unos días hice un relevamiento para conocer como manejaban los colegas de la comunidad los cambio de versión . Los que contestaron el cuestionario, en su mayoría hacen cambios frecuentes, actualizando desde versiones recientes.  Voy a tratar de resumir como manejamos nosotros los cambios de versión para formalizar el proceso. Hay muchos pasos que llevan mucho tiempo y son tareas repetitivas y son ideales para automatizarlas.  Etapas.  Cada proyecto de cambio de versión es diferente y ahí radica la dificultad de su formalización.  Voy a tratar de explicar en un post diferente cada uno de los pasos que realizamos:  Crear el nuevo entorno de trabajo con la nueva versión Identificar y planificar que controles vamos a hacer Build exitoso de la KB en versión nueva Hacer una instalación de la versión nueva Comparar versión vieja con versión nueva Validar y corregir warning, errores y diferencias Desarrollo con la nueva versión Instalación en Producción Eliminar Instalación de producción

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

En las últimas versiones de GeneXus han introducido varias mejoras para acelerar el proceso de Build All de KB grandes.  Para probarlo hice un script para hacer un rebuild all de una KB de más de 10.000 objetos en una version anterior de GX y la nueva version.  Tiempos de Rebuild all en KB con mas de 10.000 objetos.   GeneXus 16 Upgrade 7   03:50 horas  GeneXus 16 Upgrade 10  03:24 horas  Diferencia   26 minutos Compilación con MSBUILD.  En el Upgrade 10 (*), se hizo oficial la compilación utilizando MSBuild en vez del GXExec para el generador C# .  Tiempos de Rebuild all KB con mas de 10.000 objetos  GeneXus 16 Upgrade 7 compilando con  GXExec 03:50 horas    GeneXus 16 Upgrade 10 compilando con MSBuild 02:47 horas  Diferencia   63 minutos Los tiempos fueron medidos en un notebook i7 con 16Gb de RAM usando la misma KB y el mismo disco SSD, usando el Generador C#.  Es un buen motivo para evaluar pasarse al último Upgrade pues es bastante más rápido.  (*) En Upgrade 7 se podía usar la f