Automatización

RSS
Modificado el 2011/02/10 00:06 por Juan José Montes de Oca Arbós Categorizado como VAN

VAN - Diciembre 18 de 2009 - Automatización

 

Formato

     Reunión virtual

 

Duración:

     Vídeo: 1:29 horas 

 

Ponente:

     Martín Salías

 

Síntesis:

 

El objetivo de la VAN se resume en la siguiente frase: “Antes de hacer algo por cuarta vez, automatízalo”.

 

Tareas repetitivas

 

El desarrollo de software surge para automatizar tareas de negocio, como crear una factura. Generalmente somos buenos en esto, pero no tanto en automatizar nuestras tareas.

 

Objetivos de la automatización

 

  • Esfuerzo

    La tarea cuesta menos y se hace menos tediosa. Cuanto mayor tiempo lleva la tarea, menor es la probabilidad de hacerla. Y cuando la dejamos de hacer, minimizamos el valor del trabajo que hacemos. Ej: no compilar frecuentemente.

  • Reduce el tiempo
  • Aumenta la previsibilidad
  • Consistencia

    Por ejemplo, para automatizar ciertas tareas, necesitamos hacer que las diferentes variantes de la tarea sean consistentes. Eso nos fuerza a hacer nuestro trabajo más consistente y seguramente ganaremos en eficiencia. Ej: implementar en distintos ambientes.

  • Extensibilidad

    Al ganar / ahorrar tiempo, surge la oportunidad de mejorar otras cosas. El caso más típico es el server de build. Una vez que automatizo el build, puedo automatizar otras tareas, como correr pruebas unitarias, informes de code coverage, etc.

  • Métricas

    Tomar métricas en un proceso automatizado es mucho más fácil que en un proceso manual. Ej: índice de bugs de los commits hechos después de las 10 de la noche. Frecuencia de commits / bugs en función del tiempo de los desarrolladores en el equipo, para entender si el equipo va aprendiendo / mejorando. Hay una enormidad de información que se puede extraer para encontrar oportunidades de mejora.

 

Estrategias

 

  • Herramienta específicas

    Una opción es usar herramientas / plataformas completas (tipo TFS). Otra es utilizar herramientas chicas que se pueden acoplar y mezclar. Lo importante es mantener la idea de probar, analizar su efecto e integrar al proceso de desarrollo.

  • APIs y abstracciones

    DRY: dont’ repeat yourself. Cómo diseño, principios SOLID. Cuidar el diseño para mantener el código simple y con poco impacto frente a cambios. Usar un lenguaje específico de dominio.

  • CodeGen (ej: ajgenesis)

    Hay un balance entre la generación de código y la construcción de interfaces. Otra alternativa es generar cosas en runtime.

  • Build

    Generalmente el build comprende actividades previas a la compilación (obtener última versión de los fuentes). A continuación sigue el proceso de compilación. Luego de compilar se pueden hacer varias cosas, como por ejemplo correr NGEN para generar código binario p/distintas plataformas. Cuando alguna de estas tareas falla o lanza un warnings, tengo que recolectar y loguear estos datos.

  • Testing

    Pruebas unitarias, de integración. A veces el entorno de compilación no es el de prueba. Según el entorno puedo automatizar cambios en los archivos de configuración. Luego de la ejecución de pruebas, puedo recolectar datos (%coverage). 

    Hay una gran variedad de pruebas que pueden realizarse: de stress, de carga, pruebas de compliance con páginas web, validez de ciertos estándares (accesibilidad, nivel html). Análisis estático. Análisis de estilo. Análisis sobre código java script. Análisis de arquitectura, dependencias, complejidad ciclomática, dependencia entre componentes (ndepend). Analizar si las referencias que hay entre componentes se corresponde con un diagrama de arquitectura.

  • Deployment

    Luego del build, pasar a otro entorno para ejecutar otro tipo de pruebas (manuales, estéticas). Se puede automatizar el hecho de reportar “hay una versión nueva” y saber cuánto varió respecto de la anterior. 

    Quizás 1 vez x día o cada tantas iteraciones, alguien realizar un test manual. Si alguien lo mira y dice “esto no me gusta”, el equipo debería poder probar eso en el contexto de la versión que se está probando. Si no lo automatizo, se me desordena el resto del proceso.

    Cuando empezamos a ver que esto ocurre, si lo dejamos pasar, se nos van acumulando junto con otras cosas. Después, a medida que pasa el tiempo, se hace más difícil resolverlas porque tengo muchas cosas pendientes (es difícil romper la inercia).

    Generalmente el proceso de deploy (a cargo de otra gente, otro grupo) no se automatiza tanto. Al hacerlo manualmente, me pierdo la oportunidad de hacer deployment mucho más frecuente de lo que lo hago. Esto tiene varias ventajas, siempre y cuando pueda garantizar cierto nivel de calidad. Hay casos de gente que hacen deployment continuo.

 

Técnicas

 

  • Herramientas (bug tracker, carga de requerimientos)

    Si bien este tipo de herramientas ayudan en la organización de tareas, no hay que dejar de ver que cuando hay demasiados bugs estamos teniendo un problema. Si gestionar y solucionar los bugs consume un tiempo importante del desarrollo, es una señal de que algo no anda bien. Estas herramientas ayudan a tener un mecanismo de comunicación fluida. A veces son mecanismos super sencillos, como post-it.

  • Poweshell // CmdLest

    Si puedo automatizar el proceso para implementar en mi ambiente de desarrollo, testing y staging, entonces gano en seguridad, ya que si en staging anduvo bien, es muy probable que en otro ambiente también.  En organizaciones grandes, donde intervienen varias áreas en un deploy, si puedo facilitar un script automático al grupo de implementación, probablemente me gane su confianza y me convierta en un gran socio de ellos.

    Powershell me da un lenguaje de scripting con acceso a las librerías de .net. Puedo escribir scripts en c#, vbnet, boo. También puedo escribir mis propias librerías tipo commandlets , parametrizarlos y reutilizarlos. Hay muchos productos con una variedad muy grande de commandlets para distintas tareas. Ej: reiniciar appPool de IIS, administrar sqlserver, active directory, etc. Estas librerías simplifican trabajar con piezas de infraestructura. Esto me da un montón de posibilidades.

  • Ruby / Python
  • Motores de IC++

    Motores de integración continua y todo lo que puedo hacer además. Ej: validar cuestiones del proceso, como que se hayan enviado ciertos mails con los compromisos del equipo, verificar si se hicieron las reuniones de planificación y review. Si está declarado el entregable dentro del svn. Verificar tareas que tienen que ver con la certificación ISO. Buscar mails con determinado contenido implica que no hay que hacer revisiones manuales. Nuevamente, hay muchas posibilidades detrás de esto.

  • Virtualización

    Antes, probar cosas en distintos ambientes, sistemas operativos, versiones de software, era complejo. Ahora, la virtualización nos permite tener una librería de máquinas virtuales, subirlas y bajarlas según sea la necesidad. Por ejemplo, levantar una máquina, instalar algo, probar, y si todo está bien, apagar la máquina sin guardar los cambios para volver a repetir el proceso. Me permite reproducir fácilmente entornos similares a los de producción. La combinación entre scripting y virtualización es una combinación poderosa. Ej: para hacer deploy puedo levantar un VM, instalar cosas que hacen falta, disparar pruebas, recolectar datos y apagar la máquina.

 

Un caso que no es mío

 

http://timothyfitz.wordpress.com/2009/02/08/continuous-deployment/

http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/

 

En este caso, luego del commit, pruebas y checkeos, el último punto es ejecutar los mismos scripts e implementar en producción. Obviamente, tienen un montón de chequeos para no pasar errores a producción. De esta manera tienen feedback del usuario mucho más frecuentemente.

Si consigo pasar rápidamente los cambios menores, entonces gano una buena velocidad de respuesta e imagen. El usuario ve que permanentemente la aplicación está mejorando.

 

Enlaces:

 

Lecturas

  •  

 

Video

Si lo prefieren, pueden observar el vídeo en http://www.screencast.com/t/kI8kYuVw o descargar el archivo desde este enlace, el cual tiene un tamaño de 172.68 MB.

 

Unable to display content. Adobe Flash is required.