The Geek Inside

Una de las cosas más importantes en el proceso del desarrollo de software es el control de versiones.

Esta práctica se puede llevar de varias maneras:

1. Creando archivos comprimidos de cada versión que publicamos.
2. Generando respaldos de nuestro código fuente diariamente.
3. Usando una herramienta especializada para control de versiones.

Las primeras dos alternativas aunque funcionan, dejan mucho campo para cometer un error, por lo que me concentraré en la última de las alternativas, aunque no está excenta de que se puedan cometer errores al usarla, de las tres considero que es la mejor.

A continuación describiré una simple serie de pasos que se debe de llevar a cabo para montar una estrategia de control de versiones:

Versioning

Lo primero que debemos tener en cuenta antes de comenzar a usar cualquier tipo de control de versiones, es una técnica de versioning, yo regularmente me adapto a la técnica usada en la plataforma o lenguaje en el que estoy desarrollando en ese proyecto.

Como por ejemplo el Apple Framework Versioning, sin embargo una de las estrategias que más me gusta es la de APR, pues es bastante desciptiva para saber cuando hay que cambiar de numero de versión.

Sistema de control de versiones

Ahora como segundo paso es encontrar una herramienta que se ajuste a nuestras necesidades, existen varias y de diversos tipos:

• CVS
• Subversion
• Darcs
• Monotone
• Git
• Visual Source Safe
• Visual Team Fundation Server

CVS, Subversion, VSS y VSTS necesitan mantener corriendo una máquina como servidor y cada uno de los integrantes del equipo conectarse a ella para hacer un commit o update.

VSS y VSTS son comerciales, todos los demás están regidos por alguna de las licencias open source.

Darcs, Monotone y Git son sistemas de control de versiones distribuidos, esto es cada repositorio en cada máquina es un branch de un proyecto, regularmente se usan “parches” para actualizar el repositorio de otra máquina, ya que cada quién tiene su propoo repositorio se tiene que estár conectado a un repositorio central.

Proceso de control de versiones

El tercer y último paso es trazar una proceso para actualizar, modificar y publicar tus adecuaciones al código, esto debe siempre de hacerse después de haber seleccionado la herramienta que usaremos ya que cada una tiene sus peculiaridades.

En el caso de usare una de las llamadas distribuidas, no es necesario hacer un update antes de subir nuestros cambios ya que no competimos con nadie la última versión.

Pues bien, esta es una pequeña guía para comenzar tu proceso de control de versiones, en artículos posteriores, iré refinando y dando ejemplos del uso de cada uno de los pasos descritos anteriormente.