Construcción Nocturna (Nightly Builds)

 En  parte debido la globalización, en parte a la masificación de Internet pero principalmente debido a la tendencia de tercerizar (outsourcing) los desarrollos o gran parte de ellos, muchas organizaciones se encuentran hoy armando sus sistemas en base a ensambles de componentes construidos por equipos diversos y dispersos (distribuidos)

Qué tan listos nos encontramos, qué tan preparada está nuestra organización para llevar el control de versiones del código fuente cuando éste madura en varios lugares al mismo tiempo? Qué pasará cuando llegue el día de juntar las piezas si las pruebas de regresión comienzan a dar fallos? Cómo encontrar rápidamente donde se produce el fallo?

Quiero aclarar esta última pregunta: no me refería a localizar dónde se manifiesta el fallo sino dónde se genera. El fallo se puede manifestar en un componente porque un valor que le devolvieron es menor que 0 (cero) y eso por lógica de aplicación no estaba permitido. Si ese es el caso, es ese componente el responsable del error? O hay que rastrear qué otro componente le pueda estar entregando valores inválidos?

Qué complicado, no? Era dificil ya trabajando todo el equipo para la misma organización, imaginémonos cómo se va a poner la cosa ahora que la aplicación la hacemos entre varias organizaciones, con diferentes necesidades, urgencias y compromisos. Esto se intensifica cuando las organizaciones son trasnacionales, tienen diferentes husos horarios, idiomas, culturas y hasta idiosincracias

Que levante la mano quién no le ha tocado trabajar en los últimos tres años en un proyecto, ya sea para otro país, ya sea considerando que parte del desarrollo se llevaba en algún país de la región, o en España o incluso en India

Cómo llevan las empresas que triunfaron con el modelo de outsourcing, el control de cambios de sus proyectos de misión crítica? La respuesta se basa en la aplicación de tres mandatos:

  • Integre con frecuencia (integrate often)
  • Construya con frecuencia (build often)
  • Pruebe con frecuencia (test often)

Integrar con frecuencia implica tener un repositorio centralizado, posiblemente replicado, de manera tal que al fin de cada jornada cada equipo de trabajo pueda registrar (check-in) aquellos componentes asociados a tareas ya terminadas. Este repositorio debe ser de alta disponibilidad ya que posiblemente deba ser accedido por equipos de trabajo -no es chiste- de otros continentes. La carencia de esta característica podría obligar a tener que delegar en alguien local la recepción de componentes para registrarlos en forma manual. Y lo mismo para reservarlos (check-out)

Construir frecuentemente el código integrado, permite mantener una colección de versiones de los ejecutables (generalmente diarias cuando se trata de proyectos grandes compuestos de equipos dispersos). La idea es contar siempre con la chance de conocer si un error detectado recientemente es realmente nuevo -de manera de enfocar la pesquisa a los últimos cambios- o viene de allá lejos en el tiempo, y simplemente nunca se había dado la casuística para que se manifestase. Existen frameworks que se encargan de realizar construcciones nocturnas (nightly builds) de la versión que incluye el último código integrado

Probar con frecuencia el código construido, es una buena forma de anticipar la detección de errores de ejecución. En el mejor caso el mismo día que se introdujo. Pruebas unitarias a métodos específicos de componentes, pruebas de carga u otras pruebas para verificar umbrales de aceptación (tiempos de respuesta, por ejemplo) deben intentar cubrir la mayor parte de casuísticas posibles del código (code coverage). Por suerte existen frameworks que permiten generar y mantener casos de prueba de los tipos mencionados y varios otros más, y ejecutarlos en forma automática o semi asistida

Existirá algún producto que me permita automatizar la implementación de estas tres prácticas? La respuesta es sí: Visual Studio 2005 Team System. El lado servidor de VS 2005, Team Foundation Server, se compone de varias herramientas integradas como el generador de portales, el repositorio de versiones, el motor de reportes de gestión, etc. Una herramienta poco conocida es Team Foundation Build

Team Foundation Build es una facilidad que enmascara una pieza de línea de comandos clásica como es MSBuild (una suerte de make versión Microsoft). Con Team Foundation Build se pueden definir tipos de construcción donde se indique a qué soluciones (.sln) del repositorio afectan -las cuales pueden construirse en un espacio de trabajo (workspace) remoto al lugar desde donde se define este tipo de construcción-. Del mismo modo, los ensamblados pueden ser dejados en cualquier carpeta compartida de la red. Y no termina aquí: Team Foundation Build puede opcionalmente, luego de la construcción, ejecutar los proyectos de pruebas definibles vía Team Developer o Team Tester

Y mediante el sistema de alertas incorporado a Team Foundation Server, es factible recibir un correo con los resultados de la construcción (pasos ejecutados, pruebas que fallaron, qué check-ins componen la construcción, qué unidades de trabajo –bugs u otras tareas- están involucradas, etc. No obstante, los resultados de cada construcción ejecutada quedan publicados en el portal

Eventualmente, Team Foundation Server nos permite reforzar el proceso de registro (check-in) a través de políticas: acciones que se deben cumplir exitosamente para proceder. Ejemplos de políticas son: exigir que la pieza integrada se construya libre de errores, que se ejecute un análisis del código, que se ejecuten pruebas sobre la pieza, o que ésta lleve asociados al menos una unidad de trabajo. Así da gusto trabajar en equipo!!

Para conocer más detalles de Team Foundation Build recomiendo seguir explorando por esta serie de notas (click acá). Existe un webcast muy completo (y no es extenso de duración) que explica en detalle la arquitectura de Team Foundation Build, describe sus puntos de extensión y por supuesto remata todo con una demo. Para verlo hay que hacer click acá

Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s