Optimizar la felicidad del equipo de desarrollo

Hace casi un año, Chad Dickerson dio una charla en la RailsConf 2011 que vale la pena leer. Se trata de una presentación de poco más de 20 minutos donde el que es el CEO de Etsy explica las claves para conseguir un equipo de desarrollo feliz.

Etsy, que muchos conoceréis es un sitio web que permite la venta objetos de artesanía a través de la red. Es enorme. En la charla (2011) hablaban de mil millones de visitas al día y más de 40 millones de dólares en ventas al mes. Espectacular. Pero no menos espectacular es que un equipo de 70 desarrolladores realize 25 despliegues a producción al día :)

Gerrit, un sistema de revisión de código muy jugoso

Hace unos días charlaba placidamente en una terraza de Santiago de Compostela con @pepellou y @carlisgg sobre lo interesante que era Gerrit y como resultaba curioso que un sistema basado en un repositorio de Git era la solución más natural a uno de los problemas más tradicionales de las organizaciones con muchos desarrolladores, que era el mantener la build intacta.

Tenía pendiente escribir sobre esto, pero además es que justo hoy @psluaces referencia en un comentario en el post sobre las desventajas de las ramas de desarrollo un artículo suyo, también interesante, donde se explican algunos de los problemas que alivia Gerrit. Así que, ¡qué gran excusa para ponerse a hacer los deberes y escribir este post que tenía pendiente!

Sobre las desventajas de las ramas de desarrollo

Hace unos días, gracias a @alexcuesta llegué a un gran video (al final del artículo) donde Martin Fowler y Mike Mason analizan los pros y los contras de lo que se conoce como Feature Branching. Bueno, en realidad los contras, porque en lo que exponen el 90% son contras y el 10% son justificaciones.

Feature Branching (artículo del 2009 muy completo del propio Fowler en el que se basa la charla) es una técnica de toda la vida, pero que con el auge de los sistemas de gestión de versiones distribuidos como git ha ido también ganando en popularidad, que consiste en el desarrollo de funcionalidades en ramas paralelas a la rama principal, para de este modo no afectar al desarrollo normal.

Podcast sobre test de aplicaciones

En javaHispano han publicado un podcast hace unos días donde participan Alfredo Casado, Julio César Pérez y Jose Luis Bugarín y que se lo recomendaría a todo el mundo ya que explica muy bien el por qué es tan importante hacer testing, sus beneficios y todo lo que no perdemos al no hacerlo. Al igual que comentaba yo mismo en mi charla en Alicante, de la que todavía tengo pendiente el escribir varios posts, estamos en un momento donde una persona que no haga tests no se puede considerar un buen profesional. Señores, quitémonos el chip de monos picateclas porque el desarrollo de software es mucho más, y el testing es sólo una de las habilidades que un desarrollador ha de tener. Muy buen podcast.



El podcast lo podéis escuchar aquí mismo o descargaros el MP3 original desde la página de javaHispano.

Tus builds de Hudson en Campfire

Ojeando los plugins de Hudson he descubierto de casualidad que desde hace un par de semanas está disponible un plugin para Campfire. Lo que quiere decir es que puedes configurar tus build para que publiquen sus resultados en Campfire. Para los que se nos olvida chequear el email y se nos pasa que hemos roto la build.

La página del plugin es esta y su instalación es trivial. Ojo que es necesario tener la última versión de Hudson para que funcione. Aquí tenéis el anuncio por parte de los autores. Una captura con la configuración:



Y su consiguiente resultado en Campfire:

¡Hay que respetar la build!

En una de mis últimas empresas, allá por Irlanda (como pasa el tiempo, oiga) teníamos unos 30 desarrolladores. De entre todos estos, unos 10 estaban en Polonia, los demás estábamos en Irlanda. A parte de todo esto teníamos una consultora en el Reino Unido con unas 10 personas que se dedicaban a mantenimiento. Todas estas personas podían tocar la build.

El principal, con mayúsculas, problema con el que nos encontrábamos era la cantidad de commits que se hacían. El proyecto estaba en una fase fuerte de crecimiento así que había montones de funcionalidades que subir. Esto hacía que los commits fuesen constantes, y difíciles de controlar. Y como en toda época de rush, como no, las revisiones de código destacaban por su ausencia.

Total, que con tal cantidad de commits simultáneos, por muchos tests que hiciésemos (que se hacían) era muy habitual el romper la build. Pero ese no era el problema. El problema de verdad es que la gente seguía haciendo commits cuando la build estaba rota, lo cual presenta varios problemas:

1. No sabes que tu código va a funcionar. Por mucho que esté funcionando en tu build local, al estar la build rota, no tienes la certeza de los cambios que ha subido otra gente, así que nunca sabes si esos cambios te pueden afectar.
2. Si no se protege la build, os cambios se acumulan. Todos esos cambios, son cambios no probados en un entorno de integración. Cuanto más tiempo pase, más grande es el problema. Cuantos más commits se acepten con una build rota, más problemas potenciales están entrando en el código. El número de errores crece. El código se vuelve más inestable.
3. A mayor número de cambios, más difícil es el recuperar la build. Si los cambios se van acumulando y acumulando, nos encontraremos que al corregir el primer error aparecen más errores. La única solución que queda es ir corrigiendo error tras error hasta que la build vuelva a funcionar. Cuanto más código incontrolado permitamos, más tiempo nos llevará arreglar la build.
4. En el peor de los casos, no hay otra solución que volver atrás. En el peor de los casos nos encontraremos con que el código que se ha subido se cruza y no queda más remedio que revertir los cambios, con la consiguiente perdida de tiempo. Los equipos tendrán que pararse y ver por qué sus funcionalidades se han solapado.

Todo esto se ilustra en la captura de pantalla siguiente:



Entre 1 y 2 hay un montón de commits. Llega un momento en el que alguien se da cuenta de que se ha roto la build, y comienza el proceso de arreglar la build. En 2 se arregla algo, pero no es suficiente. En 3 algo más, pero sigue sin ser suficiente. En 4 finalmente se arregla, pero han sido necesarios 10 arreglillos para conseguirlo. Cuando si la build se hubiese arreglado en el momento de detectar el error no se hubiese perdido tanto tiempo.

¿Soluciones?

• Involucración del equipo. La build debe de ser colectiva y todo el mundo tiene parte de responsabilidad en controlar que esté siempre sana. Muy a menudo la responsabilidad recae sobre el jefe de equipo, y si este falta se hace la vista gorda. Esto al final perjudica a todos. Si alguien ve que la build está rota, debe alertar de ello e investigar a ver qué está pasando.
• No hacer commits si la build está rota. Tan simple como esto. Si la build se rompe, lo mejor es no hacer commits. No importa que el código sea muy urgente. Como desarrolladores, si hacemos commits, puede ser mucho peor para nosotros. Es mucho más efectivo el esperar a que la build esté estable y subir el código con la seguridad de que no vamos a romper nada. Además, así nadie nos meterá en el lio de arreglar la build después ;)
• La técnica de la botella. Si las dos primeras no funcionan, la técnica de la botella es super-efectiva. Ya había escrito sobre eso aquí. Se compra una botella, que sea grande que hará falta. Cada vez que alguien rompe la build, se ponen 50 céntimos, un euro o algo así. Que no sean 10 céntimos porque entonces no duele demasiado :) Esto es mano de santo. En cuanto alguien ve que se va dejando un par de euros al día, pasa a ser mucho más cuidadoso con los cambios que hace. Además tras unos meses se puede hacer una cena a la salud de la build. La desventaja de este sistema es que no funciona demasiado bien con equipos deslocalizados :)
• No permitir commits. Podríamos bloquear el repositorio de código fuente si la build se rompe. Esta es una solución bastante drástica que normalmente es perjudicial. Puede funcionar bien sólo cuando el equipo es pequeño. Si el equipo es grande y hay mucho código, esta medida tendrá el efecto de cuello de botella.
• Revertir automáticamente el código que ha causado el error. Esta fue la medida que se aplicó en la empresa que os comentaba antes. La situación era tan complicada que no quedó más remedio que revertir de inmediato cualquier código que rompiese la build. Es un poco drástico pero dada la magnitud del problema, fue necesario. La gente comenzó a ser mucho más cuidadosa cuando veía que sus cambios se rechazaban una y otra vez.
• Build en dos fases. En sistemas y equipos complejos. Otra alternativa es mantener dos builds. Una más inestable, en la que los desarrolladores van haciendo sus commits, y otra estable que nunca fallará. La primera sería una build permisiva, pero que como siempre, habría que respetar. La segunda aceptaría sólo código que ha pasado la primera build, y siempre estaría completamente estable. La idea es que si alguien necesita el código más reciente en cualquier momento, no tenga que esperar a que se arregle la build. Esto yo lo veo como un modelo complejo sólo apto para empresas grandes que tengan necesidades muy específicas.

En fin este tema daría para mucho hablar. Seguro que muchos estais familiarizados con el mismo y lo vivis en el día a día. Me encantaría leer vuestros comentarios y saber si tenéis este tipo de problemas y que hacéis vosotros para solucionarlos.

La build y la botella

En nuestro trabajo tenemos una botella como la de la foto. Bueno, en realidad es muuuuucho más grande. De un metro más o menos. Es de publicidad de Heineken, de esas de plástico. Tenemos implantado un Cruise Control bastante básico, pero que cumple su cometido. Cuando alguien rompe la build porque ha hecho commits de funcionalidad inacabada, o funcionalidad que rompe los tests existentes, o se ha olvidado de configurar dependencias, pues tiene que poner un euro en la botella.

La verdad es que esta medida tan simple tiene unos efectos muy curiosos. El más obvio y evidente es que nadie quiere romper la build, ya que aunque sólo sea un euro, nadie quiere regalarlo. Así que los desarrolladores somos mucho más cuidadosos con lo que subimos y con no romper nada de lo que hay ya hecho.

Otro efecto muy beneficioso es la cura de modestia. A nadie le gusta ser el que rompe la build. Hoy, un chico nuevo ha roto la build por primera vez, y le tocó poner el euro correspondiente. El hombre fue cabizbajo a depositar el euro ante la guasa general que se suele montar. No es que este hombre sea inmodesto, ni mucho menos, pero es que la sensación que tuve yo la primera vez que rompí esta build es de cura de modestia. Los desarrolladores tendemos a que se nos suba el ego muy rápidamente. Y siempre viene bien que alguien nos baje los humos, aunque sea el Cruise Control, y que tengamos que darnos un paseito ante la guasa general del resto del equipo mofándose (amistosamente) de que te toca apoquinar.

Además la gente es muy legal y hoy otro chico dejaba un euro por la build que había roto ayer. Y es que a uno tampoco le gusta quedar debiendo nada, aunque sea a la botella.

La verdad es que para la cantidad de gente que estamos trabajando en el equipo, y siendo diferentes equipos trabajando en diferentes componentes interconectados, yo personalmente tengo clarísimo que la salud de la build se debe en gran medida a los efectos de esa botella.

¿Estáis usando integración continua en vuestro equipo? Mi consejo, usar una botella. Hará de la build algo más estable y además añade un toque de diversión al día a día. Ah, y a final de año, pues siempre se puede hacer una cena con el dinero de la botella. ¡Faltaría más!

Foto by ^Vanessa^@Flickr

Configurando Hudson para proyectos Grails

Como parte del desarrollo de Jobsket, una de las cosas que hemos hecho es el preparar un servidor de integración continua para intentar mantener nuestras builds lo más estable que sea posible.

Grails, no tiene ningún plug-in ni soporte específico para ningún sistema de integración continua así que decidimos descargarnos e instalar Hudson. La principal razón para instalar este sistema de integración continua es que es muy sencillo de instalar y administrar, ya que toda la configuración se realiza desde el UI de la propia aplicación, con sus bonitos componentes AJAX, sin necesidad de andar tocando ficheros de configuración.

Hudson está por defecto preparado para trabajar con Java, pero configurarlo con otros lenguajes o frameworks no debería dar ningún problema. Aquí no os voy a aburrir con los pasos para instalar y configurar Hudson, sino que comento simplemente los cambios necesarios para integrar un proyecto de Grails son tan sólo dos y son realmente muy simples:

Primeramente configuramos nuestra build para ejecutar un shell script. Este script contendría los pasos necesarios para la ejecutar nuestros tests o la build o lo que queráis. En nuestro caso el script es realmente sencillo ya que simplemente estamos interesados en ejecutar los tests, pero si tenéis otros requisitos podéis ejecutar directamente cualquier script de Ant o Gant, lanzar Maven, o lo que sea.



Lo segundo es simplemente hacer que Hudson lea nuestros informes de test. Por defecto Grails los coloca en el directorio test/reports, así que simplemente le decimos a Hudson que los busque ahí:



Una última cosa importante que no he comentado es que no os debéis olvidar de ajustar todos los settings necesarios para ejecutar grails, como por ejemplo:

export PATH=$PATH:/opt/grails-1.0.1/bin
export JAVA_HOME=/opt/java/jdk1.6.0_03
export GRAILS_HOME=/opt/grails-1.0.1

Hudson te permite configurar desde el UI la JAVA_HOME pero el resto lo tendréis (creo) que añadir vosotros en alguna otra parte. Yo por ejemplo tengo todo esto en el script que se arranca al loggearse el usuario, pero vosotros lo podéis poner donde queráis, como por ejemplo en el script que vimos antes que ejecuta los tests.

Pues eso es todo, no debería llevar más de 10 minutillos. Rápido y sencillo.

El rol de build engineer

Una de las posiciones que más hemos intentado presionar donde trabajo para que se contratase es la de release/build engineer.

No cabe duda que hoy en día construir software es más complejo (no necesariamente más difícil) que hace años. La cantidad de diferentes sistemas que intervienen en el funcionamiento de una aplicación hace que crear una release sea mucho más complicado que hace años donde casi sólo había que preocuparse por crear un fichero ejecutable para su correspondiente plataforma.

Hoy por hoy nos encontramos que cualquier mínimo software involucrará aplicaciones de escritorio, applets o RIAs, contenedores web, servidores de aplicaciones, sistemas de mensajería, interfaces o servidores de terceros, etc. Asimismo, la integración continua (incluso aunque nos ponga en evidencia) se ha convertido en una práctica fundamental a la hora de lanzar software a tiempo. Sin embargo, está claro que a medida que el software se hace cada vez más y más complejo el mantener este proceso de integración continua se hace más complicado. Y es que hay que tener en cuenta que el proceso de integración continua no se limita únicamente a compilar el código fuente y asegurarse de que no se ha roto la build , si no que es necesario construir un sistema "vivo" que nuestro departamento de QA pueda utilizar para asegurarse de que realmente no se ha roto nada.

Para intentar solucionar este problema se introduce el rol de build/release engineer. Hoy por hoy si se busca en los portales de empleo se encuentran ofertas de empresas que buscan cubrir este tipo de vacante, aunque es cierto que tampoco son demasiadas. Por ejemplo hoy he estado buscando en las ofertas de Irlanda y sólo he encontrado tres o cuatro en el portal que suelo seguir.

La verdad es que por experiencia propia puedo decir que aunque el rol está justificado lo cierto es que es complicado encontrar a alguien que se quiera dedicar exclusivamente a mantener la salud del sistema de automatización de una empresa, por mucho que este rol te permita aprender como funcionan internamente muchos sistemas. Al fin y al cabo, quién quiere pasarse meses pelando con scripts y ficheros XML, ¿no?

Por lo tanto, en el caso de reconocer el valor de build engineer y no poder contratar a uno, ¿qué se puede hacer? Básicamente se me ocurren dos soluciones:

• Promocionar a alguien de QA: Normalmente (al menos aquí) los testers suelen ser graduates o personas con conocimientos informáticos pero que nunca se han dedicado a programar o que ni siquiera han estudiado realmente informática. Muchas de estas personas son realmente buenos en lo que hacen y llegan a tener un conocimiento global del funcionamiento del sistema mucho mejor que muchos desarrolladores.
  
  Algunos de estos testers con el tiempo van ganando experiencia y conocimientos que les permitirían pasar a ejercer un rol de build engineer, que a fin de cuentas está directamente relacionado con todo el proceso de QA, así que podría verse como un tipo de promoción natural.


• Asignar el rol de build engineer a todo el equipo: Para mi es importante resaltar aquí lo de "todo el equipo". Ya que todos sabemos lo que va a pasar si un desarrollador se dedica a configurar la build el sólo, es decir, que se convertirá de manera no-oficial en el build engineer, y que siempre que pase algo acudiremos a él a ver si lo puede solucionar.
  
  Rotando el rol de build-engineer entre los diferentes miembros del equipo, por ejemplo haciendo que cada semana uno ejerza ese papel, se consigue que todo el mundo acabe por tener un conocimiento de la build y que se mejore también el conocimiento global de como funciona el sistema. Al principio puede hacerse tedioso y engorroso, por eso de que todos tenemos muchas cosas que hacer para andar aprendiendo todos lo mismo, pero con el tiempo y cuando los errores aparezcan todo el grupo habrá adquirido el conocimiento para solucionar los problemas de automatización y no se dependerá del release engineer que vuelve dentro de un mes y se ha ido de vacaciones.

Por cierto, que si os lo estáis preguntando, pues nosotros por ahora nos hemos quedado en un termino medio. Cuando llegué no había nada de nada, pasados unos meses conseguimos un build engineer, pero con el tiempo lo perdimos, y ahora, pues bueno, como al final nuestra automatización ha llegado a niveles bastante avanzados y es bastante compleja pues requiere mucha dedicación, así que hay un equipo digamos de "gestión de procesos" que se dedica a controlarla, siendo algunos de los miembros de este equipo también desarrolladores. Es decir, que en lugar de involucrar a todos los desarrolladores lo que puede ser un poco utópico pues se escogen a tres o cuatro y se les asigna la responsabilidad de estar pendientes de eso como parte de su tiempo.

ThoughtWorks anuncia CruiseConstrol Enterprise

Después de seis años parece que ThoughtWorks se ha decidido a comercializar (ellos lo llaman adaptar el software a la nueva web) el ubicuo CruiseControl y han anunciado el lanzamiento de CruiseControl Enterprise.

Resulta muy curioso que con la cantidad de productos que han explotado ya el mercado durante tanto tiempo, sea ahora cuando al final se hayan decidido a sacar sus buenos euros de la operación cuando otras compañías como JetBrains o PMEase ya están aprovechando ese mercado hace tiempo.