Para un desarrollador de software es muy común hablar de versionamiento y el uso de herramientas como git o mercurial es habitual. Sin embargo, en algunas ocasiones observo que para muchos aún no está claro para lo qué realmente sirve un sistema de control de versiones.

En primera medida, cuando se habla de un sistema de control de versiones se hace referencia al control de cambios que se realiza sobre un proyecto, en su mayoría de construcción de software. En pocas palabras, el sistema de control de versiones es la memoria de cómo el proyecto fué o está siendo construído. Por otro lado, también constituye una herramienta efectiva para el trabajo colaborativo (ejemplos como http://github.com o http://bitbucket.org son una muestra conocida). Sin embargo, en el trabajo diario me he encontrado con usos que no corresponden con el objetivo de la herramienta y por ello a continuación listo aquellas prácticas, que bajo mi punto de vista, no deben seguirse realizando cuando usamos un sistema de control de versiones.

Primero que todo, un sistema de control de versiones no es un repositorio de archivos; para ello existe otras herramientas como servidores ftp o servicios como amazon S3, dropbox, etc. Me he encontrado con que muchos desarrolladores usan el repositorio para incluir archivos como imágenes, documentos pdf, copias de seguridad de bases de datos, que no aportan en la construcción de memoria del proyecto y por otro lado si aumentan de forma significativa el tamaño del repositorio (haciendo que sea más demorado clonarlo, por ejemplo). Aunque muchas herramientas para control de versiones soportan la inclusión de archivos no es recomendable abusar de dicha característica para incluir todo tipo de recursos. Es cierto y sobre todo cuando se trabaja con desarrollo de aplicaciones web, que hay que incluir cierta cantidad de imágenes susceptibles de versionamiento (fondos, ilustraciones, etc) pero en la medida que sea importante mantener un histórico de las mismas. Por lo regular la mayoría de frameworks web permiten definir las ubicaciones para el tratamiento de archivos estáticos (assets) caracterísitica que facilita ignorar archivos.

Otra de las prácticas poco recomendadas es el versionamiento de archivos que contengan información de caracter confidencial: claves de acceso, nombres de usuario, llaves para consumir APIs de terceros, etc. Este tipo de información no debería estar versionada, dado que no hace parte de la memoria del proyecto y debe manejarse con parte de la configuración de los entornos de despliegue (desarrollo, pruebas, producción, etc). Adicionalmente, al incluir este tipo de información en un sistema de control de versiones, se está proporcionando información de acceso a entornos controlados que constituye una potencial vulnerabilidad, y no quiero parecer paranóico.

Por último, observo con gran frecuencia que los mensajes actualizaciones de código son poco descriptivos conforme a los cambios que introducen; cosas como: cambios menores, corrección, fix, etc; son mensajes que no aportan en la construcción y guía de la memoria del proyecto. Con solo un minuto de más esfuerzo, seguro se pueden construir mensajes concretos y efectivos.

Y recuerde: cuando desarrolle software, escriba código como si otro lo fuera a leer y entender.



Comments

comments powered by Disqus