Construcciones automatizadas y diarias

construccion Una de las grandes novedades de Visual Studio Team System y Team Foundation Server es la posibilidad de crear construcciones automatizadas. Pero como ya he comentado alguna vez en este blog, el simple hecho de contar con una herramienta que nos ayude en la tarea no significa que vayamos a adoptar una buena práctica. De hecho antes de Team System ya existía NAnt como herramienta de automatización de la construcción, y se trata de una gran herramienta, pero aun así pocos son los equipos de desarrollo que cuentan con la posibilidad de construir todo su proyects con la simple ejecución de un comando, son pocos los que usan construcciones automatizadas. Conocer las ventajas que aporta las construcciones automatizadas es el único camino para que estas se popularicen y más y más equipos de desarrollo disfruten de sus bondades. Si no quieres seguir leyendo piensa esto: si Microsoft lo ha incluido en su producto de gestión del ciclo de vida será por algo. Si quieres una explicación un poco más elaborada de porque las construcciones automatizadas son una buena idea y cómo pueden ayudar a vuestros proyectos y como combinan con otras técnicas podéis seguir leyendo.

El proceso de construir el software desde las fuentes es complejo. De hecho es cada vez más complejo: elegir la fuentes adecuadas, compilarlas con las versiones adecuadas de los componentes, asegurarnos que hemos compilado en configuración ‘release’, seleccionar de la salida del proceso de compilación aquellos archivos que debemos distribuir, no olvidar incluir aquellas librerías o componente de los que depende nuestro software y asegurarnos de que su versión es la correcta, generar los archivos de ayuda, crear la estructura de directorios que espera como entrada nuestra herramienta de generación de instaladores, ejecutar el proceso de generación del instalador… y todo esto involucrando a un buen número de personas diferentes ¿de verdad alguien cree que es posible realizar este proceso manualmente sin cometer varios errores durante el mismo?. La cruda realidad es que no es posible. Y lo que es peor, a menudo los errores cometidos en alguno de los múltiples pasos que hay que dar se detectan solo al final del proceso. El resultado: ¡una enorme perdida de tiempo!. Y lo peor del caso es que este es un proceso que se repite muchas veces a lo largo de la vida de un proyecto. Además, para agravar aun más la situación este problema ocurre cuando menos tiempo tenemos, ¡justo cuando alguien está esperando que le entreguemos el software!.

En todo proyecto de software existe un ciclo que ser repite infinitas veces: escribir código, compilarlo, integrarlo y realizar pruebas. Contar con un proceso de construcción del software automatizado hace que este este ciclo se acelere enormemente.

El principal problema que plantean las construcciones automatizadas es que exigen una inversión de tiempo para ponerlas en marcha. Configurar un proceso de construcción completo que sea capaz de desde el código fuente de nuestro software construir el software completamente hasta el instalador y además desplegarlo en un sistema de prueba es complejo. De hecho es algo que solo es abordable y rentable si se realiza de forma incremental, haciendo que el proceso de construcción crezca de manera paralela a nuestro software. En cualquier caso, a menudo, en proyectos con problemas de integración, merece la pena invertir el tiempo necesario para configurar un proceso de construcción a posteriori. El esfuerzo es grande pero a menudo no hay otro camino para zanjar de raíz los problemas de integración en los proyectos de software. Resumiendo, más vale configurar pronto el proceso automatizado de construcción que hacerlo a posteriori cuando hay problemas.

Si bien el simple hecho de poder construir nuestro software de manera automática nos proporciona claras ventajas, yendo un paso más allá y construyendo nuestro software diariamente (gracias a nuestro proceso automatizado de construcción esto es algo posible) podemos obtener ventajas añadidas. Si diariamente construimos nuestro software detectáramos rápidamente problemas de integración y corregirlos cuando los cambios que pueden ser la causa aun están frescos en nuestra memoria y por tanto nos es más fácil corregirlos. Además como parte del proceso de construcción podemos ejecutar nuestros test unitarios lo que nos proporcionará la posibilidad de detectar errores no solo relacionados con la integración. Adicionalmente, como colofón a nuestro proceso de construcción y aprovechando que nuestro proceso de construcción despliega el software construido a un entrono de pruebas podemos realizar un test de humo que asegure que el software construido tiene la calidad suficiente como para ser probado en profundidad. Este paso asegura que cualquier error relativo a la configuración del software desplegado se detecta pronto.

A menudo se pone como escusa para no realizar construcciones diarias la magnitud del proyecto: ¿Cómo vamos a construir y desplegar un software tan complejo todos los días? Precisamente cuanto mayor es el proyecto mayores son las posibilidades de sufrir problemas de integración y de calidad pues más es el código que cada día se añade. Además el hecho de que grandes proyectos como por ejemplo Firefox lo haga, demuestra que es viable y rentable. Podéis ver el estado de las construcciones diarias de Firefox.

Os dejo unas cuantas referencias interesantes sobre este tema, por si queréis profundizar más en el tema:

Joel on software: Daily Builds Are Your Friend

Wikipedia: smoke test

MSDN: Instrucciones para pruebas de humo

Mozilla Quality Assurance SmokeTests

Steve Mcconnel: Daily Build and Smoke Test

Software Development using Build and Smoke Tests

15 comentarios en “Construcciones automatizadas y diarias”

  1. Hola Rodrigo,

    En mi actual proyecto usamos varios eventos de pos generación para los ensamblados. ¿Es posible realizar estas tareas, como puedan ser un registro en el GAC, con MSBuild o NAnt? Supongo que si pero, ¿Es recomendable migrarlas o es mejor que se queden dentro del evento de pos generación?

    ¿Que opinas del proyecto CI Factory?
    http://www.cifactory.org/joomla/

    Saludos.

  2. La verdad es que si tus post builds contienen acciones que son necesarias en el entorno de desarrollo de cada uno de los desarrolladores, como creo que es el caso, están mejor en los post builds. Pero en cualquier caso conviene recordar que un archivo *proj, no es más que un script de MSBuild y que por tanto cualquier tarea de MSBuild se puede meter en el *proj. La verdad es que no hay una receta universal, yo hay cosas para las que uso post builds por simple comodidad, como por ejemplo el arrancar el servicio que hostea servicios WCF después de construirlo, que es algo que no quiero además hacer como parte de la build.

    Sobre CI Factory, la verdad es que es una alternativa razonable si no tienes un TFS pero teniendo un TFS prefiero no usarlo simplemente por simplificar el sistema de build. Trato de apañarme sin añadidos a mi TFS.

    Un saludo!!!

  3. Yo utilizo para mis compilaciones Visual Build Pro. Es muy potente y de una manera sencilla te deja hacer un montón de cosas. Es totalmente visual y tiene una serie de tareas predefinidas para poder hacer tus builds “sin mucho esfuerzo”.

    Aparte de con Team System se integra con un montón más de aplicaciones. Mereca la pega echarle un ojo si tener una aplicación de pago no es problema

  4. buenas …
    excelente post, y resalto la frase inicial -> ” … el simple hecho de contar con una herramienta que nos ayude en la tarea no significa que vayamos a adoptar una buena práctica … ” VSTS es un conjunto impresionante de herramientas, pero lamentablemente (al igual que mi cerebro) en algunos casos solo se aprovecha el 5% de su potencial.

    Creo que para lograr un escenario de desarrollo con daily builds, es necesario poseer un nivel de maduracion bastante complejo en las empresas. ¿Porq complejo?, pues porque me he visto en bastantes ocasiones tratando de justificar el tiempo de montar (y mantener !!!) un entorno de CI, cuando para algunas personas un servidor de build, simplemente compila y nada mas …

    ya m aprovechare de la url de este post, en algun futuro para poder explicar el porque de CI 😀

    Saludos desde Lisboa

  5. Estás hablando en partes de lo que es la integración continua y que es diferente al proceso de automatización. La filosofia y los objetivos de uno son disintos al otro.

  6. Juan, siento contradecirte, para nada hablo de integración continua, sino de integración frecuente. Soy un gran defensor de la integración frecuente y la construción automatizada, pero con la integración continua no lo tengo tan claro…

  7. Rodrigo:

    “nuestro software diariamente (gracias a nuestro proceso automatizado de construcción esto es algo posible) podemos obtener ventajas añadidas. Si diariamente construimos nuestro software detectáramos rápidamente problemas de integración y corregirlos cuando los cambios que pueden ser la causa aun están frescos en nuestra memoria y por tanto nos es más fácil corregirlos. Además como parte del proceso de construcción podemos ejecutar nuestros test unitarios lo que nos proporcionará la posibilidad de detectar errores no solo relacionados con la integración.”

    Me puedes decir en que parte esto se diferencia de integración continua? Es porque lo haces una vez al día que a eso le llamas frecuente? Es cierto que la integración continua debe tener un intervalo menor, pero el principio se basa en lo mismo, integrar frecuentemente y ejecutar las pruebas necesarias.

  8. Aúpa Juan!!!

    La diferencia entre integración continua y construcción diaria es clara. En construcciones diarias (o integración frecuente) cada cierto periodo de tiempo preestablecido, sin embargo en integración continua cada vez que un desarrollador integra algo de código en el gestor de fuentes se realiza la construcción de todo el proyecto.

    La diferencia entre ambas tecnicas que a priori no parece mucha se hace evidente al trabajar con uno u otro modelo. La principal diferencia es que con integración frecuente es responsabilidad del desarrollador asegurar que el código compila y los test se ejecutan satisfactoriamente antes de integrar. En integración continua esto se hace en el servidor de builds cada vez que se integra código (aunque logicamente también debe hacerlo el desarrollador).

    En una primera aproximación es más sencillo mantener un entorno de integración frecuente que un entorno de intagración continua, sobre todo si se despliegan los resultados a un entorno de pruebas o preproducción, aunque es cierto que la integración continua añade algunas seguridades adicionales pues no queda en la mano del programador el correr los test. De cualquier modo, esto es algo que se puede mediante políticas en Team System.

  9. >Aúpa Juan!!!

    Lo de aúpa no se a que viene.

    >La diferencia entre integración continua y construcción diaria es clara. En construcciones diarias (o integración

    Que es lo que yo te he preguntado en el primer comentario, si tu consideras eso la diferencia.

    >frecuente) cada cierto periodo de tiempo preestablecido, sin embargo en integración continua cada vez que un
    >desarrollador integra algo de código en el gestor de fuentes se realiza la construcción de todo el proyecto.

    Nadie dicta que una integración continua no pueda durar un día. Algunos equipos trabajan con builds de 1 minuto, otros con 4 horas y otros una vez al día. Con que frecuencia es ya cuestión de gustos y de los objetivos de cada equipo.

    El hecho de integrar y ejecutar pruebas unitarias como bien dices y ver que la integración no rompe partes del proyecto a nivel global es el fundamento detrás de la integración continua. Que tu lo llames frecuente porque lo haces una vez al día, pues muy bien. Pero el concepto es el mismo.

    >principal diferencia es que con integración frecuente es responsabilidad del desarrollador asegurar que el código >compila y los test se ejecutan satisfactoriamente antes de integrar. En integración continua esto se hace en el

    No señor. En integración continua, el desarrollador también es responsable de que sus pruebas se ejecuten localmente. Lo que se hace en el servidor son pruebas de integración. Nadie impone que pruebas locales no se puedan hacer localmente.

    >test. De cualquier modo, esto es algo que se puede mediante políticas en Team System.

    La integración continua es una mentalidad. Las herramientas están ahí para ayudar. Que sea Team System o CruiseControl.NET or Drako or mil opciones más.

  10. Lo que aúpa es un saludo. Equivalente a hola.

    A ver, tienes un error de concepto claro. Cuando se habla de integración continua la ejecución de la build no se hace de manera periodica cada cierto intervalo de tiempo, sino cuando siempre que se integra código en el gestor de fuentes. Si no es así no hay integración continua.

    La integración frecuente es guiada por intervalos de tiempo. Se hace un build cada cierto periodo de tiempo determinado según las necesidades del proyecto, tipicaménte de manera diaria.

    Creo que en el post está claro que se persigue con la integración continua o frecuente, que son dos herramientas similares pero con matices diferenciadores, para conseguir evitar problemas de integración y acortar el ciclo codificación-construcción-prueba y hacerlo menos propenso a errores.

    Con el tema de los test creo que no has leído bien mi comentario o que no ne he expresado con suficiente claridad. En cualquiera de los dos casos el desarrollador antes de integrar código debe correr los test localmente. La diferencia en integración continua es que cuando en el momento exacto en que se integre efectivamente el código en la base de código del proyecto los test se volverán a correr.

    El matiz que tu haces, separando los test de integración del resto de test ha quedado obsoleto. La técnica recomendad actualmente es correr todos los test (excepto los de aceptación) como parte de la build.

    Con esto espero que el tema haya quedado claro, porque creo que estamos mareando la perdiz. El único proposito del post era animar a la gente que lo lea a automatizar sus builds.

    Saludos!!!

  11. Gracias por tus comentarios. No creo conveniente entrar a debatir los conocimientos que cada uno de nosotros pueda o no pueda tener. No es el lugar ni a nadie le interesa. Lo que yo estoy intentando decirte con mis comentarios es que lo que propones de integración, que tu llamas frecuente no es ni mas ni menos que integración continua. Lo de los tests obsoletos depende de nuevo de cada empresa, cada equipo. Éstas técnicas existieron mucho antes de que Microsoft los adoptara (y aún en eso lo ha hecho mal) con Team System.

    De todos modos, lo dejamos ya aqui.

    Gracias.

  12. Buenas

    perdón que me meta, pero tanto CI y CF, me terminaron mareando mi perdiz. Lo mejor (like always) es ir a ver que dice uno de los grandes -> he aqui el resultado: http://www.martinfowler.com/articles/continuousIntegration.html

    Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

    Integracion Continua (CI) es una practica donde todos los miembros de un equipo integran su trabajo cada determinado periodo de tiempo, usualmente un dia :D. Esto se hace para bla bla bla …
    Los comentarios van por el mismo lado (casi) salvando el caso de los procesos de build/test frente a otros eventos ademas de un schedule, como son un check-in, una nueva version, etc.

    Como bien dice Juan, éstas técnicas existen desde hace mucho tiempo; y parafraseando a Rodrigo, la idea es que la gente se anime a buildear y testear automaticamente, yo como consultor todavía estoy alucinado con la cantidad de gente que desconoce estas practicas 😀

    Saludos

  13. Buenas

    Estoy introduciendo los procesos de Integracion Continua en los nuevos proyectos de mi sección, especializada en aplicaciones web .net

    Os subscribo un articulo de mi blog en donde describo por encima los pasos a seguir para incorporar esta forma de trabajar.

    http://shamragnar.blogspot.com/2008/04/avui-toca-una-mica-de-feina-integraci.html

    i mi mayor fuente de información, los articulos “Automating Your Builds With NAnt” de Jean-Paul S. Boodhoo’s Blog –> http://www.jpboodhoo.com/blog/

    Ahora bien a ver si alguno de ustedes puede acabar de ayudarme, pues como colofon me falta conseguir realizar la construcción de ficheros del website

    shamragnar [at] gmail.com

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *