Cuando se desarrolla software, y en especial cuando se hace en equipo, es fundamental contar con un mecanismo que permita gestionar el código que producimos.

La gestión de los cambios que se producen sobre el software se convierte en algo indispensable cuando varios programadores trabajan sobre el mismo código. El utilizar una herramienta de este tipo facilita la labor de integrar el código de los diferentes participantes y sobre todo, permite llevar un control de los cambios que se han realizado sobre cada uno de los componentes software.

Los sistemas de control de versiones y configuraciones no solo se aplican al desarrollo de software, sino también a otros campos, como por ejemplo, documentos, imágenes o páginas web. En 21projects trabajamos con varios lenguajes de programación y todos ellos conviven en nuestro sistema de control de versiones. Incluso cuando desarrollamos para iPhone o Android, donde suele intervenir un único programador, también mantenemos todo el código en nuestro repositorio central, evitando así que pueda perderse el software debido a algún fallo en disco de nuestros PCs o algún otro inconveniente.

En este caso, vamos a hacer una introducción a la herramienta de gestión de versiones que utilizamos en 21projects. Subversion es una herramienta open source diseñada exclusivamente para sustituir a su antecesor, CVS, que presentaba algunos inconvenientes muy importantes a la hora de gestionar el software (por ejemplo, no es posible renombrar un fichero o eliminar un directorio que tenga archivos dentro). Subversion ha sido diseñado según una arquitectura cliente-servidor, en donde cada programador edita el código localmente y lo “sube” a un repositorio central, el servidor Subversion.

Para conocer ventajas e inconvenientes adicionales de Subversion os dejo al final los enlaces a la Wikipedia y a su Web oficial. Existen otras alternativas a Subversion, como Git, de las que hablaremos en otro post. Lo realmente importante que quería transmitir en este artículo era el uso de Subversion (aka SVN) y algunas recomendaciones personales para evitar problemas.

Una de las grandes incógnitas que pueden surgir a la hora de decantarse por Subversion es si instalarlo en nuestros propios servidores o bien subcontratar el servicio a una empresa que se dedique a ello. En el caso de 21projects hemos decidido subcontratarlo y por ello no os vamos a explicar como instalarlo (aunque es muy sencillo). Los motivos para haber tomado esta decisión son los siguientes:

• Necesidad de centrarnos en nuestro business core y no dedicar tiempo a mantener las herramientas, que como Subversion, deben facilitar nuestra labor y no suponer un problema añadido.
• Bajo coste del servicio subcontratado.
• Los datos guardados en el repositorio son de gran importancia para nuestro negocio, es por ello que preferimos confiar en una empresa externa que se encargue de mantener backups periódicos de la información y que pueda ofrecernos garantías.
• Integración con otras herramientas cuyo mantenimiento e instalación no es trivial. Por ejemplo, Trac (hablaremos de esta herramienta en otro post).

Es por estos motivos que en 21projects hemos decidido confiar en otra empresa y delegar la responsabilidad de su mantenimiento. En nuestro caso trabajamos con RepositoyHosting, una empresa que ofrece un plan de precios muy sencillo y económico, con unas características más que de sobra y un plan de administración que aunque sencillo es muy cómodo. Adicionalmente, RepositoryHosting también ofrece Trac integrado lo cual era una condición indispensable a la hora de elegir la empresa.

Una vez que contratado el servicio, es necesario crear un repositorio para nuestros proyectos. Un repositorio puede comprenderse como un directorio con sus respectivos subdirectorios y ficheros. En dicho repositorio se almacenará el software y podemos elegir tener un único repositorio para todos nuestros proyectos o bien crear uno nuevo por cada proyecto.

Antes de comenzar con el uso de Subversion, quiero comentar que para organizar los proyectos se suele asumir un convenio. Se trata de crear por cada proyecto tres directorios bajo los cuales se guardará nuestro software. La explicación de cada uno de los directorios es la siguiente:

• Trunk: Directorio de un repositorio bajo el cual se encuentran los directorios y ficheros de nuestro proyecto.
• Tag: Directorio bajo el cual se almacenan las diferentes versiones o releases de nuestro software.
• Branches: Directorio donde se almacenan ramas de nuestro proyecto. Una rama es una desviación que se toma a partir de una versión del software para desarrollar alguna funcionalidad en paralelo con el desarrollo principal para su posterior integración. Hay empresas que trabajan realizando ramas nuevas por cada funcionalidad que se desea añadir y las hay que procuran no hacer ramas nuevas para evitar los posibles problemas de integración en un futuro. Nosotros preferimos una alternativa intermedia, procurando abrir una nueva rama cuando no es seguro que la funcionalidad a implementar se vaya a integrar con la versión principal (por ejemplo, para pruebas de concepto).

Por otro lado, queda comentar los principales comandos para trabajar con Subversion:

• Import: Comando utilizado para subir al repositorio la estructura inicial de nuestro proyecto.
• Checkout: Comando para descargar en un PC un proyecto desde un repositorio.
• Add: Comando utilizado para añadir un fichero a nuestro proyecto. No es subido al repositorio hasta que se indique con el comando “commit”. El comando add solo deja “marcado” ese fichero o directorio como parte del repositorio.
• Delete: Comando que permita marcar un fichero o directorio para ser eliminado del respositorio.
• Commit: Comando que nos permite subir al repositorio todos los cambios hechos sobre un proyecto en local.
• Update: Comando que nos permite actualizar nuestro proyecto en local desde el repositorio central.

Aunque existen clientes gráficos para la comunicación con un repositorio Subversion, voy a poner un ejemplo de cómo se interactúa con un servidor Subversion desde consola.

Primero creamos la estructura de directorios de nuestro proyecto en local:

mkdir miProyecto
cd miProyecto
mkdir trunk branches tags

A continuación, subimos la estructura inicial al repositorio en el servidor central:

svn import miProyecto http://urlDelRepositorio/ -m "Initial import"

Ahora podemos borrar el directorio que habíamos creado inicialmente en local:

cd ..
rm -r miProyecto/

Finalmente, obtenemos una copia de trabajo del repositorio central:

svn checkout http://urlDelRepositorio/miProyecto/trunk miProyecto

A partir de este momento, comenzaríamos a programar y guardar los ficheros y directorios creados bajo el directorio miProyecto. Cada nuevo fichero o directorio creado deberemos marcarlo como parte del repositorio de la siguiente manera:

svn add file_or_dir_name

Una vez hemos terminado de hacer cambios, deberemos reflejarlos en el repositorio central en el servidor Subversion:

svn commit -m "Guardando los cambios recientes, agregada la funcionalidad X" http://urlDelRepositorio/miProyecto

Si otros programadores van a realizar cambios sobre el código, cuando queramos volver a trabajar en el proyecto deberemos obtener todos los cambios realizados sobre este a través del siguiente comando:

svn update

Para finalizar con este artículo, quiero destacar las dos reglas de oro a seguir para evitar problemas propios y evitárselos a los demás. Todos deberíamos tener estas reglas impresas en letra grande al lado de nuestra pantalla hasta haberlos interiorizado:

• Nunca harás un commit de código que no compile o tenga errores: Si lo haces, cuando otro programador haga un update su código también tendrá esos errores y por tanto no compilará.
• Siempre harás un update antes de empezar a trabajar sobre el código. De esta manera, te aseguras de estar trabajando siempre sobre la última versión del código.

Enlaces:
CVS – Wikipedia
SVN – Web oficial
SVN – Wikipedia