Automatización Continua

Automatización Contínua¿Una historia que vale la pena contar?

Terror en la softscuridadHistorias que te dejarán pensando

“Basada en hechos reales”

El despertar de los muertos vivientesEl fin del mundo: Año 2000

El fin del mundo se aproxima (1999)

▪ Bug del Año 2000! También conocido como “el error del milenio”

▪ OK! Con GeneXus es trabajo fácil ;)a) Instalo update de GXb) Abro todas las KB’sc) Build Alld) Compiloe) Testeof) Distribuyo “pa todo el mundo”g) Yupi! Contentos con la llegada del año 2000!

▪ OK! Manos a la obra! …. Mientras tanto…

El despertar de los muertos vivientes

Niiaaammmm! KBrebros!

Los muertos se levantan de la tumba!

▪ +50 KB’s Zombies!! (No se tocan hace mucho)

▪ Yupi! Disquetes de 5,25” y 3,5” (hermosos 90’s)

▪ +5 versiones diferentes de KB’s, desde GX 3.0 a 6.1

▪ Muchas versiones! ¿Cuál es “la posta”?

▪ Yes! mucha cosa programada a mano!!

▪ Un mix de gustos! Cobol, FoxPro, VFP, VB…

▪ OMG! Cuantas instalaciones? Uuu… nice!

▪ A Correr!! Digo.. A Migrar!!


¿Cómo matar un Zombie?

▪ Mantener vivo lo que vale la pena, el resto matarlo cuanto antes.

▪ Migrar siempre a última versión de GX (Si es automatizado mejor!)

▪ Refactoring! Refactoring! (en cuanto se descubra algo zombie, matarlo)

▪ Unificar! Una KB! Un Lenguaje! Un solo proceso! órganos internos apoyan a varios sistemas.

▪ Documentar! Documentar! (Principalmente proceso para no convertirse nuevamente en zombie)

▪ No permitir “chanchujo a mano” por fuera (si no queda otra, documentar y automatizar)

▪ Tracking! (saber qué cosas están mal y marcarlas para darle seguimiento)

▪ Build y Deploy, asegurarse que la nueva versión suplante a la zombie cuanto antes!


Lecciones aprendidas

▪ Gestión de Configuración de Software (SCM) es “La Ley”

▪ 90’s pocas herramientas de automatización, Build, Deploy y jugar con XPW era lo que se podía hacer.

▪ Gurda tus productos de trabajo y los backup en un medio que no falle, tener replicación en caso que falle.

▪ No puedes migrarte de una última versión de GX, pasa por intermedias

▪ Migrar de GX cuanto antes! Probar cuanto antes! Corregir cuanto antes!

▪ ¿Si funciona no lo toques? Mantenlo actualizado, si se deja de usar, backup y borrado (kill the zombies!).

▪ Testing? Solo manual, documentar las pruebas y versionarla igual que versionas el sistema.

▪ Distribución e instalación (algo que no se tiene en cuenta siempre).

▪ Versionar todo! Hacer backups periódicos! (y periódicamente probar que los backups funcionan!)

▪ Un ciclo completo de build, test y deploy cada tanto viene bien (puedes aprovechar al migrarte de ver de GX)


Gizmo y el efecto “Gremlins”Mogwai “Espíritu maligno”

2001 la odisea

▪ Producto Grande! KB’s Grandes!

▪ Muchas solicitudes de cambio!

▪ Muchos módulos nuevos!

▪ Muchas mejoras para hacer!

▪ Muchos programando todo el tiempo!

▪ Muchos haciendo macanas todo el tiempo!

▪ ¿En donde estoy?

En el sector encargado de arreglar “macanas”.

Gizmo y el efecto “Gremlins”

¿Quiéres un “Gizmo”?

Respeta las siguientes reglas:

▪ No lo expongas a la luz! Lo mataría!

▪ Nunca le des de beber agua!

▪ Nunca lo mojes!

▪ Nunca darle de comer luego de la media noche!


OK! Ahora estoy tranquilo, conozco las reglas!!

¿Pero todos los que juegan con “Gizmo”? ¿las conocen y las respetan?

Gremlins! Corran!

▪ Se portan mal!

▪ Son impredecibles!

▪ Se reproducen rápidamente!

▪ No siguen las reglas!

▪ Son producto de “descuidados” o “mal informados”

▪ Y lo peór de todo! Quieren maltratar a “Gizmo”


Algunos tipos de Gremlins

▪ No encontramos el fuente del programa

▪ ¿Quién hizo el cambio y cuando?

▪ Grrr! Código repetido por todos lados!

▪ La documentación no corresponde!

▪ ¿Realmente lo testearon?

▪ OMG! Está en producción?

▪ ¿Quién te pidió que hicieras ese cambio?

▪ Ups, me equivoqué y envié un programa incorrecto


Gremlins vs Zombies

▪ A diferencia de los Zombies, los Gremlins son producto de mucha actividad, a medida que hay más trabajo, más puntos de fallo en el proceso pueden existir.

▪ Los Gremlins tienden a proliferen, se necesita de “Policías” encargados de que se cumpla “la ley” (procesos) para mantenerlos en contról.

▪ Es casi imposible no tener Gremlins, si haces mucho, y muchos participan, es natural que aparezcan, hay que trabajar de forma continua en intentar mitigarlos.

▪ Los “Policías” pueden ser personas u herramientas, o las dos trabajando juntas son lo ideal.


Caso Ejemplo:El Gremling de “datos truncados”

▪ 5 Bases de conocimiento con cientos de programas en cada una de ellas

▪ Cambio de un “dominio” de atributo de 14,5 a 18,5, todos los basados en se actualizaron correctamente. Se regeneró y recompiló y se distribuyó a los clientes.

▪ Los test no lograron el cubrimiento correcto, muchos de los programas fallaron en el cliente.

▪ No todos los programadores basaron en atributos sus variables

▪ Existía problemas además entre “cross KB’s” con llamadas a procesos externos


El Gremling de “datos truncados”Solución:

▪ 1 – Notificar a todos los programadores de los errores cometidos

▪ 2 – Crear una herramienta que intente detectar y corrija el problema automáticamente.Año 2001, se utilizaba GX 6.1, se analizaron las Spec y los XPW para detectar los programas con variables que podrían estar mal creadas (se parcheaba el xpw ya con el arreglo para luego ser integrado)

▪ 3 – Corregir todos los programas, y enviarlos a probar para luego enviarlo a los clientes.Se detectaron y corrigieron cientos de programas, antes de eso ya estaba cansado de tantas “idas y venidas”, se tomó el toro por las guampas y se solucionó el problema de raíz.

▪ 4 – Fue el inicio de primeras herramientas de inspección y corrección de programas, arreglaba “problemas” en lo programado en la KB local o se podía usar para procesar lo integrado en la KB en el servidor central.


Caso Ejemplo:El Gremling de “no se de donde viene”Solución:

▪ Se crearon herramientas para gestión de requerimientos

▪ Se crearon estándares de documentación para cada tipo de requerimiento.

▪ Se reservan los programas para su modificación asociados a un requerimiento (tipo lock, nadie puede trabajar en ellos hasta que sean liberados)

▪ Se documentan las modificaciones en los fuentes, asociando el bloque modificado a los requerimientos (se dejó de hacer cuando se implementó el diff entre versiones)

▪ Se “marca” los compilados con la firma del requerimiento (puedo saber desde un class o dll de qué versión del fuente fue compilado)

▪ Se realiza un empaquetado y build asociado a un requerimiento (esto puede varias según el tipo de desarrollo)

▪ Se creó una herramienta que permite ver la trazabilidad de todo el ciclo, desde un requerimiento puede verse toda la documentación, así como los fuentes involucrados y los paquetes de distribución e inclusive el código fuente (similar a GXServer)


Caso Ejemplo:El Gremling de “en .net me compila…”Solución:

▪ Se detectaron algunas limitaciones, que si los programadores programan y compilan en solo un lenguaje no saltan y no son evidentes en otros.El día que lo necesitan ver funcionando en ese otro lenguaje se enteran que tienen que cambiar la forma de programarlo.

▪ Se implementó en la KB de integración que siempre se compile en todos los lenguajes para asegurarse que en el proceso de integración lo integrado compila para todas las plataformas soportadas.

▪ Para algunos bugs de generación, se parchea el código generado.


Caso Ejemplo:El Gremling “el octavo pasajero”Solución:

▪ Existe metadata que viaja en los exports que afectan la definición de datos de la KB destino. El programador muchas veces tiene en su KB local una KB vieja o pruebas y cambios de otras cosas que no serían deseables que sean integradas en la KB central (sin embargo desapercibidamente viajan).

▪ Se implementó en la KB de integración un sistema de “filtro” que impide que se “rompa” o “cambie” algunas cosas en la KB central (dominios y subtipos era lo más común, si quieres hacer eso, tienes que seguir otro procedimiento formal).



▪ Gestión de Configuración de Software (SCM) sigue siendo “La Ley”

▪ Inspeccionar el código y filtrar las cosas indeseadas permiten protegerte

▪ Gestionar requerimientos (tanto desarrollo como mantenimiento) y permitir una trazabilidad ayudan.

▪ Crear herramientas para de forma automática arreglar “macanas”.

▪ Versionado de código fuentes (e includido comparación entre las mismas) ayuda mucho.

▪ Testing? Sigue siendo manual, pero se crearon estándares y documentación formal, tanto para la documentación técnica, cambios, manuales y evidencias de pruebas funcionales.

▪ Un ciclo completo de build, test y deploy ayuda a detectar problemas (ahora se puede automatizar con GXPublic!)


Entrando a la MatrizAño 2008

Todo es parte de la matriz

▪ Producto Monstruoso! KB’s Monstruosas!

▪ Nuevos mercados, nuevos clientes, nuevos desafíos.

▪ Muchos más programando!

▪ Muchos haciendo “macanas” todo el tiempo!

▪ ¿En donde estoy?

Estoy como “keymaker”.

Abro puertas para llegar más rápido y mejor al destinoConstruyendo herramientas relacionadas con Build & Deploy

Entrando a “La Matriz”

¿Todo es parte de la matriz?

▪ Definiciones

▪ Diseño

▪ Requerimientos

▪ Pruebas

▪ Integración

▪ Configuración

▪ Programación

▪ Build

▪ Release


Foco2001 a 2008

▪ Definiciones

▪ Diseño

▪ Requerimientos


▪ Pruebas

▪ Integración

▪ Configuración

▪ Programación

▪ Build

▪ Release

Foco>2008

Interrogantes

▪ Acelerar el proceso y minimizar errores

▪ Mejorar la comunicación

▪ Mejorar calidad del software

▪ Estado actual y calidad de desarrollo

▪ Herramientas adaptdas a la necesidad

▪ Bloques de construcción e interacción

▪ Infraestructura flexible

▪ Trazabilidad de origen a resultado


Acelerar el proceso y minimizar errores

▪ Automatizando los siguientes procesoses posible acelerar y minimizar los errores

▪ Verificación

▪ Compilación

▪ Empaquetado

▪ Pruebas

▪ Inspección

▪ Distribución


CI – Integración contínua

▪ Integrar, generar y distribuir lo antes posible para mitigar y reducir riesgos.

▪ Eliminar procesos manuales (errores humanos)

▪ Ejecutar de forma inmediata las pruebas

▪ Disponibilidad de builds actualizados

▪ Monitorización de las métricas de calidad del proyecto


Automatizar tareas de poco valor

▪ Análisis de impacto antes de integrar (y filtrado)

▪ Consolidar programas

▪ Comparar programas

▪ Reorganización

▪ Generación y compilación

▪ Operaciones varias con XPZ

▪ Distribución y empaquetado de programas

▪ Comparador de esquemas de base de datos y GX



▪ Gestión de Configuración de Software (SCM) sigue siendo “La Ley”

▪ 7x24 ayuda más de lo que te imaginas

▪ Permite trabajo entre personas geográficamente distribuidas

▪ Una única forma de hacer las cosas (una única Ley)

▪ Reducir los tiempos de desarrollo y reléase ayuda a concentrarse en arreglar

▪ Escalable, puede crecer con el crecimiento del producto y la empresa

▪ Con cada corrida se aprende y mejora el proceso (mejora contínua)


¿[email protected] Twitter: @3dgiordano

Recursos: Buscar y “estudiar”

▪ Gestión de Configuración de Software (SCM)

▪ Integración contínua (CI)

▪ Deploy contínuo

▪ ALM

▪ Ispección contínua

Automatización Continua

Technology

Transcript of Automatización Continua