Que le pido a un control de versiones: Backups

Una de las funcionalidades que creo que están bien en un control de versiones, aunque no es que sea primordial, es el facilitar el tener una copia del código en el servidor, de tal forma que si se estropea el disco duro de tu ordenador no pierdas todo el trabajo que has realizado.

Muchas veces se utilizan los comits en el servidor a modo de backups, pero esto no debiera de ser así, un comit debiera de representar un trabajo terminado. El disponer de una copia de seguridad hace que sea más fácil el mantener los comits como lo que son.

Aquí la única herramienta de las que conozco que realiza de forma nativa esto es Rational Team Concert. El resto no tiene ese soporte.

Bien es cierto que se podría realizar el backup dentro de la política de copias de seguridad de todo el equipo, no solo del código. Pero esas políticas suelen ser un poco precarias.

Que le pido a un control de versiones: Trazabilidad

Trazabilidad. Creo que es la madre de todas las características de un control de versiones.

Es la capacidad de poder identificar que código corresponde con cada petición que te han realizado, normalmente en algún sistema de ticketing, como Bugzilla, Mantis, etc.

Cuando tienes que realizar un traspaso el poder saber que tareas tienes que traspasar y tenerlas perfectamente reflejadas en la herramienta ayuda mucho.

Aquí nuevamente el que mejor lo hace es Rational Team Concert. No hay que hacer ningún esfuerzo para tenerlo, viene de serie, además con una característica añadida y es la posibilidad de forzar administrativamente que todos los «commits» lleven obligatoriamente asociado una tarea dentro del ticketing.

Otro que lo hace relativamente bien también es el Git, ya que dispone de muchas facilidades para realizar ramas y mergeos.

El resto de los que conozco (VSS, CVS y SVN) no destacan tanto en esta funcionalidad

Que le pido a un control de versiones: Flujos

Hoy vamos con una característica que me gusta tener en los controles de versiones y que hace muy bien el Rational Team Concert y es la definición de flujos.

Es decir poder tener definido que, por ejemplo, de una rama de trabajo se pasa a una rama de integración y de esta a una rama de Preproducción, etc.

Esto te permite tener definido y reflejado tu flujo en la propia herramienta, sin tener que andar definiendolo en una normativa en papel que se puede ir saltando a discreción.

En Rational Team Concert de hecho existe el concepto de flujo en el que puedes definir de un Stream (para entendernos una rama) a donde puedes liberar el código.

Otra herramienta que lo hace bastante bien es Git, sobre todo por la posibilidad de tener diferentes repositorios remotos y la posibilidad que te proporciona el gitFlow. Este añadido a Git te define un flujo típico dentro de la propia herramienta. Bueno siempre y cuando utilices SourceTree.

El resto de herramientas de control de versiones con las que he trabajo como Visual Source Safe, CVS y Subversion no disponen de estas funcionalidades de forma nativa, así que los flujos los tienes que hacer tu a mano. Lo cual es más tedioso y propenso a errores.

Que le pido a un control de versiones: favorecer comits atómicos

Todos hacemos comits constantemente en nuestros sistemas de control de versiones. Una de las características que valoro en estas herramientas es la facilidad que den para hacer comits atómicos.

En decir, cuando tienes un cambio que afecta a muchos ficheros, muchas veces se cae en la tentación de ir revisando cada fichero para ir seleccionando cual hay que comitear y cual no, pero comiteando cada fichero revisado, en vez de todos juntos.

Aunque obviamente tienes todos los cambios en el control de versiones, no tienes todos agrupados, porque has ido haciendo varios commits, según revisabas.

Esto hace que si quieres llevarte el cambio a otro sitio o sacarlo de una versión sea más difícil con varios commits que con uno único.

De los controles de versiones con los que he trabajado, solo hay dos que facilitan estos commits atómicos, y son el Git y el Rational Team Concert.

Ni el Visual Source Safe, ni el CVS, ni el Subversión lo hacen.

Que le pido a un control de versiones: suspender trabajos a medias

Inicio con esta entrada una serie de sobre que requisitos creo que debe cumplir un sistema de control de versiones. La intención es hacer entradas cortas reflejando las características que me gustaría tener.

La primera característica es la de poder suspender trabajos. Es decir, mientras estas realizando una tarea poder guardar el estado de tu entorno de trabajo para atender otra tarea más prioritaria, por ejemplo, un error en producción, y una vez solucionado esa tarea prioritaria, poder continuar con la tarea que originalmente estabas realizando.

De los controles de versiones con lo que he trabajado los únicos que lo implementan de forma nativa son el Git y el Rational Team Concert.

El resto de herramientas con las que he trabajado (Visual Source Safe, CVS y Subversion) no lo soportan de forma nativa, así que hay que recurrir a métodos más manuales como comitear los cambios a medias o bien a guardárselo en otra carpeta. Ambas soluciones muy poco elegantes.

Que mal venden el Git

Estoy empezando a usar el repositorio de código Git, como ya comenté en unas entrada de mi proyecto MyCloudChest. Cada día me gusta más, pero tengo que reconocer que me parece que se venden muy mal y me ha costado verle las mejoras que aporta.

Me explico. Si miras por Internet lo primero que te destacan es que es un repositorio de código distribuido, que te permite trabajar, por ejemplo, mientras vas de viaje en un avión y no tienes conexión. 

Me imagino que la gente que escribe eso viajará mucho en avión, pero cuando te lo planteas para tu empresa, pues no se en estados unidos, pero en los sitios en los que yo he trabajado, los programadores están en la oficina en su mesa trabajando con un ordenador de sobremesa, así que de primeras no le ves mayor utilidad y lo descartas.

Por circunstancias, que ya explique, si que me ha sido útil el usar un repositorio de código distribuido, para avanzar en el pueblo en este proyecto personal, porque allí (o más bien aquí que ahora mismo estoy escribiendo esto desde el pueblo) no dispongo de ADSL, solo móvil.

Los viajes en avión no, pero en cambio si hay situaciones que se me han planteado en varias empresas y con varios clientes en las que un repositorio como Git puede ser útil. Muchas empresas te obligan a dejar el código en sus repositorios, normalmente Subversion. Pero claro, no siempre tienes una buena conectividad con esos sitios, ya que suelen darte acceso mediante VPN. Esto te obliga a tener tu repositorio Subversion en tu empresa, para poder trabajar con eficiencia y luego hacer un corta y pega al repositorio del cliente y subirlo mediante la VPN.

Como el Git permite trabajar con varios repositorios «servidores» si puede ser más adecuado que un Subversion.

Esto si me parece una situación más cercana, no como el trabajar desde el avión.

Otra de las cosas que no veo bien explicadas es el uso de la zona de staged, cuando lo ves lo primero que piensas es, vaya rollo, tengo que añadirlo a la zona de staged, luego comitearlo y luego empujarlo. Si en subversion hago un commit y ya está, se me van a liar los programadores y siempre procuro gestionar la capacidad de la gente.

Me dio la pista un vídeo de aprendegit.com

Lo que si que he visto en muchos casos, y he de reconocer que yo también he hecho, es el comitear cambios de una única incidencia en varias veces, porque tienes muchos ficheros modificados y vas revisando uno a uno a ver si es un cambio que tienes que subir o no.

En esta situación si que es claramente interesante el disponer de la zona de staged. Voy revisando los ficheros y decidiendo cual debo subir y cual no, y una vez que los tengo todos revisados los comiteo en bloque.

A esta situación de ejemplos poco realistas, a mi parecer, no ayuda mucho tampoco los clientes gráficos de Git, con Eclipse y su pluggin no he sido capaz de actualizarme unos cambios que tenia en el servidor, me daba un error de que no tenia un branch configurado. Menos mal que ha salido hace no mucho el programa SourceTree que es mucho más intuitivo y con ese funciono mucho mejor.

En resumen, un repositorio de código que tiene muy buena pinta, pero con una entrada bastante dura.