automatización continua
DESCRIPTION
Como muchas películas de terror, tenemos un final feliz. Historias de Zombies y Gremlins, y la lucha por controlar la Matriz. Un camino de experiencias pasando por las cumbres del desafío de SCM, a implementar Integración Continua (CI) y por último lograr llegar a tener control de todo el proceso mediante ALM. http://en.wikipedia.org/wiki/Software_configuration_management) http://es.wikipedia.org/wiki/Trazabilidad http://en.wikipedia.org/wiki/Continuous_integration http://www.martinfowler.com/articles/continuousIntegration.html http://www.jug.ch/events/slides/110922_Continuous_Inspection.pdf http://www.codinghorror.com/blog/2006/10/the-build-server-your-projects-heart-monitor.html http://i.bnet.com/logos/whitepapers/Serena_Life_Cycle_Management.pdfTRANSCRIPT
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!!
El despertar de los muertos vivientes
El despertar de los muertos vivientes
El despertar de los muertos vivientes
¿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!
El despertar de los muertos vivientes
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)
El despertar de los muertos vivientes
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!
Gizmo y el efecto “Gremlins”
OK! Ahora estoy tranquilo, conozco las reglas!!
¿Pero todos los que juegan con “Gizmo”? ¿las conocen y las respetan?
Gizmo y el efecto “Gremlins”
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”
Gizmo y el efecto “Gremlins”
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
Gizmo y el efecto “Gremlins”
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.
Gizmo y el efecto “Gremlins”
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
Gizmo y el efecto “Gremlins”
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.
Gizmo y el efecto “Gremlins”
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)
Gizmo y el efecto “Gremlins”
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.
Gizmo y el efecto “Gremlins”
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).
Gizmo y el efecto “Gremlins”
Lecciones aprendidas
▪ 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!)
Gizmo y el efecto “Gremlins”
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
Entrando a “La Matriz”
Foco2001 a 2008
▪ Definiciones
▪ Diseño
▪ Requerimientos
Entrando a “La Matriz”
▪ 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
Entrando a “La Matriz”
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
Entrando a “La Matriz”
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
Entrando a “La Matriz”
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
Entrando a “La Matriz”
Lecciones aprendidas
▪ 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)
Entrando a “La Matriz”
¿[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