Integración Contínua
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:
<?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€.
posted by Luis Belloch at 01:56 | permalink
16 comentarios
Comentad por favor, comentad, que necesito un tirón de orejas... xDDD
(Se permiten posts anónimos)
2:25 AM
El otro día hablando del tema, y obligandome a replantear la situación, surgió la siguiente pregunta: si tu producto tarda en generarse 4 o 5 horas, ¿cómo es posible "integrar continuamente"? En más de un sitio he leido que el lanzamiento del proceso de generación (build) se produce cada vez que se modifica algo; erroneamente o no, dos ideas rápidas sobre ello:
1. Si se añade algo, debería generarse una porción del producto y evitar el reprocesado de la solución completa... ¿como mitigas los efectos colaterales en el caso de que tu aplicación no esté bien diseñada? ;)
2. Integras continuamente para reducir el tiempo entre errores de integración y por tanto aumentar la tasa de producciones correctas al resolver errores en un mismo dia, no entre día y día. Teniendo en cuenta esto, simplemente regenera el producto cuando lo necesites y ante todo, evita que algunos de tus desarrolladores vayan por delante de otros. Desarrolla "en bloque temporal" y ciñete a la política de tu rama release, los cambios, a test.
(Que rollo tengo a estas horas de la noche, dios.. lo siento, no me pude contener al llegar a casa con una buena idea!!)
2:44 AM
El caso es que me gustaria comentar, pero... me quedé en C, Access, Ensamblador, e incluso COBOL!
como comprenderás me suena un poco raro. Lo siento!
Eso si... Interesante, debe serlo!, porque lo que tu escribes me mola siempre. Pero esta vez no lo capto :)
6:20 PM
Hola Luis, he descubierto hoy tu página web a través de las referencias a la mía (por cierto, muchísimas gracias por el enlace).
Siento ponerte esto aquí, ya que no va sobre el artículo que has escrito, pero he buscado en tu perfil y no he encontrado tu correo electrónico, y es que quería sindicar tu página pero el enlace que tienes no funciona.
Por cierto, muy interesante este post, veo que hay muchísimo que aprender sobre el tema, aprovecharé ahora que voy a empezar con .NET :-)
Ah, y el Mac Mini es CARÍSIMO jejeje xD
10:03 PM
Felicidaddes por la bitácora. La he conocido hoy y me gusta. Sigue asi.
12:29 AM
D'0h!
Te debo un e-mail!
11:50 AM
lo espero, lo espero.. ;-)
Por cierto, muy bueno el preview de los comentarios de tu blog. Tienes buenas ideas "usables".
10:53 PM
Coincido en que herramientas como NAnt/Ant le facilitan a uno la vida. Yo uso Ant y en la catedra de objetos en la que estoy también enseñamos como usarlo. En Proyectos chicos quizas no se ve bien la utilidad, pero en cuanto uno se encuentra todos los dias haciendo lo mismo para tener algo mostrable a tus clientes es algo fundamental.¿ Por que? porque siempre hace lo mismo y no se equivoca, en cambio hacer todas esas tareas a mano sí es fuente de errores.
Generalmente cuando uno quiere mostrar su programa realiza siempre los mismos pasos, en uno de mis proyectos hacia por lo menos estos:
-borrar todo lo generado
-recompilar todo el codigo
-generar el ejecutable
-limpiar los archivos de configuración
-reemplazar la base de datos por una que estuviera limpia
-generar el instalador
-subir el instalador al ftp para descarga publica
La cuestion es que mientras que esto no fue automático, siempre habia algun olvido y nada funcionaba por lo que cada deploy terminaba llevando un par de dias hasta que todo anduviera bien
Este proceso que hacía todo el tiempo no deja de ser un algoritmo.
Si nos la pasamos programando y diseñando ¿por que no vamos a hacer lo mismo con el deploy? Al fin y al cabo estudiamos para que las cosas mecanicas no las tengamos que hacer nosotros.
Este tipo de herramientas nos ayuda a concentrarnos
en temas donde sí somos mas eficientes que una máquina y le dejamos a estas el trabajo tedioso y repetitivo que tan bien saben hacer.
Por lo que veo, hace unos años que el mundo del software apunta a automatizar las tareas. Generadores de código que arman toda la capa de persistencia a partir de un diagrama de clases,
herramientas como maven que arman toda la estructura de un proyecto, otras, como xdoclet que a partir de anotaciones en el código generan los archivos de configuración para los diferentes frameworks son un ejemplo de hacia adonde va la industria.
Me pareció muy interesante tu articulo y tu blog. Es la primera vez que lo leo y espero volver a pasar por acá
Me alegra saber que gente de mi edad esta tan al dia con este tipo de cosas.
Saludos desde Bs As
mamapaga
8:27 PM
Hombre!! Parece que vamos comentando... Saludos desde la otra parte del charco ;-)
Buenas puntualizaciones. Gracias por lo de DB2.
¿Tienes blog? ¿nos dejas la dirección para que podamos visitarlo?
12:53 PM
Todavia no :-(
Es una de las cosas que quiero hacer este año en cuanto disponga del recurso mas deseado en estas épocas: tiempo
Saludos
Mamapaga
10:09 PM
y que pasa con SCons?
8:09 PM
SCons no tiene mala pinta, pero no lo he probado como para darte una opinión firme. Supongo que herramientas hay muchas y cada uno se decanta por lo que le resulta más útil y atractivo.
Personalmente, NAnt juega una parte importante de mi trabajo diario, pero no descarto otras cosas!! Gracias por el apunte!!
12:59 AM
Pues nada, quería agradecer este artículo que me llevó a conocer Draco.net. Lo instalé y lo he puesto a funcionar junto con NAnt y Subversion y ya tengo mi HolaMundo.exe para empezar.
También aportar un enlace ankhsvn , un Add-in para Visual Studio que sirve para colocar nuestra solución de VS.net en un repositorio de Subversion, ya que en este artículo se menciona la aparente mala costumbre que se tiene a la hora de hacer builds automáticos.
Las herramientas para hacer builds automáticos existen des de hace la tira de años. No es algo nuevo ni mucho menos. Yo utilicé muchas desde tiempos de Cobol (80's y 90's) y era muy fácil: o pasabas el "batch build" o no había "runcobol ...". O en clipper más de lo mismo: PLink o nada de exe.
Pienso que en gran medida la linea de producción que había antes se ha perdido. Más en algunos sitios pequeños donde hay poco tiempo para planificar y se improvisa con el point-and-click o donde no hay un arquitecto de sistemas. Tambien pienso que los IDE y más los gráficos han dejado un poco en segundo término las utilerías de linea de comandos donde solían realizarse este tipo de automatizaciones. Al menos siguen existendo (como en VS.NET) pero que no se promueve su uso.
No estoy en contra de los IDE gráficos en absoluto. Creo que facilitan en gran medida trabajos que serían engorrosos si no existiesen. Tanto así que utilizo VS.net y me parece un gran producto y también hay otros que mejorarán como Sharpdevelop, Eclipse o Netbeans. Es decir, que hay que pensar en lo que queremos y saber lo que podemos hacer así como profundizar en el conocimiento de nuestras herramientas para aplicarlas mejor.
Pues eso, mis 5 cents.
12:03 AM
Ante todo, gracias por comentar! no lo hace mucha gente por aqui...
Un punto de vista interesante, yo he crecido entre entornos graficos y he tenido que ir descubriendo la línea de comandos poco a poco, supongo que la gente más veterana en estas cosas le sacará más partido. A ver que nuevas herramientas nos preparan para automatizar el proceso, MSBuild parece un buen paso.
Gracias por el enlace, no sabia que existia ankhsvn.
1:04 AM
Buenas, Segun leo CruiseControl.net hay que configurarlo todo a mano? no existe ningun GUI para configurarlo?
saludos
3:35 PM
Hombre! alguien comenta por aqui!!
Que yo sepa, no existe herramienta alguna para configurar proyectos, la configuración se realiza mediante ficheros XML convencionales.
Tampoco tiene nada de especial, puedes ver bastantes cosas y algun ejemplo que otro en http://confluence.public.thoughtworks.org/
display/CCNET/Configuring+the+Server
10:35 PM
Publicar un comentario en la entrada
Links to this post:
Crear un enlace
<< Volver