subscripción
Pointer to (void)
Integración Contínua
Enero 14th, 2005 - [Enlace local]
Hoy toca considerar una de las practicas de moda en la industria de fabricación del software: la integración continua o continuous integration. No, no estamos hablando de matemáticas, estamos hablando de una forma de producir software, de forma continua.
Breves apuntes para situarse. Hoy en día, ninguna empresa seria habla de aplicaciones "sueltas", habla de productos. Un producto de software, y habrán mejores definiciones que esta, lo podríamos considerar como un conjunto formado por la aplicación, la documentación de esa aplicación y un montón más de elementos dependientes de la configuración. Por lo tanto, es claro que no basta con distribuir el ejecutable y esperar que el usuario funcione a su aire. Primer problema, necesitas productizar tu solución.
Por otra parte, cierto es que alrededor de todo producto de software trabaja un conjunto de profesionales, desde programadores a documentalistas pasando por analistas, gestores de la configuración, QA, ejecutivos y la señora de la limpieza, que su tarea hace. Toda esa gente realiza su labor en pro del producto por lo que los esfuerzos se centran, como en el remolino de tu bañera, en un solo punto. Si no coordinas bien toda esa energía, simplemente colisiona. Segundo problema, tienes veinte o treinta alfareros trabajando a dos manos sobre el mismo jarrón, y has de conseguir que acabe pareciendo un jarrón.
Así que llegamos al primer concepto de moda, que surgió creo recordar por los 90, cuando yo todavía apenas existía: Daily Build and Smoke Test. (para muestra, IEEE Software Best Practices, Steve McConnell). El concepto es simple. Invierte tiempo en construir un sistema que te permita compilar los fuentes, generar la documentación, empaquetar el producto, etc. de forma diaria y automática. Fijate que si lo haces diariamente, produces diariamente un producto. Y si es automático, reduces los errores y el tiempo que tus ingenieros invierten en la integración. La gente de Perforce, por ejemplo, recomienda mantener tres ramas: la principal, donde se añaden nuevas características diariamente, la rama de mantenimiento, que afianza las características ya añadidas, y la rama release, donde reside el código estable. Por lo tanto, dentro de este workflow se puede establecer un ciclo continuo de producción de la solución final que te permita evaluar la calidad, determinar el estado del proyecto y ayudar a que tus ingenieros y la señora de la limpieza puedan ir integrando nuevas características o correcciones, entre ramas y de forma ordenada, a la solución.
Basta de palabrería, para aquellos cuyas mentes pertenezcan a .NET, literalmente, NO es buena solución utilizar un archivo de solución de VisualStudio.NET, aglutinar un montón de proyectos dentro y compilar conforme te vayan dando, plus copypaste docs and stuff... No!! La respuesta viene de Java, es para .Net, es opensource y se llama... NAnt!! Es simple. Creas un directorio, escribes un documento XML con extension .build siguiendo unas pautas, ejecutas nant en la línea de comandos y pasados unos segundos, tienes tu producto. Cierto, podrías usar un script, pero es un verdadero rollo tener que escribir la línea entera de csc.exe y demás. Un ejemplo sacado de la documentación:
Ya sabes automatizar tu producción, le toca el turno al título del post... uf, me alargué demasiado hoy... La idea: producir el build tras cada integración de código en lugar de hacerlo diariamente. Fácil, sencillo, práctico y acelerado. Recomiendo la lectura de un articulo de Martin Fowler: Continuous Integration. ¿Y cuales son esta vez tus herramientas? CruiseControl.NET y Draco.NET, y sí, los dos son gratuitos. El primero ha sido desarrollado por la conocida ThoughtWorks, que parece trabajar muy a la mano de Microsoft, y sino, mirad el obligado libro de lectura gratuito Enterprise Solution Patterns Using Microsoft .NET. El segundo, más sencillo de utilizar, pero igualmente efectivo. Existe un articulo en TheServerSide que habla de ellos dos más en profundidad: Continuous Integration with CruiseControl y Draco.NET.
¿Cual de los dos utilizar? Mi recomendación: si no planificas bien tu proceso de desarrollo o no estas seguro de lo que pensará la señora de la limpieza de todo esto, empieza con NAnt y builds diarias en pequeños proyectos, documenta tu proceso, descansa y optimiza ese flujo de trabajo. Después ya puedes lanzarte al ruedo CruiseControl o Draco.
PD: Para el que no crea en NAnt, Microsoft pretende sacar algo parecido llamado MSBuild en Whidbey.
Por cierto, sin palabras, Mac mini, 489€.
Breves apuntes para situarse. Hoy en día, ninguna empresa seria habla de aplicaciones "sueltas", habla de productos. Un producto de software, y habrán mejores definiciones que esta, lo podríamos considerar como un conjunto formado por la aplicación, la documentación de esa aplicación y un montón más de elementos dependientes de la configuración. Por lo tanto, es claro que no basta con distribuir el ejecutable y esperar que el usuario funcione a su aire. Primer problema, necesitas productizar tu solución.
Por otra parte, cierto es que alrededor de todo producto de software trabaja un conjunto de profesionales, desde programadores a documentalistas pasando por analistas, gestores de la configuración, QA, ejecutivos y la señora de la limpieza, que su tarea hace. Toda esa gente realiza su labor en pro del producto por lo que los esfuerzos se centran, como en el remolino de tu bañera, en un solo punto. Si no coordinas bien toda esa energía, simplemente colisiona. Segundo problema, tienes veinte o treinta alfareros trabajando a dos manos sobre el mismo jarrón, y has de conseguir que acabe pareciendo un jarrón.
Así que llegamos al primer concepto de moda, que surgió creo recordar por los 90, cuando yo todavía apenas existía: Daily Build and Smoke Test. (para muestra, IEEE Software Best Practices, Steve McConnell). El concepto es simple. Invierte tiempo en construir un sistema que te permita compilar los fuentes, generar la documentación, empaquetar el producto, etc. de forma diaria y automática. Fijate que si lo haces diariamente, produces diariamente un producto. Y si es automático, reduces los errores y el tiempo que tus ingenieros invierten en la integración. La gente de Perforce, por ejemplo, recomienda mantener tres ramas: la principal, donde se añaden nuevas características diariamente, la rama de mantenimiento, que afianza las características ya añadidas, y la rama release, donde reside el código estable. Por lo tanto, dentro de este workflow se puede establecer un ciclo continuo de producción de la solución final que te permita evaluar la calidad, determinar el estado del proyecto y ayudar a que tus ingenieros y la señora de la limpieza puedan ir integrando nuevas características o correcciones, entre ramas y de forma ordenada, a la solución.
Basta de palabrería, para aquellos cuyas mentes pertenezcan a .NET, literalmente, NO es buena solución utilizar un archivo de solución de VisualStudio.NET, aglutinar un montón de proyectos dentro y compilar conforme te vayan dando, plus copypaste docs and stuff... No!! La respuesta viene de Java, es para .Net, es opensource y se llama... NAnt!! Es simple. Creas un directorio, escribes un documento XML con extension .build siguiendo unas pautas, ejecutas nant en la línea de comandos y pasados unos segundos, tienes tu producto. Cierto, podrías usar un script, pero es un verdadero rollo tener que escribir la línea entera de csc.exe y demás. Un ejemplo sacado de la documentación:
<?xml version="1.0"?>¿Y que más puedes hacer? Sincronizar los fuentes con CVS, SVN, Perforce, Clearcase, et al. aglutinar toda la documentación con NDoc, ejecutar tests automáticos con NUnit, generar un programa de instalación... Automatizar tu integración.
<project name="Hello World" default="build" basedir=".">
<description>Hello World</description>
<property name="debug" value="true" />
<target name="clean" description="remove old files">
<delete file="Hello.exe" failonerror="false" />
<delete file="Hello.pdb" failonerror="false" />
</target>
<target name="build" description="compile src">
<csc target="exe" output="Hello.exe" debug="${debug}">
<sources><includes name="hello.cs" /></sources>
</csc>
</target>
</project>
Ya sabes automatizar tu producción, le toca el turno al título del post... uf, me alargué demasiado hoy... La idea: producir el build tras cada integración de código en lugar de hacerlo diariamente. Fácil, sencillo, práctico y acelerado. Recomiendo la lectura de un articulo de Martin Fowler: Continuous Integration. ¿Y cuales son esta vez tus herramientas? CruiseControl.NET y Draco.NET, y sí, los dos son gratuitos. El primero ha sido desarrollado por la conocida ThoughtWorks, que parece trabajar muy a la mano de Microsoft, y sino, mirad el obligado libro de lectura gratuito Enterprise Solution Patterns Using Microsoft .NET. El segundo, más sencillo de utilizar, pero igualmente efectivo. Existe un articulo en TheServerSide que habla de ellos dos más en profundidad: Continuous Integration with CruiseControl y Draco.NET.
¿Cual de los dos utilizar? Mi recomendación: si no planificas bien tu proceso de desarrollo o no estas seguro de lo que pensará la señora de la limpieza de todo esto, empieza con NAnt y builds diarias en pequeños proyectos, documenta tu proceso, descansa y optimiza ese flujo de trabajo. Después ya puedes lanzarte al ruedo CruiseControl o Draco.
PD: Para el que no crea en NAnt, Microsoft pretende sacar algo parecido llamado MSBuild en Whidbey.
Por cierto, sin palabras, Mac mini, 489€.