Buenas,

repito el título del post que más que un título es una afirmación

AUTOMATIZAR PROCESOS ES AHORRAR A LARGO TIEMPO

Esto no es una tarea fácil, pero una de las formas de encarar la misma es la siguiente

1. Identificar las tareas repetitivas que realizamos manualmente durante el desarrollo de una aplicación

2. Evaluar la posibilidad de crear un proceso automático que se encargue de realizar esas tareas

3. Definir un período de prueba para la implantación de este proceso

4. Verificar el tiempo ganado utilizando este proceso

Si seguimos esos pasos durante la implantación de un proceso de automatización, seguramente veremos una de estas dos opciones

- lo que inicialmente parecía una tarea que podía ser sustituida rápidamente por un script luego se complica bastante y no tiene sentido abandonar el proceso manual

- el proceso automatizado comienza a ser parte de un proceso de automatización cada vez mayor que nos ayuda a ganar calidad en nuestros desarrollos

Esto que parece un poco de teoría de cerveza de viernes por la noche en realidad es bastante cercano a nuestro día a día. He aquí un ejemplo con uno de los grandes “el Javi Gallardo” (a ver cuando te creas un blog che!)

Resulta que para compartir el output de una aplicación era necesario comprimir la misma en un formato especial, separar el archivo comprimido en varios chunks, firmarlos, y par de pasos más.

Cuando realizábamos este proceso a mano, el mismo nos tomaba menos de un minuto. Pero siempre existía la posibilidad de poner mal la clave del ZIP, de separar mal los chunks, etc. Javi se tomó 30 minutos y se creó un script que se encargaba de realizar este proceso.

De esta forma, logramos tener siempre el mismo OUTPUT a partir de un proceso repetitivo y predecible (que es una de las bases sobre las que debemos trabajar).

A nivel métricas, simplemente evitando que Javi se equivocase en la generación de un paquete ya habíamos ganado el tiempo de generación del script. Javi es un crack, pero si asumimos que se podía equivocar 2 veces al día.

Todas las ejecuciones posteriores nos dieron una ganancia de +300 segundos. Finalmente, después de un par de meses habíamos ganado 2 días/hombre. (Esto traducido a €uros siempre nos da una alegría)

Con Javi no fuimos más allá, ya que con el script nos bastaba, pero siempre existe la posibilidad de pensar un poco out-of-the-box

• delegar en una build de Team Foundation la responsabilidad de realizar este proceso.
• procesar el resultado de este proceso solo en ocasiones de compilación exitosa y si los tests se ejecutan correctamente
• automatizar el empaquetado y distribución a partir de este proceso
• etc.

Cuando llegamos a estos escenarios estamos más cerca de tener escenarios de Continuous Delivery (sobre lo que hablé en este link), simplemente automatizando tareas.

Existen muchos escenarios donde podemos automatizar, la mayoría se traducen en despliegues, pero rápidamente se me ocurren los siguientes

• Despliegues, por ejemplo cuando desplegamos a AZURE, ¿porqué lo hacemos SIEMPRE manualmente?
• Pruebas, el principal punto donde automatizar nos garantiza calidad
• Generación de código, no es uno de los más recomendados, pero trabajar con plantillas por ejemplo es una forma de garantizar siempre el mismo OUTPUT a partir de un INPUT determinado
• Muchos más …

Finalmente, comentar que tal vez el mejor momento donde podemos aplicar estos procesos es en el momento de integrar nuestro código. En el caso de trabajar con Team Foundation, la definición de una build es increíblemente potente como para implementar estos procesos.

En AVANADE Spain tenemos una serie de definiciones de Build que nos permiten realizar diferentes tareas de automatización. Desde procesos para garantizar la calidad, como la ejecución de análisis de estilo de código (StyleCop), generación de informes personalizados a partir de pruebas unitarias y de pruebas de MTM, hasta despliegues automatizados a AZURE, ClickOnce, WebDeploy, etc.

Saludos @ Home

El Bruno