Automatización Continua
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Automatización Continua

  • 268 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
268
On Slideshare
267
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
4
Comments
0
Likes
2

Embeds 1

http://www.slideee.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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