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

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

2. Terror en la softscuridad
Historias que te dejarán pensando
“Basada en hechos reales”

3. El despertar de los muertos vivientes
El fin del mundo: Año 2000

4. El despertar de los muertos vivientes
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 GX
b) Abro todas las KB’s
c) Build All
d) Compilo
e) Testeo
f) Distribuyo “pa todo el mundo”
g) Yupi! Contentos con la llegada del año 2000!
▪ OK! Manos a la obra! …. Mientras tanto…

5. Niiaaammmm! KBrebros!

6. El despertar de los muertos vivientes
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!!

7. El despertar de los muertos vivientes

8. El despertar de los muertos vivientes

9. 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!

10. 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)

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

12. Gizmo y el efecto “Gremlins”
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”.

13. 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?

14. Gizmo y el efecto “Gremlins”

15. 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”

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

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

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

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

20. 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)

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

22. 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).

23. 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!)

24. Entrando a la Matriz
Año 2008

25. Entrando a “La Matriz”
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 destino
Construyendo herramientas relacionadas con Build & Deploy

26. Entrando a “La Matriz”
¿Todo es parte de la matriz?
▪ Definiciones
▪ Diseño
▪ Requerimientos
▪ Pruebas
▪ Integración
▪ Configuración
▪ Programación
▪ Build
▪ Release

27. Entrando a “La Matriz”
Foco
2001 a 2008
Foco
>2008
▪ Definiciones
▪ Pruebas
▪ Diseño
▪ Integración
▪ Requerimientos
▪ Configuración
▪ Programación
▪ Build
▪ Release

28. Entrando a “La Matriz”
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

29. Entrando a “La Matriz”
Acelerar el proceso y minimizar errores
▪ Automatizando los siguientes procesos
es posible acelerar y minimizar los errores
▪ Verificación
▪ Compilación
▪ Empaquetado
▪ Pruebas
▪ Inspección
▪ Distribución

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

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

32. 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)

33. ¿Preguntas?
3dgiordano@gmail.com Twitter: @3dgiordano

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