miércoles, agosto 13, 2014

Control de versiones: ¿Para qué sirve? ¿Por qué es necesario?

Por: Fernando D. Bozzo

Muchos han oido hablar, o incluso han leido, sobre la existencia del Control de Versiones (VCS: Versioning Control System) también conocido como Control de Código Fuente (SCM: Source Code Managment) o su variante Distribuida (DVCS: Distributed Versioning Code Management), pero todavía son pocos los que se han dado cuenta de qué les aporta un SCM a su trabajo programando.

Para complicar más la experiencia, la gente que sí ha usado control de versiones, pero que ha sido mediante SourceSafe, tienden a pensar en una herramienta SCM como un "repositorio de código", debido a las limitaciones de SourceSafe que todo el que haya trabajado con él ya conoce.

Un SCM es mucho más que un repositorio de código, y tienen muchas ventajas trabajar con uno. La mayoría de los lenguajes de programación, que son basados en texto, como Java, PHP, PLSQL, Python, Javascript, C/C++ y muchos otros, vienen beneficiándose de ellos desde los 90, siendo el primero cvs, y siguiendo luego por Subversion (svn), Perforce , y evolucionando luego a DVCS (Distributed Version Control System o Sistemas Distribuidos de Control de Versiones) como Git, Mercurial, Plastic y otros.

En el caso de Visual FoxPro, un SCM tradicionalmente se podía solo usar parcialmente, más que nada para comparar versiones de un archivo, que es muy útil, pero donde los cambios de otros desarrolladores había que seguir haciéndolos a mano para integrar.

Desde fines de 2013, y con la ayuda de un proyecto Open Source hecho en Visual FoxPro, FoxBin2Prg, es posible aprovechar absolutamente todas las ventajas de un SCM o un DVCS que ya disfrutaban los demás lenguajes basados en texto:

  • Se pueden comparar los binarios usando archivos de texto estilo PRG
  • Se puede saber qué se cambió en cualquier momento del tiempo, incluso entre versiones no consecutivas (por ejemplo, hace 3 versiones atrás)
  • Se puede saber quién hizo un determinado cambio, incluso a nivel de cada línea de código
  • Se pueden obtener varias estadísticas, como, por ejemplo, cuántos cambios se hicieron desde la última versión, o qué componentes cambiaron
  • Se puede tener un equipo de desarrolladores que puede trabajar en los mismos componentes (forms, librerías de clases, menús, etc) y que pueden hacer merge (mezcla) de código concurrentemente y obtener binarios FoxPro funcionales de esas mezclas sin bloquearse entre ellos
  • Cada desarrollador tiene su copia local del sistema, donde puede hacer todas las pruebas que necesite sin tener interferencias o bloqueos por los cambios de los demás
  • Si un desarrollador comete un error, los demás no pagarán las consecuencias ni quedarán bloqueados por ello
  • Un desarrollador puede trabajar en la versión actual del sistema, mientras otro puede estar trabajando en el parche de la versión anterior con código más antiguo, y ambos no se verán afectados
  • Se puede trabajar en más de una versión a la vez (esta versión, la próxima, un parche, etc) usando ramas
  • Se tiene la opción de trabajar en un proyecto con gente que está en sitios geográficamente separados. Esto permite que tu trabajes en tu casa, yo en la mía y ambos podamos compartir el mismo repositorio, por ejemplo, GitHub o BitBucket, como repositorio intermedio
  • Se pueden sincronizar varios repositorios de código fuente para backup, para replicación o para otros usos
  • Se tiene la opción de "deshacer" un cambio, o muchos cambios, que afectan a uno o varios componentes de forma segura y volver a una versión anterior
  • Se puede ser libre de los formatos privativos y usar formatos libres que pueden ser usados por más de una herramienta SCM, lo que permite pasarse de una a otra herramienta
  • En definitiva, se tiene el completo control de todos los aspectos del desarrollo de un sistema, de sus versiones, sus cambios y evitando los bloqueos entre miembros del equipo


Si luego de leer esto, siguen con dudas sobre la utilidad que le puedan encontrar, incluso trabajando en solitario, intenten responder estas preguntas a situaciones de la vida real y comparen sus propias respuestas con las que dicen "Con SCM":



¿Llevas el control de las versiones de tu programa?

Con SCM: Siempre es así, además se etiquetan, para mantener un histórico de cambios consultable




¿Cómo lo haces ese control? ¿usando un zip o un subdirectorio por versión? ¿en serio?

Con SCM: Guardando instantáneas de los cambios en una BDD



¿Cómo comparas dos versiones de un archivo?

Con SCM: Se eligen 2 momentos del historial de un archivo y se compara, o se elige una versión y automáticamente se compara con la anterior




Cuando descubres o te reportan un bug, ¿cómo lo buscas? ¿depurando siempre?

Con SCM: Algunos errores se descubren solo mirando los cambios, porque se resaltan nada más que los cambios hechos y no hay que revisar todo el código




Si luego de una o dos horas de refactorización descubres que lo has hecho mal y que sería mejor comenzar de nuevo, ¿cómo haces? ¿restauras un backup?

Con SCM: Se elige el punto de guardado (changeset) anterior con un click




¿Tienes backup de todos los momentos en los que agregas funcionalidades?

Con SCM: Guardar una instantánea de todos los archivos cambiados son unos pocos clicks




Estás trabajando en varios requisitos del cliente a la vez, y al finalizar, o en medio de los desarrollos, te llama y te dice que uno de ellos realmente no lo necesita, o que prefiere otra cosa, ¿qué haces ahora mismo? ¿acaso llevas backup para cada requisito? No vale suicidarse :)

Con SCM: Cada requisito se puede trabajar en su propia rama, y quitar un requisito puede llegar a ser tan fácil como desintegrar una rama (unos clicks)



Estás en medio de una release (versión), y te reportan un bug importante que no puede esperar a la siguiente versión, ¿qué haces? ¿mueves todo el desarrollo a otro sitio y restauras un backup? ¿y una vez hecho el arreglo? ¿vuelves a reponer todo a su sitio y vuelves a realizar los cambios en la versión que tenías a medio hacer?

Con SCM: Se crea una rama para el parche (un click), se desarrolla el parche y se aplica a la versión anterior y a la actual, por medio de merge (mezcla de código)




Sigamos complicando: Tienes un mal día, sacas el parche y resulta que no funciona. Hay que deshacer los cambios, que además también los habías hecho en la versión actual, pero además la versión actual tiene otros cambios posteriores que no quieres deshacer. ¿Cómo deshaces el parche? ¿Tienes tantos backups como para volver atrás? Pero en ese caso perderías los cambios que te servían...

Con SCM hay varios caminos posibles: 1) Puedes hacer un merge sustractivo del parche, tanto en la versión anterior como en la actual (algunos clicks), 2) Puedes elegir comenzar a trabajar en una nueva rama de un momento de la historia anterior al parche, 3) otras alternativas.




¡Ok! ¡Suficiente! Parece que esto sirve, pero suena todo muy complicado o no entiendo todos los conceptos, además que seguramente sea muy difícil de usar y no es que me sobre el tiempo para aprender algo nuevo...

¿De verdad crees eso? ¿Y si te digo que con unas buenas prácticas en dos o tres tardes tienes los conocimientos necesarios para seguir adelante? ¿No crees que estás perdiendo más tiempo haciendo manualmente algunas de las cosas antes comentadas, cuando ya existen herramientas que te lo ponen fácil?

¿Ves todas las facilidades que estás perdiendo, y que te luego te ahorrarán mucho más tiempo que el que vayas a invertir en aprender?


Actualmente en VFP 9 hay varias opciones disponibles para trabajar con control de versiones, desde herramientas SCM/DVCS gratuitas hasta herramientas de pago. Sólo es cuestión de elegir algunas, probarlas y quedarte con la que más te guste para tu forma de trabajo.


Si te interesa seguir adelante, te invito a continuar por aquí:

FoxBin2Prg: Control de código fuente con PlasticSCM

Instalación de PlasticSCM paso a paso

Programas para control de versiones


Hasta la próxima!

No hay comentarios:

Publicar un comentario