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!

Always ship trunk

Paul Hammond product manager de Flickr hizo una presentación en Velocity 2010 donde hablaba lo anticuados que están los sistemas de control de versiones cuando toca crear aplicaciones web.

Durante los últimos años parecía que SVN se había convertido en el rey de los sistemas de control de versiones, pero pronto aparecieron nuevos jugadores. Mercurial y Git son formas diferentes y más distribuidas de controlar el ciclo de desarrollo de software, pero según Paul, ninguno de todas estas alternativas está realmente pensada para el desarrollo web. Y lo cierto es que si lo pensamos fríamente y dejando a un lado las preferencias personales, no le falta razón.

La principal razón para crear una rama ha sido siempre la misma. Ese cliente que pide esa funcionalidad especial, que además la tenemos que hacer para ayer, y que vamos a dedicar a unas personas concretas a que la hagan mientras que el resto del equipo hace sigue con su desarrollo. Esas ramas pueden quedarse ahí o ir adquiriendo vida propia, e incluso evolucionar a productos nuevos, quien sabe. Pero el desarrollo en ramas, tal y como comenta Paul Hammond, parece estar más orientado a las aplicaciones tradicionales de servidor o de escritorio que a la web.

Paul argumenta que en la web no hay versiones, hay la versión. Esa es la versión que manejarán tus usuarios. Bueno, en realidad no es así, no es tan fácil. Tenemos entornos de producción, pre-producción, desarrollo, betas, QA, unos tendrán unas funcionalidades, otros tendrán otras funcionalidades. Incluso podemos querer probar ciertas funcionalidades en producción pero en modo oculto, o habilitarlas para un cierto subconjunto de usuarios, o tener la capacidad de habilitar o deshabilitar ciertas funcionalidades en tiempo real, o hacer tests A/B para comparar la efectividad de ciertos cambios, y un largo etcétera de posibilidades.

¿Existe algún sistema de control de versiones que te ayude a hacer esto? No, o al menos Paul no lo conoce (yo tampoco). La solución son añadir condiciones al código. Todo esto añade complejidad y puede ser bastante peligroso, pero por otra parte resulta muy efectivo. La recomendación general es guardar los switches en algún lugar centralizado donde se pueden habilitar o deshabilitar fácilmente.

A mi por ejemplo esta es una de las cosas que más me gusta de Grails, copiado de Rails y que te permite tener diferentes entornos de ejecución con diferentes configuraciones e incluso crearte tus propios entornos. Todo eso lo podemos combinar con algunos interruptores que nos permitan habilitar o deshabilitar funcionalidades en tiempo real y tendremos una única aplicación en la trunk que podremos controlar a nuestro antojo.

Sencillez operacional vs. complejidad en la configuración. ¿Qué preferís vosotros? ¿Tiene sentido el tener múltiples branches en el mundo web?

PS. Tenéis el enlace a la presentación arriba, pero hay más notas aquí.

Como hacer un backup seguro de MySQL de la forma más simple

Sin duda, uno de los temas más importantes a la hora de crear una aplicación es la gestión de backups. Pero claro, qué pasa si no tenemos dinero para una SAN o una NAS, o ni siquiera un segundo servidor, o resulta que no podemos usar los servicios de cloud de Amazon o simplemente que no queremos, o peor aún, qué pasa si no tenemos los conocimiento suficientes como para hacer un backup completo...

Vaya lio. Bueno, Robin Blandford nos demuestra en un post que hasta las cosas que parecen de lo más complicado, se pueden hacer de la manera más simple. Si trabajamos con Subversion y MySQL, pues por qué no utilizar el primero para hacer backup del segundo.

Insultantemente simple:

#!/bin/sh
echo Starting Backup $(date)

mysqldump yourdbname > /var/svn/yourprojectname/yourdbname.sql

echo Dump Completed

svn ci /var/svn/yourprojectname/yourdbname.sql -m backup

echo SVN Commit Completed

echo Backup Done! $(date)
echo —

Solo quedaria poner nuestro SVN en algun otro servidor (en Internet hay algunos proveedores gratuitos) y listo respaldos incrementales que consumen poco tamaño y además offshore. Qué más se puede pedir :)

¿Algún truquillo mejor que se os ocurra?

Análisis de repositorios de Subversion con StatSVN

StatSVN es una herramienta que permite analizar repositorios creados con Subversion. El funcionamiento es muy simple y solo requiere ejecutar dos comandos: svn log y ejecutar StatSVN con ese log como parámetro. No requiere conexión al repositorio, tan sólo que te hayas descargado el código fuente desde Subversion ya que trabaja siempre con los directorios .svn locales.

Lo he estado probando y funciona bastante bien, aunque con algún proyecto me ha fallado, pero quizás sea que algún .svn estuviese corrupto. En su página tienen algunas demos

Por cierto viendo algunas de las demos se descubren cosas interesantes, como que aparentemente el 60% de las líneas de Hibernate 3 fueron enviadas al repositorio por dos personas (la realidad es que si miras los detalles no es así y el mayor commiter está ahí porque es el que crea la documentación), que en subversion hay un montón de desarrolladores con un porcentaje decente de líneas, que el 90% the Grails lo ha hecho un único desarrollador, ... Interesante :-)