Buildbot: ¿Que?

Este es el segundo post sobre django-yabe, mi propio blog engine.

Primero un poco de background, a principio de año lei el libro “The productive programmer”.

The Productive Programmer

La verdad no es un gran libro, me deje llevar por un par de reviews y el glosario parecía interesante, pero resulto ser una colección de anécdotas (algunas muy buenas) y alguna que otra analogía que me ayudaron a entender mejor algunos conceptos, pero el resumen del libro se puede hacer en una palabra: automatizar.

Automatizar es genial: cualquier trabajo repetitivo es propenso a errores cuando lo realiza una persona, en cambio cuando lo hace una computadora no. Una computadora no se “olvida de un parámetro” o “se saltea un paso”, la computadora hace lo que le digamos y listo (Si sabemos decírselo es otro tema). Y dentro de la creación de software existen muchas tareas que se pueden hacer de forma automática, una de ellas es la integración continua (del ingles Continuous Integration):

Integración continua es una practica del desarrollo de software donde los miembros de un equipo integran su trabajo frecuentemente, normalmente cada persona integra su trabajo al menos una ve por día – dando múltiples integraciones por día. Cada una de estas integraciones es verificada por una construcción automática del software (incluyendo los tests) para detectar errores de integración tan rápido como sea posible. Muchos equipos encontraron que este acercamiento llevo a reducir significativamente los problemas de integración y permitió al equipo a desarrollar software de una forma mas rápida.

Martin Fowler, Continuous Integration

El primer paso para la integración continua se logra teniendo el código fuente de la aplicación en algún sistema de control de versiones (SCM por sus siglas en ingles). Particularmente a mi me gusta Mercurial por ser distribuido y simple, pero existen otras opciones como GIT y Subversion. El segundo paso es tener una construcción automática (automated build).

¿Que es un “automated build”? Del mismo texto de Fowler:

Hacer que el código fuente se convierta en un sistema funcionando puede ser un proceso complicado que involucre compilar, mover archivos, cargar esquemas en las bases de datos y mas. Pero, como la mayoría de las tareas en el desarrollo de software, puede ser automatizada y, como consecuencia de esto, debe ser automatizada. Pedirle a personas que escriban comandos o hagan clicks en ventanas de dialogo es una perdida de tiempo y un campo fértil para errores.

Así que entendemos a un automated build como tomar el código fuente y llevarlo a un sistema andando, en el que corremos las pruebas de forma automática. ¡Eso es perfectamente scripteable! Puede hacerse un hook para el SCM que elijamos que cuando recibe un commit se encargue de correr un script que compile el código (en este caso en particular estoy usando Python para el proyecto, así que no se compila, ¡pero puede correr los tests!), es tan fácil que me sorprende que nadie lo halla hecho ya… Hudson, CruiceControl o Bitten (de los creadores de Trac) son algunos de los que ya lo hicieron, y hay muchos mas en la pagina de Wikipedia al respecto. De hecho ayer anunciaron en Mozilla que van a empezar a utilizar Hudson para el desarrollo de la pagina de Addons de Firefox y Thunderbird.

Mi gusto particular en herramientas de CI es BuildBot. La primer razón por la que me gusta es porque esta hecho en Python, y se puede extender y configurar utilizando este lenguaje. Eso es una ventaja grande porque en el espíritu de ser DRY puedo hacer que configuraciones como “a quienes avisarles por email cuando falla un build” puedo, en lugar de escribirlas en la configuración, hacer que las lea dinamicamente de la base de datos de Redmine o Trac para el proyecto en cuestión. La segunda es que es muy completo, tiene distintas formas de notificarte, trabaja con muchos SCM (Subversion, Mercurial, GIT, ¡hasta CVS!) y tiene una documentación que es muy buena como referencia, aunque lamentablemente es pésima como introducción.

Así que el plan para el próximo post es configurar que cuando subo código al repositorio de Mercurial para django-yabe, BuildBot haga un build (Django tiene un framework de unittesting muy completo) y me avise por email si fallo.

3 Responses to “Buildbot: ¿Que?”

  1. Santiago Says:

    Piola. Ahorrás unos cuantos pasos testeando. Lo que me pregunto es el grado de complejidad que podés aplicarle a los tests en sí. Sobre todo para esos models que ni graficados se termina de descifrar en qué casos puede fallar.


  2. qwerty Says:

    No es extremadamente complejo. Y lo cierto es que hay partes mas dificiles de testear que otras, pero con algo de creatividad se puede probar todo.

    El caso particular de los modelos: ¿Que es lo que queres testear? Django te crea una base de datos pelada y te deja cargarle fixtures cada ves que corres los tests cases, es realmente muy completo a tales fines.

    Y en los casos donde aparece un bug por el que no habias testeado, haces un regression test: Escribis un test case que pruebe la existencia del error, y despues programas hasta que el test case pase.


  3. Diario de un programador » Archivo del blog » Como configurar Buildbot Says:

    [...] el post anterior sobre django-yabe escribí sobre que es la Continuos Integration y como, de las distintas herramientas que existen, [...]


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>