martes, 23 de diciembre de 2014

Build & Deploy: Resumen del 2014

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 esfuerzo con la disminución de la tasa de errores

A pesar de no haber logrado una solución para la comunidad, si logramos tener una solución que soluciona alguno de los problemas planteados.

Lo que tenemos ya implementado (para una aplicación con .NET, con GXServer) hace:

Para el Build, si hay algun commit nuevo en GXServer
* Actualización de GXServer, build all
* División de los ejecutables en BuildUnits
* Salvado y envío de Reorganización
* Generación de archivos de comparación de navegaciones
* Envío de mail a todo el grupo de desarrollo de los resultados.
* Generador de borrador de las Releases Notes (lista de commits)

Para los chequeos, dados dos Builds de la aplicación
* Comparación de navegaciones
* Comparación de los WSDL de los servicios publicados.

Para el Deploy
* Instalación del build en el FileSystem
* Adaptación de web.config a client.exe.config al ambiente de instalación.
* Adaptacion de location.xml al ambiente de instalacion
* Configuración de todos los directorios virtuales
* Emisión y configuración de certificados X.509 para pruebas
* Ejecución de scripts de inicialización básica.

Con estas herramientas estamos en condiciones de generar un ambiente de prueba o producción en pocos minutos, cuando se genera un cambio en el sistema.

Por experiencias anteriores, se que este tipo de cambio lleva varios años dentro de la comunidad Genexus, pues las necesidades de las empresas no se dan todas al mismo tiempo y no todos tenemos la misma madurez en nuestros procesos de desarrollo.  Me quedo contento que en un año logramos avanzar bastante, aunque me hubiese gustado haberlo logrado en mas lugares.

Cambiando de tema, este es le POST número 1000 de "Desarrollando desde la trinchera", por lo que brindo por eso.

jueves, 18 de diciembre de 2014

Una KB grande vs Varias KB mas chicas. Manejando fuerzas opuestas

A medida que pasa el tiempo es normal que las empresas automaticen cada vez mas sus procesos, desarrollando  (o integrando) aplicaciones en cada vez mas secciones de las mismas.

Con este crecimiento, aparecen fuerzas opuestas en la forma de modelar la realidad.

Por un lado, se quieren tener base de conocimientos lo mas chicas posibles, para poder entender y tener un desarrollo mas rapido y ágil. Esto implica que se van a tener varias KB para cada uno de los sistemas necesarios.

La otra opción es tener una KB que tenga todos los sistema de la empresa, siempre que sea posible. Esto hace que se tengan KB grandes, lo cual es buenísimo para el manejo del modelo de datos, el mantenimiento de las instalaciones, etc.

Comparación de ventajas y desventajas


VENTAJAS
DESVENTAJAS
Muchas
KB chicas
  • Fácil de entender cada KB
  • Desarrollo Agil
  • Diferentes versiones de GeneXus en cada KB
  • Fácil de instalar cada KB
  • Migraciones mas fáciles
  • No se mantiene la integridad referencial en forma automática
  • Programación rápida
  • Difícil de enteder el modelo global
  • Interfaces entre sistemas mas complejos
  • Proceso de instalación para cada KB (mucho trabajo)
  • Si hay objetos compartidos entre KB (por ejemplo transacciones) es difícil mantener sincronizados entre las KB
  • Dificil mantener propiedades sincronizadas
Una
KB grande
  • Modelo de datos unificado
  • Integridad referencial
  • Interfaces entre sistemas muy fáciles
  • Fácil instalar
  • Build all lento
  • Difícil de probar
  • Difícil de migraciones
  • Difícil de entender la relación entre los objetos de la KB.
  • Programación mas lenta

Parte de estas ventajas y desventajas pueden mitigarse utilizando módulos, dividiendo una KB grande en módulos mas pequeños. Aun faltan algunos ajustes para que esto sea práctico, pero son pasos en la dirección correcta. Por ejemplo, seria bueno poder ver una KB "filtrada" por un modulo, de forma de solo ver los objetos de dicho modulo y los objetos públicos de los demás módulos y nada mas. Esto ayudaría a los desarrolladores a entender una KB grande. 

Un caso que no se puede resolver correctamente usando módulos, es cuando se necesita una versión nueva de GeneXus para una parte del sistema. Por ejemplo, tengo una KB corporativa en GeneXus Evolution 2 y necesito desarrollar un sistema para dispositivos móviles que pueda funcionar sin conexión, por lo que tengo que usar GeneXus Evolution 3. 

Las opciones que tengo, son hacer una migración de toda la KB de Ev2 a Ev3 (lo cual es todo un proyecto en si mismo  y puede llevar recursos que en el momento no se tienen) o desarrollar el sistema en una KB separada en Evolution 3, e integrarla a la KB grande, cuando se realice la migración definitiva. 

Me viene dando vueltas en la cabeza este problema de mantener varias KB en diferentes versiones de GeneXus, pero que comparten un mismo modelo de datos. Tengo algunas ideas (no demasiado maduras) para poder resolver este problema, las cuales son bastante difíciles de implementar. 

Me parece importante conocer y manejar las fuerzas opuestas de muchas KB vs KB centralizada, pues muchas veces el éxito de mantenimiento de sistemas, dependen de como se organicen las bases de conocimiento de las instalaciones. 

lunes, 15 de diciembre de 2014

Don Eduardo

Hace unas semanas, falleció Romualdo Eduardo Gard Figoli, mas conocido como Don Eduardo.
Tenía cerca de 100 años, muy bien vividos. Fue uno de los verdaderos emprendedores de Uruguay, que conocí bastante, por haber trabajado para varias de las empresas de la que era dueño o accionista. 

Partiendo de un origen muy humilde, llegó a ser dueño y comandar importantes empresas de producción de aceite comestibles, cosméticos, molinos harineros,  empresas de trasporte, de alquiler de autos, producción agropecuaria y muchas mas. En los últimos años también  en biocombustibles. 

Una anécdota que lo pinta de cuerpo entero, es que junto con Gustavo y Raúl, teníamos que ir una vez por semana  a Molino San José (a 100 km de Montevideo), pues eramos responsable del centro de cómputos * de todo un grupo de empresas. 
Salíamos temprano, para llegar antes de las 7:00 AM pues teníamos que hacer algunos ajustes en las maquinas antes que entraran la mayoría de los usuarios a los sistemas. 
Casi siempre llegábamos al Molino, y Don Eduardo ya estaba trabajando. Había salido de Montevideo y llegado antes que nosotros!!. 

Recuerdo que al principio de los 90 cuando tenían un proyecto de producción de biocombustibles a partir de oleaginosos, que en aquella época lo veia como algo imposible y se termino de implementar mas de 20 años después. 

Siempre vivió tratando de no llamar la atención, con un perfil muy bajo, siendo un hombre hábil en la negociación y trabajador como pocos. Ejemplos como el de él son necesarios para Uruguay, pues lo considero un verdadero emprendedor.



viernes, 12 de diciembre de 2014

Rebuild All en GeneXus

Me llego una consulta de un colega y dejo la respuesta tambien aca, por si a alguien mas le sive.

Antes de hacer un REBUILD ALL, con GeneXus, es bueno aprovechar y borrar algunos archivos que pueden haber quedado desactualizados.

Lo que yo hago antes de ejecutar un rebuild es ejecutar el BAT

echo ----------------------------------
set dirGX=C:\GeneXus\GeneXusEv2U7
set dirKB=C:\models\ev2\KBdir
echo --- Borrado previo REBUILD ALL ---
del %dirKB%\*.ari /s/q 
del %dirKB%\*.0?? /s/q 
for /f %%i in ('dir /a:d /s /b %dirKB%\*') do rd /s /q %%i
MSBuild /nologo Rebuild.msbuild /p:KBDir=%dirKB%;GXDir=%DirGx%  /t:Rebuild
echo --- TERMINO EN BUILD ALL       ---


Que hace este archivo de comandos? 

Borra todos los archivos *.ARI de la KB (de la version actual y de todas la versiones de la KB). 
Borra todos los archivos donde se guardan referencias entre objetos que tienen extensiones 001, 005, etc). Estos archivos muchas veces quedan mal, cuando se tiene mas de un generador en la KB y son causante de muchos de los errores de compilacion cuando hay objetos que se generan WIN y pasan a generarse WEB y cosas asi. 
Borra todos los directorios que estan en bajo la KB (el directorio de la propiedad TargetPath, mas todos los directorios de usuarios, donde se guardan las especificaciones, el GXLock, etc, etc). 

Es bastante peligroso, por lo que conviene correrlo con cuidado y backups, pero es sano para tener un rebuild limpito. 

Para poder ejecutar el rebuild desde linea de comandos, tengo un proyecto MSBUILD que tiene

<Project DefaultTargets="Rebuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(GXDir)\Genexus.Tasks.targets" />
<Target Name="OpenKnowledgeBase">
   <OpenKnowledgeBase Directory="$(KBDir)"/>
</Target>
<Target Name="Rebuild" DependsOnTargets="OpenKnowledgeBase">
       <BuildAll ForceRebuild="true" CompileMains="true" DetailedNavigation="false" />    
</Target>
</Project>

miércoles, 29 de octubre de 2014

GeneXus y modelo fisico - Herramientas necesarias

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

                     atributo3
          Referential Integrity
                     Referenced by 
                                TABLA3
                     Referenced from
                                TABLA4 
  
          DataView1  (Asociated table TABLA3)
                  attexterno1
                  attexterno4
     
De las tablas, me gustaría poder especificar si es una tabla con alta cardinalidad y que % de crecimiento puede tener, lo cual puede servir para prever el funcionamiento del sistema.

También podría servir para que GeneXus sea algo mas inteligente en la definción de indices.
Por ejemplo, hoy tengo una tabla de parámetros, que tiene solo un registro. Si a la misma le defino atributos con subtipos (por ejemplo, países, monedas, etc) para que solo se puedan ingresar parámetros validos, hoy GeneXus define indices para cada uno de ellos.
Si especifico que una tabla solo va a tener un registro, GeneXus no debería definirle ningún índice.

Desde esta vista de las diferentes bases de datos de la aplicación, se podrían cambiar las propiedades de conexion y regenerar los archivos de configuracion (web.config, client.exe.config, client.cfg, etc).

Para el manejo de servicios web, estaria bueno tener una forma de verlos en forma global.

Web Services
      Servicio1   (SOAP)
               Parameters
                          IN: Parametro1, Parametro2, Parametro2

                          OUT: Parametro4
      Servicio2   (REST)
                 Parameters
                           IN: Parametro5
                           OUT: Parametro6

 [GENERATE location.xml]    [EDIT location.xml]   [Test WS]

Desde aqui se podria generar el archivo location.xml y también editarlo.
Seria bueno poder probar los web services en forma interactiva..

Otras cosas que podria tenerse en el modelo fisico, es poder modelar los diferentes ambientes de ejecucion de un mismo juego de ejecutables (desarrollo, pruebas, produccion, etc) y poder almacenar ahi las reglas de transformacion para adaptar los archivos generados por GeneXus.

El ambiente de desarrollo y el de pruebas, tendrian los mismos ejecutables, pero diferentes archivos para los Themes, diferentes location.xml, diferentes web.config, etc.

Se pueden almacenar los archivos directamente en cada ambiente o se puede poner las reglas de transformacion que permita cambiar el web.config que genera GeneXus y cambiarlo por el web.config que se necesita en el nuevo ambiente (por ejemplo, cambiando usuario / contraseña por otros.  Lo mismo se puede hacer con los temas.

Hay muchas herramientas posibles  que pueden y deben hacerse, para facilitarnos la vida.