viernes, 22 de agosto de 2014

Build & Deploy - Avances


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 directorios diferentes. 
  • Se copian los directorios generados en el paso anterior + Archivos Fijos extra GeneXus y se lo salva con un numero de Build en el archivo Build.info
  • Envio de mail - Informa como termino el build, si hay errores  y envio el log completo de la corrida 

Generacion de archivos de Control

En este paso se generan los archivos necesarios para hacer el analisis de impacto de este build contra el que esta instalado en produccion.
Las tareas a realizar son
  • Recuperar los WSDL de los Procedure SOAP que publique mi aplicacion.
  • Lista de mains por Deploy Location
  • Navegaciones de los objetos (para el comparador de navegaciones)
  • Analisis de seguridad (SecurityScan)
  • Objetos modificados en estado Pending Commit
  • WebServices consumidos por mi aplicacion 
  • Servicios REST

Control Pre-Deploy

Esta tarea consiste en hacer un analisis de impacto del build que estoy por instalar. 
Compara el Build Instalado (del cual debo tener copia local) con el nuevo Build, comparando las navegaciones (de objetos modificados y de objetos que no cambiaron, pero si cambio su navegacion), compara WSDL, listas de ejecutables main. Con esto el encargado del deploy define si ese BUILD es instalable o no. 
Controles que se realizan
  • Hay cambio en algun WSDL / Web Service SOAP?
  • Hay cambios en los servicios consumidos?
  • Hay cambios en los servicios REST
  • Se agrego o se quito algun ejecutable?
  • Cambio la navegacion del algun objeto no modificado?

Deploy. 

Es la instalacion definitiva de la aplicacion en las maquinas de produccion. Para esto cada uno de los directorios generados en la etapa de build va a ser instalado en una ubicacion determinada. Se tendra un juego de archivos de configuracion para cada uno de los ambientes de deploy (por ejemplo, testeo manual, testeo automatico, pre-produccion, etc)
En esta etapa:
  • Se salvan lo que estaba instalado anteriormente (para volver atras en caso de un fallo)
  • Se ejecutan las reorganizaciones necesarias
  • Se copian los nuevos programas
  • Se adaptan y se copian los archivos de configuracion para dicho ambiente

Configuración

Posterior a la etapa de Deploy, hay una etapa de configuracion, que realizara:
  • Configuracion de Directorios Virtuales / Webapp
  • Cambios en seguridad

viernes, 15 de agosto de 2014

Tecnologias interesantes para Build & Deploy

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 parecidas a estas, deberiamos poder facilitar el deploy de nuestras aplicaciones en la nube, para soportar diferentes proveedores de servicios en la nube, como comentaba en el post para lograr mayor independencia del proveedor de maquina virtuales.

jueves, 14 de agosto de 2014

KBDoctor : Ejemplo de limpieza de una KB en producción.

Me pasaron una KB que esta en producción en GeneXus X Evolution 2, mantenida por dos desarrolladores, para hacerle una limpieza con el KBDoctor.

Por lo que vi, es una KB bien mantenida y bien desarrollada, sin demasiado cosas históricas o basura.

Me pareció un buen ejemplo para medir los resultados de una limpieza de la KB, eliminando todo lo que no se usaba.

El objetivo es llegar a una KB que tenga los mismos ejecutables que tenia la original, y funcionalmente equivalente a la anterior, pero sin ningún objeto, tabla o atributo que no sea util para la aplicacion.

Para esto, usé el KBDoctor para lograrlo. Partía de una KB sin errores de especificación, ni de generación por lo que el trabajo estaba bien avanzado.

Los pasos que realice fueron:

1) Hacer un backup de la KB.

Cree una versión congelada de la KB antes de la limpieza, para poder volver a recuperar algun objeto en caso de necesidad.  También hice un export de todos los objetos de la KB, de forma de tener una alternativa en caso que la KB se corrompa por algún motivo.

2) Borrar todas las variables no usadas en la KB.

Ejecute la opción que recorre todos los objetos y borra aquellas variables no referenciadas en el código o en el layout.

3) Borrar todos los objetos no referenciados.

Al borrar todos los objetos no referenciados varias veces, se logra eliminar todos aquellos objetos que no son main y que nadie esta invocando.  Esta KB no tenia calls dinámicos, por lo que fue facil ejecutar esta opción.

4) Marcar con GenerateObject = False a todos los objetos no alcanzables.

Como es una KB que tenia aplicado el pattern WorkWith, habia muchos objetos que si bien no eran alcanzables, estaban siendo referenciados, pues se referenciaban en forma circular.
Estos objetos no se pueden borrar en el paso anterior, porque alguien los llama, pero nunca nadie los va a ejecutar.

5) Reporte de aquellas tablas que no se usan.

Con el reporte que se invoca de la forma


se obtiene un reporte de que los objetos que realizan las diferentes operaciones (update/insert/delete/read) en las tablas.
Aquellas tablas que solo son leidas, hay que analizarlas para ver si se pueden eliminar del sistema.

Una vez que se tiene la tabla candidata, se puede ejcuar la opcion "Table - Transaction Relation" y ver que Transacciones son las que colaboran en la generacion de dicha tabla y eliminarlas (si fuera posible).

Esto puede traer algunos inconvenientes de normalizacion que hay que solucionar en forma manual.

6) Borrar subtipos no usados

 En el paso anterior, al haberse eliminado tablas, es necesario hacer un analisis de subtipos y borrar todos aquellos que ya no son necesarios.  Para este paso, es indispensable conocer el modelo de datos al cual se quiere llegar.

7) Eliminar atributos que no están en ninguna tabla.

La opcion Attributes/Remove Atributes without table permite borrar todos aquellos atributos que no estan en ninguna tabla y elimina tambien las referencias en variables que dicho atributo pueda tener.
Si esta referenciado en subtipos o en dataview sin tabla asociada no los borra los atributos.

8) Analizar cuales son los objetos no alcanzables.

En el paso 4) se genero una categoria KBDoctor.Unreachable, que contiene todos los objetos que no son alcanzables.
Hay que analizar cada uno de estos objetos y ver si son necesarios o pueden ser eliminados.

9) Reporte de atributos que solo estan en trasacciones.

Analizar el reporte de todos los objetos que solo estan en trasacciones, ayuda a detectar algunos atributos que alguna vez fueron utiles y ya no son utilizados en la KB. Borrarlos ayuda a no cometer errores.



Si la transaccion es no alcanzable, se puede sacar el atributo de la estructura  sin problemas.
Si la transaccion es alcanzable, hay que analizar si tiene sentido seguir teniendo dicho atributo, pues puede ser un atributo util, para consultas (por ejemplo, teléfono de un cliente, aunque es raro que nadie los use para nada mas).

10) Volver las transacciones a sus partes default. 

A todas aquellas transacciones que no pueden borrarse (porque definen tablas que se utilizan) pero no son referenciadas por nadie, volver todas sus partes al estado default. Esto significa que los formularios win y web, seran los por defecto y no tendran reglas ni eventos.
Luego de hacer este paso, volver a correr el que borra los objetos no referenciados.

NOTA IMPORTANTE:

Luego de cada uno de estos pasos hay que hacer un build all y corregir todos los errores que aparezcan.

KBDoctor no tiene en cuenta ningún proceso externo a la KB que esta analizando, por lo que si hay otros programas que usan la misma base de datos o los programas desde fuera de la KB, los mismos pueden verse afectados. Por ejemplo, hay que tener en cuenta stored procedures de la base de datos, scripts que puedan ejecutarse en la misma, triggers, etc.
También pueden haber Data Views de otras aplicaciones que usen los atributos que en esta KB ya dejaron de usarse.


Los números, antes y después de la limpieza son:

Números antes y después de limpieza con KBdoctor
Para que tomarse todo este trabajo?  Que ventajas tengo? 

Una de las principales ventajas, es que teniendo en la KB solo los objetos necesarios, el mantenimiento de la misma es mas facil y rápido. Solo hay que corregir aquellos objetos que se usan y no objetos inútiles. 

Otra beneficio es que teniendo una KB "limpita", es mucho mas fácil detectar cuando se introducen objetos de prueba o con problemas. Por ejemplo, si logramos eliminar todos los warnings de mi aplicación, apenas alguien introduce un objeto que tiene algun warning, el mismo puede ser corregido. 
En KB con objetos viejos y que no se usan, es muy común que los programadores no se preocupen que tengan warnings, pues "ya no se usa mas". Esto poco a poco rebaja la calidad de los controles que se hacen en la KB. 

Otra ventaja que puede medirse, es que los tiempos de especificación/generación son un poco mas rápido. 
En el KB del ejemplo, que es una KB chica de 1500 objetos, los tiempos de REBUILD ALL, fueron. 


El rebuild se hizo  casi 5 minutos mas rápido. Podríamos pensar que los build all también se verán afectados en un porcentaje similar (aunque es mas difícil de probar), por lo que podríamos asumir que los ciclos de especificación/generación serian algo asi como un 20% mas rápido, lo cual es una mejora muy buena desde mi punto de vista. 

El proceso de limpieza lo hice en un dia de trabajo y otro medio dia adicional para tomar los tiempos, contar los objetos, escribir este post, etc.  Las ventajas de la limpieza son bastantes para el trabajo que da hacerla y los resultados se prolongan en el tiempo. 

** “Ningún animal fue lastimado durante la realización de este post” **



martes, 12 de agosto de 2014

Análisis de Impacto ampliado o manejo del API de mi aplicación.

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 aplicaciones.

Que consecuencias tiene esto? 
El analisis de impacto anterior que solo abarca la base de datos, se torna insuficiente para analizar cual sera el impacto de la nueva version. 
Debo agregar un analisis de cuales son los servicios externos que cambiaron y cuales de los servicios que mi aplicacion publica cambiaron, para poder avisarle a quienes los consumen. 

Un buen ejemplo de esto son las aplicaciones generadas por GeneXus para Smart Devices, que pueden tener una base de datos local (cuando son offline) y tambien recuperan y guardan datos de servicios REST. Cuando haga una nueva version, tengo que saber si los servicios cambiaron para saber si debo o no instalar una nueva version en los dispositivos moviles. 

Otro ejemplo, es cuando una aplicacion WEB, publica web services SOAP para que sean consumido por los demas. 

Cual seria un analisis de impacto "ampliado"?
Asi como en IAR de hoy, compara la estructura de la base de datos actual y la futura y muestra las diferencias, en analisis de impacto de las API, deberia guardarse una foto de la interfaz actual de los servicios consumidos y compararlo con la interfaz del web service futuro. En el caso del los Web services SOAP, puedo almacenar los WSDL. En el caso REST, es un poco mas complejo. 

Creo que con la incorporación de los módulos y la definición de cuales son los objetos públicos y privados, vamos en el camino correcto, para lograr tener un GeneXus API Manager, que permita administrar la interfaz de mi aplicación. 

lunes, 11 de agosto de 2014

PIENSOPIENSO: Es posible ejecutar esta reorganización?


Tengo una KB GeneXus y en la misma tengo la transacción

TransaccionNoUsada 

*Clave
  AtributoSecundario
  AtributoSecundarioNoUsado (no es referenciado en ningun objeto)



Dicha transaccion tiene la propiedad de GenerateObject = False pues nadie la invoca y genera la tabla de nombre MiTabla

Tengo ademas un programa, (Tipo Procedure, main, Command Line) que hace

new  //Agrega registro en la tabla MiTabla
    Clave = &Clave
    AtributoSecundario= 'Valor'
endnew



Elimino el atributo AtributoSecundarioNoUsado y se genera la reorganizacion que hace:

ALTER TABLE MiTabla DROP COLUMN AtributoSecundarioNoUsado;


PREGUNTA:
Puedo ejecutar la reorganización sin instalar nuevamente mis programas?
Justifique su respuesta