Page 26 - REVISTA 2016

fundamentales: procesos, herramientas y equipo, los tres muy ligados entre sí. O sea, se puede estar mejorando
gracias a mejorar el proceso, pero para eso se necesita adaptar las herramientas que se utilizan y además se nece-
sita capacitar al equipo. Quizá dentro de los enfoques ágiles nos encontramos con frameworks como Scrum que
apuntan al proceso, nos encontramos con diversos tipos de herramientas, desde herramientas de comunicación,
gestión de tareas, etc., y nos encontramos con mucho foco en la motivación y compromiso del equipo. Todos
los aspectos de los enfoques ágiles están siendo bien dirigidos a ser adaptable al cambio, ese es el eje principal.
La idea es asumir que lo que el cliente necesita no está fijo por más se establezca en un contrato. Es así que es
fundamental poder trabajar sobre adaptaciones constantes y que eso no implique que los costos del proyecto se
disparen o se vuelva inmanejable.
¿Qué se necesita para adaptarse al cambio y mantener el nivel de calidad? Algo que hemos observado en muchos
proyectos es que los problemas más típicos al introducir cambios en un sistema es el miedo: miedo a romper
algo que estaba funcionando y que no nos demos cuenta hasta que llegue a las manos del cliente. Cuando a un
usuario le dan una nueva versión de la aplicación no hay nada peor que encontrar que lo que ya andaba dejó de
funcionar. Si el error es sobre algo nuevo, es entendible, pero que ocurra sobre algo que ya se suponía que andaba
cuesta más. Para atacar este problema debemos ser capaces de detectar errores de cualquier tipo lo antes posible.
Cuando hablamos de error nos referimos a cualquier tipo de error: error de cálculo, problema de performance,
vulnerabilidad de seguridad, aspectos de usabilidad, problemas de mantenibilidad (o sea, factores de calidad
de código) o cualquier cosa que pueda llegar a manos del usuario y ocasionarle inconvenientes en el uso con el
sistema. Y cuando hablamos de lo antes posible nos referimos a lo más cercano al momento en el que se inserta
ese error en el sistema.

Es así que surgen y ganan importancia las prácticas de Continuous Integration y Continuous Delivery para los
equipos ágiles. Básicamente lo que plantea la Integración Continua es que debemos construir frecuentemente
nuestra solución, armar un producto potencialmente entregable al cliente, digamos que al menos una vez al día.
Por ejemplo, en lugar de esperar dos semanas para unir nuestro código al del resto del equipo, lo hacemos todos
los días, o incluso varias veces al día. En lugar de ejecutar “manualmente” todas las pruebas, las automatizamos
y las ejecutamos todos los días, o incluso varias veces al día. En lugar de detectar otros tipos de problemas al
final, los vamos analizando a medida avanza el desarrollo. De esta forma ahorraremos mucho costo y esfuerzo,
especialmente en re-trabajo. Además, con esta solución no tendremos miedo en enviarle una nueva versión del
producto al cliente.

Las herramientas para Integración Continua permiten definir una secuencia de tareas a realizar automáticamente,
entre las que se suelen incluir:

• Actualización del código a la última versión.
• Compilación de la solución.
• Ejecución de pruebas automáticas.
• Chequeos de calidad de código.
• Verificaciones de seguridad, performance, compatibilidad, etc.

Y la lista se puede ampliar con cientos de integraciones y verificaciones que se deseen agregar. Hay decenas de
herramientas para dar soporte a estos automatismos, algunas tan antiguas como Ant, Maven y MSbuild, hasta
las más populares de hoy en día con interfaz de administración web como Jenkins, CrouiseControl, Bamboo y
TeamCity y, por si fuera poco, también tenemos soluciones en la nube como Code Pipeline de Amazon, TravisCI,
CircleCI, Codeship y Visual Studio Team Services de Microsoft.

Entonces, para tener integración continua simplemente se trata de conseguir una de estas herramientas y ya
tengo calidad asegurada en todo lo que hagamos. ¡Incorrecto! -> El problema es que muchos equipos caen en
esa falacia y se saltean muchas asignaturas previas, con lo cual el retorno de la inversión no es el apropiado, en-
contrando más dificultades que beneficios. Algunas de esas “asignaturas previas” podrían ser la correcta gestión
de versiones del código, una apropiada gestión de ambientes y datos de prueba, un buen enfoque de automati-
zación del testing considerando los distintos niveles (unitario, API e interfaz gráfica) y mucho más.

En nuestro caso, hace más de 10 años que nos dedicamos a brindar servicios de testing funcional, automatizado
y de performance. En el camino hemos visto muchos clientes y partners trabajando en distintos contextos, tanto
a nivel nacional como en los mercados más exigentes como Japón, Estados Unidos y países europeos. Ahora

28 Revista de la Facultad de Ingeniería