Desarrollando desde la trinchera

Existen muchas forma de organizar el desarrollo de aplicaciones GeneXus. Esta variedad de escenarios, hace que a veces se dificulte el discutir sobre herramientas o procedimientos generales, pues algunos son buenos para un caso, pero no aplican o no son convenientes para otros escenarios.  Quiero hacer una lista de cada uno de los que tengo identificados, para tratar de explicar pros y contras de cada uno.  KB Monolítica - Empaquetado Monolítico - Instalación monolítica en una sola maquina Es ideal para aplicaciones chicas, que no tengan requerimientos grandes de escalabilidad. Permite mantener sencillo el desarrollo y es como conviene empezar todos los desarrollos.  El empaquetado es sencillo y la puesta en producción también. Hay que testear toda la aplicación para ponerla en producción.  KB Monolítica - Empaquetado Monolítico - Instalación en mas de un nodo con base de datos compartida Una unica KB, la cual se empaqueta en un único package, pero se instala en mas ...

El esquema general de desarrollo e instalación de aplicaciones desarrolladas con GeneXus es así:  Las treas que tenemos son: Build.  Partiendo de una KB actualizada/modificada se especifican, generan, compilan todos los ejecutables de la aplicación. Se hace la reorganización de la base de datos necesaria y se salva dicha reorganización. Esta reorganización seria bueno poder ejecutarla solo con un script en forma automática. Estaria bueno tener un archivo build.info cuyo contenido fuera el identificador de version del ultimo build exitoso y que ademas tenga GXVer: 16.U9.141222 KBVer: 20200610165879 BuildStart: 2020-06-10t17:01:45 BuildEnd:  2020-06-10t18:45:26 En caso que estemos en un ambiente de CI/CD, si el GXVer del build.info existenten del build anterior y son diferentes, se puede lanzar automáticamente un rebuild all, en vez de un build all.  El archivo build.info, se  puede renombrar o borrar al empezar la tarea, de forma que las tareas siguientes s...

Problema:  Tengo una KB GeneXus, con una tabla con 2 millones de registros que tiene un campo AttSec N(3) y debe cambiarse a C(3) (si se quiere, puede tener otro nombre). Tabla ====== *Clave       N(10) AttSec       N(3) otros atributos El sistema esta funcionando 24x7, se instala en varios nodos (en un NLB). La aplicación deberá estar operativa siempre, no se puede bajar ni bloquear. Se pide: ¿Cuales son los pasos de desarrollo e instalación que debo seguir para lograr instalar en todos los nodos la aplicación operativa con el atributo C(3)? Solución: Si alguien se anima, la escribe en los comentarios. Yo publico la mia en unos dias. UPDATE = 04/07/2017=============================== MI SOLUCIÓN:  Lo primero que haría seria ver si la tabla es usada solo por mi aplicación o también es accedida por alguna aplicación externa. Para simplificar, supongamos que solo es accedida por la aplicación GeneXus. Estado Inicia...

Los colegas de Datys  de Cuba, me hicieron una demostración de las herramientas que utilizan en su proceso de desarrollo con GeneXus para hacer integración continua. Han logrado integrar muy bien diversas herramientas para la realización de controles de calidad de su codigo y pruebas unitarias al mismo. Utilizan Cruise Control, GXUnit, bibliotecas de control estático de código para Javascript y CSS, controles propios de variables no usadas, atributos huérfanos y demás. Me pareció una muy buena implementan y también esta bueno el cambio a la  interfaz web que le hicieron al Cruise Control. Les dejo un video para puedan apreciar el producto funcionando. Es bueno ver que crece el grupo de empresas interesadas en este tipo de temas, para resolver el proceso completo de desarrollo de aplicaciones con GeneXus. Tenemos que aprender a cooperar mas para lograr avanzar mas rápido.

Hace un tiempo que buso  algunos indicadores sencillos que permitan medir que tan bien (o mal) está el proceso de desarrollo, midiéndolo en su totalidad. Lo ideal seria bueno poder tener algo que mida desde la captura del requerimiento, análisis, diseño, codificación, pruebas, instalación, soporte y desinistalacion y borrado cuando no se use mas. Encontrar indicadores para todo el proceso no es fácil, pero hay algunos que son mas fáciles de medir y ayudan a entender que tan bien evolución un grupo de trabajo. Un indicador que me gusta mucho es el que mide el tiempo que lleva crear el ambiente de desarrollo para una maquina recién instalada hasta el primer build all exitoso. La idea es tomar la cantidad de horas que lleva hacer los siguientes pasos: 1) Instalar la versión de GeneXus que se necesite 2) Instalar todos los UC / Extensiones necesarios y sus dependencias 3) Bajar la KB del Server (o importar xpz) 4) Create database sin errores 5) Build all sin errore...

Pasó el GX25 y estuvo muy bien. Como habia comentado en el post anterior , mi participación este año era en el Cafe con Deployment, donde nos juntamos para intercambiar ideas sobre las tareas de Deploy. No quede conforme en la forma de transmitir los productos anunciados y las tareas realizadas en el area de deploy. Es un tema muy amplio y cada empresa tiene realidades diferentes, por lo que es imposible resolver todos los casos de primera. Los pasos que se estan haciendo son: Crear las tareas basicas para poder realizar deploy de aplicaciones.  Solucionar el deploy de aplicaciones WEB y SD simples Solucionar el deploy de aplicaciones mas complejas Tareas Basicas de Deploy.  Hasta hoy, para poder instalar una aplicacion WEB habia que usar el Deployment Wizard para java y el XCopy installation para .NET.  Ambas herramientas estaban algo desactualizadas pues no llevaban todo lo que se necesitaba, por lo que la tarea de instalación se hacia muy complicada....

Mas o menos a esta altura del 2013, empezaba a trabajar con el tema del Build & Deploy de aplicaciones GeneXus. En un año logramos avanzar bastante en el tema, logrando tenerlo formalizado, habiendo detectado las dificultades y limitaciones actuales y tenemos desarrolladas varias herramientas para facilitar la tarea de la realización de procesos de build y deploy automatizados. Con dichas herramientas logramos bajar el tiempo necesario para tener una versión ejecutable de nuestra aplicación y también la configuración del ambiente. Lo que no logré fue que el tema interesara dentro de la comunidad, al menos como yo lo había imaginado.  No tuve ni la fuerza ni el liderezgo suficiente como para interesar a actores claves dentro de la comunidad como para que dedicaran recursos para lograr una solución que funcione para mas de una empresa. Quedan como tareas pendientes: * mostrar las ventajas de este tipo de herramientas en el desarrollo agil de aplicaciones * justificar el...

Comentando el post anterior , un colega me preguntó que tipo de herramientas podrían desarrollarse para el manejo de modelo físico, dentro de KB GeneXus. Lo que me gustaría es poder ver el modelo físico que hoy GeneXus intenta ocultar a los desarrolladores, pero que tiene mucha de la información necesaria. Una vista interesante, seria poder ver las tablas por Data Store DataStore1     Tables/DataViews          TABLA1               * atributo1                 atributo2                 atributo3              INDICES                  Indice1                       atributo2 (desc)                  Indice2             ...

En la interna, seguimos avanzando en entender y especificar el proceso de Build y Deploy de aplicaciones Genexus.  Va tomando forma y creo que ya tenemos algo implementable. Tenemos un primer prototipo operativo y estamos en la etapa de generalizarlo para otras KBs. Aun queda mucho trabajo por delante, pero creo vamos bastante bien. Documente el proceso en el Wiki de la comunidad y tambien lo pongo aca. Build En el build, dado una KB/Version/Environment  si usa GXServer, se ejecuta un Update y se recupera el ultimo numero de Commit,  Se saca una lista de los Commits y los objetos modificados en los mismos y se lo guarda como documentacion (Desde el commit anterior hasta el commit actual) Si no usa GXServer se incrementa el numero de build Si no hay nuevo commit solo envio un mail.  Se hace un Build All  Se salvar la Reorganizacion Se recorren todos los main (y todos los llamados) que tienen especificado el DeployLocation y se lo separa en d...

En el contexto de proyecto de mejora de Build & Deploy de aplicaciones GeneXus , me ha permitido estudiar algunos productos y tecnologías interesantes. Docker - Es un empaquetador/contenedor de aplicaciones que facilita que una aplicacion hecha en un notebook pueda ser desplegada en un ambiente de pruebas primero y luego en el ambiente de produccion, sin cambios. Me resulto interesante. Packer - Permite generar maquinas virtuales identicas para diversas plataformas, a partir de una definicion unica de la misma. Entre otras plataformas, soporta generar containers docker. OpenStack es un sistema operativo para la nube, que permite el control de nuesstras aplicaciones, haciendo mas fácil la instalación y administración de las aplicaciones desde una interfaz web. También es soportado por Packer.  VirtualBox - Manejador de maquinas virtuales de Oracle, que funciona bastante bien para poder generar maquinas virtuales en el equipo. Con productos y tecnologías pa...

Hace unos años, las aplicaciones Genexus podian representarse con el siguiente esquema simple: El origen de los datos, era una base de datos y se tenia salida en forma de pantallas, reportes, archivos de texto, mails, etc. Cuando teníamos un cambio en la aplicación, nos alcanzaba con analizar que era lo que cambiaba en las tablas de la base de datos y debíamos comprobar que las salidas fueran las esperadas.  También era conveniente comparar las navegaciones de los objetos internos, para ver que los cambios fueran los esperados y con eso,  nos resultaba facil el manejo de los cambios de version de nuestras aplicaciones.  Las aplicaciones actuales, son bastante más complejas, y pueden representarse en forma simplificada como: Cual es la diferencia?  Seguimos teniendo la base de datos y las mismas salidas, pero se agregaron otras fuentes de datos (generalmente web services)  y a su vez nuesta aplicacion paso a ser fuente de datos de otras ...

Para cualquier empresa que dependa del software para subsistir (casi el 100% de las empresas), es importante no estar atado a ningún proveedor de forma que si dicho proveedor tiene problemas o se dificulta me relación con el, pueda seguir funcionando como empresa sin afectar el negocio central de dicha empresa.  Por eso, es bueno tener la libertad de cambiarme de sistema operativo, de base de datos y hasta de plataforma. El poder hacer dichos cambios me da la libertad de poder adaptarme a los cambios y aprovechar mejor las oportunidades que se presentan.  Los que desarrollamos con GeneXus tenemos mayor grado de libertad que quienes desarrollan con otras herramientas, pues el cambio de alguna de estas características no es tan costoso como en otras plataformas.  Desde hace un buen tiempo, se esta dando una transición de tener sistemas locales, a la ejecución en la nube, generalmente virtualizados.  Lo que antes acostumbramos a instalar en forma loca...