Que las ramas te dejen ver el bosque

1:14 2 Comments

Ya, ya, ya sé que el dicho no es así... pero es que en el mundo de desarrollo de software se está imponiendo justo lo contrario.

Habéis visto las release notes de Bamboo 4.0? Pues efectivamente: es todo sobre branching y merging.

Me gusta mucho leer esto porque cuando arrancamos Plastic hace ya unos cuantos años, nuestro objetivo era precísamente ese: ramas por todos lados.

Hace mucho tiempo escribí sobre cómo hacer "branch per task" con CruiseControl (Bamboo no estaba tan de moda... ¿existía?) y hace poco Luis preparó el plugin de Bamboo (versión 3!) para monitorizar ramas independientes, así que, como decía, leer sobre Bamboo soportando ramas "por defecto", me ha encantado!

Ramas malditas

"Branches are evil" era el lema de Subversion y también de Perforce hace unos pocos años... "No crees ramas, son malas, malditas, dan miedo y te llevarán al infierno" (o algo peor) era lo que los profetas del "mainline" predicaban todos los días. Trabaja en "mainline" (línea principal, vamos, que una sóla rama y hagas checkin), decían.

Como casi siempre que alguien dice "no hagas esto" es por una razón bastante patética: Subversion es horrible manejando ramas (Perforce también es horrible manejando ramas: crea una rama en un repo de 100mil ficheros... media horita de nada... es por eso que las empresas de video-juegos están saltando del barco como si fuera el Titanic).

(Aquí entra el punto en el que los que usáis SVN os cabreáis y decís "sí, si que se puede, eso no es verdad". Entonces tengo que explicar un rollo del tipo: "vale, te sirve para escenarios 'hola mundo' con 3 ramitas de juguete. Prueba con 1000 ramas, o 5000, y con un montón de ficheros, y prueba a hacer refactor de verdad, renombrando un fichero y modificándolo en una rama, cambiándolo en otro... y haz merge... Se rompe, ¿verdad? Pues eso, de juguete". Si te pones pesado con el tema de SVN invocaré al sumo pontíce: "tío, Torvalds hizo Git justo porque el merge de SVN era una porquería...". Normalmente eso funciona.)

Así que... sí, afrontémoslo: los predicadores de Subversion engañaron a una generación entera de programadores en todo el mundo (2000-2008) mutilando su forma de pensar, haciéndoles creer en la religión única de "las ramas son malignas".

Es momento de abrir los ojos.

Parche tras parche

Como eso de manejar ramas era una castaña y las versiones se rompían todos los días, hubo que poner un poco de pegamento alrededor.

Y así nació la integración continua, que como idea está genial, pero que la ausencia de ramas es un pegote: haz checkin continuamente y pasa tu test-suite mágica y si rompes el build, enciende un semáforo (o que te electrocute tu ratón) y lo arreglas en un plis-plas antes de que tus colegas te cuelguen de la pizarra de tareas del scrum.

A ver... es mejor que no hacer tests, seguro, y como muchos vivíamos en la inmundicia sin esto... pues era un avance.

Lo malo es que se convirtió en religión: "no, no necesito ramas porque hago CI".

Y bueno... duró un poco la cosa.

El tema es: haces checkin, petas un test, el sitema de CI te avisa pero... ¡¡tienes a todos tus compañeros echando humo porque has petado el build!!

Es reactivo. Lo rompes, lo arreglas.

No está mal en ausencia de algo mejor, pero supone que:

  • Te da miedo hacer checkin por si rompes el build
  • Haces checkin mucho menos frecuentemente que cuando aprendes CI siguiendo el ejemplo del "hola mundo", del "juego de póker" o de cualquier otro invento de esos que funcionan siempre
  • No usas el control de versiones más que para... entregar código... que bueno, ha sido lo que la generación subversion ha aceptado como bueno... a falta de algo mejor

    Regreso al futuro

    Hace unos años en la casi-biblia de continuous integration, el señor Duvall (no confundir con el actor) veía un futuro pre-claro en el que para evitar el problema de los broken builds en CI usando un "two phase commit".

    Independientemente de que lo que diga tenga o no sentido, usó una receta mágica: nadie en su sano juicio le lleva la contraria a alguien que dice "commit de dos fases", no vaya a ser que encima le toque explicar el algoritmo!! Así que, cuando alguien usa "two phase commit", seguro que no es en vano... creámosle! :P

    Bien, el mecanismo del futuro perfecto consiste en:

  • Evita romper los builds
  • Creando un "almacenamiento temporal" en el que tus cambios viajan hasta el CI server, se compilan, se prueban y, si todo va bien, se completa el checkin

    Hablé del tema hace tiempo y la sigo pensando lo mismo: puede usted hacerlo más complicado todavía introduciendo una paloma mensajera para enviarte los resultados de build de vuelta...

    ¡¡Vaya montaje por no usar ramas!!

    El invento, y de ahí lo de "regreso al futuro" llevaba años inventado: usa ramas para tus tareas y déjate de cuentos!

    Ya estaba inventado

    Si hoy dices "ClearCase" tu índice de "cool" cae en picado... así que no lo digas.

    Pero ClearCase era un sistema de control de versiones que ya hacía ramas y merges buenísimos en el año 95, 5 años antes del "Subversion doom's day".

    Casi todo lo que sepas sobre control de versiones ya lo hacía ClearCase (CC para los amigos) hace 15 años. Es como el "xerox park" de los controles de versiones, parece que no se inventó nada después...

    El tema es que ClearCase era caro. Caro de narices. Caro como cuando se pagaba por el software una fortuna. Una licencia de CC costaba entre 3 y 4mil Euros por usuario. 5mil si era de multi-site (capacidad distributed, con réplica y todo, pero en plan pantalones campana).

    Hacer algo mejor que ClearCase pero rápido y barato fue nuestra primera motivación para desarrollar Plastic...

    Al tema: CC ya podía crear todas las ramas que quisieras, y mezclarlas bien. Lo que pasa es que CC tenía algunos problemillas:

  • Tiraba una barbaridad de la red (vistas dinámicas y otras maravillas), así que en una LAN bien configurada (difícil de configurar) iba bien... pero muy pocos sysadmins de verdad eran capaces
  • Cuando la red no iba bien... era leeeeeento
  • Instalarlo era un dolor. En 8 horitas, con experiencia, montas uno sin problema. Sí, 8 horas... (para que luego digan que instalar plastic, en 40 segundos, es lento :P)
  • Cambió de manos: lo compró primero Rational, le pusieron una capa "metodológica" por encima, para hacerlo más sencillo, y se lo cargaron. Nació UCM, con streams, sobre 2000. Un sistema con todas las desventajas de ClearCase y Subversion juntas... Lo mataron.
  • He dicho que era caro?

    Así que el "xerox park" del control de versiones cabó su propia tumba...

    No obstante, hasta hace bien poco, incluso en el máximo esplendor de Subversion, para que os hagáis una idea de lo que es la pasta..., CC facturaba el 50% del negocio del control de versiones, frente a un 0,7% de SVN... mucho ruido y pocas nueces, que se dice.

    El segundo advenimiento de Torvalds

    Y entonces en 2005 todo cambió.

    Los "falsos profetas" de SVN tuvieron que ver como regresaba el mesías del open source para dividir las aguas y cargarse a SVN rápidamente: una charla de Torvalds anunciando, en google, eso sí, que había creado, en 3 días (muy trascendente) un nuevo control de versiones que:

  • Manejaba bien las ramas
  • Hacía bien los merges
  • Era distribuido

    Y mató a SVN en 3 años.

    Todos, sí, todos, los proyectos open source importantes del mundo dejaron SVN y pasaron a Git (o Mercurial, el hermano siniestro de Git) antes de que terminase 2008.

    No está mal para Mr. Torvalds, el tío que más pasta ha hecho ganar a otros con su software y que menos se ha quedado... todo un mesías.

    Vete por las ramas!

    Git es distribuido, que mola, porque puedes tener tu repo en tu máquina y hacer push y pull con el central, pero trabajar totalmente desconectado.

    Pero, el principal tema no es que sea "dvcs" (que sí, que mola!) es que maneja muy, muy bien las ramas.

    Crea ramas para lo que quieras, para cada tarea (sí, por cada entrada en tu issue tracker favorito, una rama), y trabaja en ellas, y luego haz merge, sin problema.

    De eso va el cambio. De usar ramas.

    Así que los "profetas de svn" se quedaron compuestos y sin novia.

    SourceForge se fue a pique frente a GitHub (el sitio por antonomasia que logra que un sistema distribuido sea, uhm... centralizado!), la gente de Perforce ya no tiene narices para decir "branches are evil" y dice todo lo contrario (con el mismo producto, eso sí, que lo hace igual de mal que antes), "distributed" y dvcs son las palabras de moda (hasta SVN intentó convencer de que era dvcs... por tener un puerto abierto... argh!), y el control de versiones ya no es "una herramienta coñazo" sino lo que hace que tu proyecto sea "cutting edge". Tela!

    Dónde estábamos nosotros?

    A nosotros, con Plastic, no nos suena raro. En 2005 queríamos hacer algo tan potente como ClearCase pero rápido, fácil, simple de instalar y asequible. Pronto vimos como Git nacía y nos pisó nuestro sueño de versionar el Kernel de Linux, aunque era un sueño loco dadas las guerras religiosas que se montaron alrededor del control de versiones (nota: años después, en la otra punta del mundo, plastic 4 versiona repositorios comerciales que incluyen todo el código de linux, android, chromium, el quake y hasta el grep y el tar... 300 mil ficheros... no está mal!).

    El caso es que la base era la "rama por tarea": hacer ramas bien, rápidas, muy rápidas, poder tener muchísimas, y poder hacer bien los merges también. Y además hacerlo fácil.

    Así que en 2006, cuando lanzamos Plastic 1.0, la gente nos miraba raro en las demos cuando les decíamos lo de "sí, sí, crea ramas".

    Ahora, años después, y gracias a Git, Mercurial y el cambio total de tendencia, lo que nos piden es precísamente eso: ramas, ramas, ramas.

    Nuestro objetivo era diferente al de Git (vale, y no podemos decir lo que nos de la gana en una charla, como Torvalds, y quedarnos tan anchos... porque no hemos creado un sistema operativo) porque al final siempre hemos estado centrados en crear un sistema no para proyectos open sino para empresas: de cualquier tamaño, pero empresas.

    Se hace "mainstream"

    Así que ahora la gente de los "continuous integration systems", como Atlassian y su Bamboo, por fin ha pillado el rollo y adapta su sistema a "branching". El paso natural. La puntilla final, espero, para los que viven anclados en el pasado "sin ramas", y un paso adelante enorme que evangelizará a muchísimos usuarios.

    Espero que por fin el legado "evil" de SVN se diluya...

  • 2 comentarios:

    Brillante resumen sobre la evolución de los controles de versiones alrededor del branching y el consecuente merging.

    Debería ser lectura obligada para mucho gestor informático demasiado atolondrado con MBAs y cancamuseos varios. Mejor nos iría.

    Raul Garcia dijo...

    http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn