DVCS: La herramienta definitiva para un hackathon

Un hackaton es un evento social donde programadores y diseñadores compiten en grupos durante 24 – 48h en el desarrollo de la mejor aplicación para la plataforma elegida por los organizadores. En este tipo de eventos el tiempo es un factor clave, y la posibilidad de que un error en los últimos 5 minutos destroce horas de desarrollo es muy alta, ya que se viven momentos de muchísima tensión.

En estos casos es útil contar con un sistema de control de versiones para poder tener un registro de la evolución del proyecto, y evitar perder el rumbo original.

En el último Hackatón al que asistí hace unos días pude experimentar la frustración de grupos que usaban Team Foundation Services Preview, un sistema de control de versiones centralizado y en la nube. Es una herramienta muy potente para gestión de código fuente aunque muestra algunas debilidades para este escenario en concreto:

Necesita una conexión a internet estable y constante, ya que de otra manera no se puede realizar un check-in ni un checkout, y cada operación añade una carga adicional a la red.
Es centralizado, con lo cual cada vez que se hace un check-in se integra todo el código, y si había cambios en el servidor es necesario obtener primero la última revisión y luego integrarlo en local (manejando posibles conflictos, por supuesto) antes de poder enviar los cambios de vuelta, perdiendo ese preciado tiempo del que no se dispone.

Todo esto hace que se emplee el repositorio como una herramienta de sincronización, no como un control real de las versiones del código.

Veamos el mismo escenario con un sistema de control de versiones distribuido (DVCS):

Cada miembro del equipo puede desarrollar su código de manera independiente en una rama, y hacer commits frecuentes asegurando un mejor historial.
El resto de los miembros del equipo pueden replicar los cambios usando la red local, sin que sea necesario usar el ancho de banda, ni servidores externos.
Se puede controlar que otros equipos en la misma red no accedan al código, aunque compartan conexión a internet, mediante listas de control de acceso (ACL).
Las operaciones de merge son menos constantes, al hacer integración de componentes terminados, evitando riesgos de introducir errores de regresión. Además con tecnologías como Xmerge se puede detectar código refactorizado e integrar de una manera más sencilla.
Se pueden integrar los cambios en una rama principal sin que ello afecte al desarrollo del proyecto (una persona puede dedicarse a esa tarea, aunque no es necesario que lo haga de manera exclusiva).

PlasticSCM permite todas las características comentadas anteriormente y más, aunque hay otras herramientas como Git o Mercurial disponibles en el mercado.

Cuando el desarrollo es ágil (nada más ágil que un evento de esta magnitud) tener las herramientas adecuadas puede ser la diferencia entre una aplicación buena y una espectacular.

Para la próxima hackatón, te propongo usar un DVCS, y si escoges PlasticSCM, puedes dejar críticas y sugerencias en los comentarios.

Más información: