Etiqueta: control versiones

Escribía en una entrada previa sobre si usar git a palo seco o edulcorado. He tenido algunas experiencias ya, aparte de con el git que instalé en mi RaspBerry (a palo seco), con GitHub, GitLab y BitBucket (git edulcorados).

Definitivamente me quedo con el git edulcorado. Estos tres productos son un Git, pero con el añadido de que unas serie de funcionalidades que me parecen bastante interesante.

– Disponen de una interface Web que simplifica enormemente el uso y la administración.
– Disponen de una pequeña Wiki, también soportada sobre Git, lo que permite tener publicada cierta documentación sin tener que andar instalando y administrando otro servicio.
– Disponen de una pequeña gestión de tickets, que al igual que en el caso de la Wiki, dispone de una funcionalidad básica, pero suficiente para proyectos pequeños.

Me parece especialmente interesante la funcionalidad de pull request o merge request, que permite a un desarrollador pedir a su responsable que le haga el merge de su branch de trabajo en el branch común.
Además hay variedad de implementaciones ( GitHub, GitLab, BitBucket,…) con lo que es relativamente fácil encontrar una que se ajuste a las necesidades.

Esta no es una entrada de la línea de que le pido a un repositorio de código, porque no siempre es un requisito el disponer de un repositorio de código distribuido.

Pero si que es cierto que alguna vez he estado en discusiones con los clientes en las que ha salido el tema de que repositorio utilizar, si el del cliente o el del proveedor. Es una decisión un poco estéril ya que el cliente puede imponerte entregar el producto que ha comprado en su repositorio, y tampoco tiene normalmente potestad para prohibirte el utilizar tu propio repositorio.

El problema suele venir por el hecho de que muchas veces la conexión con tu cliente se hace por medios no transparentes, es decir mediante VPN o similares, que hacen que el trabajar contra la infraestructura del cliente sea algo engorroso.

Aparte hay que tener en cuenta que aunque la propiedad intelectual del producto construido sea del cliente normalmente las empresas suelen querer tener una copia del trabajo realizado, simplemente para en caso de reclamación poder demostrar si ha habido o no modificaciones ajenas al desarrollo realizado.

En estos casos el utilizar un repositorio distribuido como es el caso del Git aporta bastantes ventajas, ya que permite diluir esa discusión de si utilizar el repositorio del cliente o el del proveedor. Puedes utilizar el de tu empresa y luego empujar los cambios al del cliente.

Cuando tienes que administrar un repositorio de código una de las características más importantes es el disponer de herramientas que faciliten esa administración.

Es bastante más cómodo el disponer de herramientas con interface gráfico que el tener que recurrir a «conjuros» en una línea de comandos.

Hoy día casi todos los repositorios de código tienen algún tipo de interface administrativa de tipo gráfico.

En este aspecto destaca bastante el Git, ya que aunque de por si no dispone de administración gráfica, existen multitud de herramientas que lo complementen y hacen de el una muy interesante opción.

También es cierto que si tienes que administrar muchos repositorios el disponer de una línea de comando que te permita generar scripts, es un requisito a tener muy en cuenta. Pero para cargas relativamente bajas no lo es tanto.

Es una de las cosas más molestas cuando tienes que pasar el código a otra persona fuera del repositorio es el tener que andar limpiando la cantidad de ficheritos o carpetas que incluye el repositorio para su gestión.

Así que una de las cosas que le pido a un sistema de control de versiones es que estos ficheros internos no estén dispersos por todas las carpetas.

En este aspecto, tanto el git como el Rational Team Concert son los mejores, ya que solo utilizan una carpeta en el raíz del proyecto.

Hasta ahora todos los requisitos que le pedía a un control de versiones eran de índole técnico. Pero hay una, quizá la más importante y subjetiva: la sencillez (de la que ya he hablado otras veces)

Por muchas características técnicas que pueda tener un control de versiones si los compañeros no lo entienden y lo usan mal, no vale para gran cosa.

Siempre cuento la misma anécdota. Hace ya tiempo jugué a un juego de carreras de coches, alguna versión del need for speed, no recuerdo cual. La cuestión es que de todos los coches que había para correr, siempre hacia los mejores tiempo con el que sobre el papel era el peor, simplemente porque era el más sencillo de conducir e iba más tiempo por el asfalto que por fuera, como me pasaba con el resto de coches.

El problema a la hora de valorar la sencillez es que es lo más subjetivo de todo. Si estás acostumbrado a CVS/SVN el paso a Git es relativamente asumible, pero por ejemplo el paso al Rational Team Concert puede ser más complejo, ya que no tiene como tal ramas, por ejemplo.

En ese aspecto si se quiere migrar de control de versiones o implantarlo por primera vez se debe valorar si las funcionalidades que te aporta el control de versiones compensa la dificultad de uso.

Así que en este apartado no voy a dar ningún ranking de cuales creo que sean mejores o peores, porque depende de la experiencia de las personas que lo van a usar.

No siempre que necesitamos acceder a un fichero que se almacena en una herramienta de control de versiones tenemos un cliente en el dispositivo desde el que queremos hacer la consulta, o simplemente, no queremos obtener todo el contenido para solo hacer una comprobación puntual.

El poder disponer de un acceso mediante el navegador web puede suplir esta necesidad de consulta puntual.

En este aspecto casi todas las herramientas modernas disponen de esta posibilidad, de una forma más o menos fácil. Así que no hay un claro ganador en este apartado.

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.

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

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.