Integración continua es tener un sitio donde, periódicamente, tus proyectos se compilen y se lancen los tests para que el código fuente este sano, es decir, que cualquiera que se lo baje sepa que esta funcionando y nos olvidemos de “en mi máquina funciona”.
En el mundo .NET es muy habitual tener un TFS y las builds configuradas dentro del mismo, pero si no tenemos un TFS por lo que sea, podemos usar HUDSON para montarnos nuestro entorno de CI.
Hudson es un veterano del mundo UNIX/Linux que ha sido portado a Windows en forma de ejecutable stand-alone, para lanzarlo manualmente cuando lo necesitemos, o como servicio de Windows donde está disponible continuamente, ademas de poseer un montón de módulos y plugins para conectarlo con cualquier repositorio que se te ocurra y realice una compilación de casi cualquier lenguaje. Todo ello manejado desde una simple interface web.
¿Y como lo instalamos?
Hudson está echo en JAVA así que lo primero que toca es bajarse la ultima máquina virtual si no la tienes ya e instalarla. Después nos bajamos el último war de la web de Hudson y lo descomprimimos en una carpeta donde tengamos mucho espacio ya que por defecto, las builds se ejecutaran dentro del mismo (se puede configurar). Si lo piensas montar como servicio, déjalo en el escritorio, abre una consola (cmd) y ejecuta
java –jar hudson.war.
En estos momentos Hudson lanzará un sencillo servidor web en el puerto 8080, entrando con nuestro navegador favorito a http://localhost:8080 nos aparecerá un menú tal que así:
Pinchando en instalarlo como servicio, ahora sí, tendremos que especificar una carpeta donde quedará instalado permanentemente
Una vez instalado el mismo nos da la opción de parar la instancia actual de Hudson, que recordemos es plenamente funcional, y logarnos en nuestra nueva instalación de Hudson como servicio.
Si nos vamos a los servicios del sistema, veremos a la nueva criatura
Yo recomiendo dejarlo como arranque automático.
Si queremos que Hudson escuche en otro puerto diferente a 8080, nos tenemos que ir a la carpeta de instalación y cambiar dentro del fichero Hudson.xml la siguiente linea:
<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar «%BASE%hudson.war» –httpPort=8050</arguments>
Cambiando el puerto al 8050 por ejemplo
Hudson habla con nuestro .NET
Para configurar que Hudson pueda compilar .NET, tenemos que activar el plugin correspondiente, no tenemos que instalar nada ya que se baja automáticamente.
Nos vamos al panel de control de Hudson
Pulsamos en Manage Hudson y en Manage Plugins
Buscamos el MSBuild Plugin y el MSTest plugins (si queremos tener en cuenta tests unitarios), los marcamos y pulsamos en instalar.
Una vez instalados los plugis debería quedar el listado de Installed tal que así:
Hay un montón de plugins así que si os parece util la herramienta, conviene darle un vistazo a la lista de disponibles, sobre todo si usamos repositorios como TFS o Sourcesafe, que no vienen activos por defecto.
Una vez tenemos los plugins listos, tenemos que configurar la compilación con MSBuild (el plugin que acabamos de instalar), con lo que nos vamos a configure system
donde veremos una sección de MSBuild. Aquí hay que ponerle el path al ejecutbale MSBuild.exe, en mi caso:
C:WindowsMicrosoft.NETFramework64v4.0.30319MSbuild.exe
y darle un nombre identificativo.
Podemos configurar más de un entorno de compilación, por si queremos usar .NET 2.0 o .NET 4.0 indistintamente
También conviene darle un repaso a todas las opciones pero una muy util es las configuraciones por mail (al final del todo). Si cuando acabe una build y esta falla, queremos avisar a quien a enviado la build, conviene configurar el Email suffix escribiendo por ejemplo “@midominio.com”. Si bob hace un checkin al código y rompe la build, Hudson enviará un correo a bob@midominio.com
Cuando terminemos de configurar todo no hay que olvidar de darle al boton save al final de la página.
Creando un nuevo trabajo:
Vamos a ordenar a nuestro nuevo mayordomo una nueva tarea, que es la compilación de un proyecto que tenemos en el SVN cada vez que alguien haga checkin y suba nuevos cambios.
Navegamos hasta https://localhost:8080 ( o la ip del servidor) y pulsamos en New Job
Damos un nombre al trabajo, por ejemplo: Branch-8876 o «mi superbuild» (es solo una descripción) pulsamos en Build free-style software project. (podemos clonar un trabajo existente, muy util si cambiamos solo la rama donde esta nuestro proyecto en el repositorio).
Pulsamos en ok y en la siguiente página tendremos que configurar las propiedades de nuestra tarea. Yo recomiendo modificar las siguientes:
-Discard old builds para tener solo la compilación mas reciente y no usar espacio en disco duro de forma innecesaria
-Source code management: En mi caso va a acceder a una rama de SVN, con lo que poniendo la dirección http del servidor de source safe bastaría, ejemplo:
Y como quiero integración continua, usaré la estrategia Use svn update as much as possible y Clean checkout folders and then checkout para que cada vez que se lance una compilación me baje todo el código de nuevo.
En los disparadores de la build, si queremos que se ejecute en cada checkin, hay que elegir Poll SCM y en el schedule la siguiente opción “* * * * *”. Si quisiéramos lanzarla cada día a las 2 y media de la noche, escribiríamos “2 30 * * *” por ejemplo.
En el apartado build debemos elegir el que configuramos previamente y como fichero de build, elegiremos nuestro fichero sln que contiene la solución. Hudson lanzará “MSBuild fichero elegido” y entenderá el output del mismo, indicando si ha habido algún error o ha ido todo bien.
Cuando terminemos no olvidemos pulsar el botón save.
Y ya está, en la pantalla principal podremos ver todas las builds que están ejecutándose y si alguna ha ido mal con su icono rojo correspondiente ( en esta nueva versión si va todo bien aparece un sol y si va mal un icono de tormenta)
Ah, decir que es una aplicación inmensa y que tiene soporte de esclavos para distribuir los diferentes builds en escenarios complejos.
Ya no tenemos excusa para no montar un entorno de integración continua en nuestro entorno en una tarde y empezar a usarlo desde el primer día. Con una máquina modesta nos servirá para lanzar una build cada cinco minutos y dejar de esperar ese TFS que nunca llega por falta de recursos, máquinas disponibles o pánico a la nube del nuevo cloud TFS.
Como se puede integrar con Soluciones creadas en VS 2012, por ahi estamos teniendo problemas pues el MSBuild se esta perdiendo con los tags del archivo .sln 🙁
gracias!