BeOSmAn's Blooog

Generalemente, sobre todo en empresas pequeñas, la organización de los archivos de un proyecto, tanto de código fuente como de recursos (imágenes, CSS’s, Javascripts, etc.) viene siendo un caos. En la mayoría de las ocasiones está el directorio principal y todo ahí metido.

Esto de por sí ya es contraproducente a la hora del mantenimiento y extensión de cualquier proyecto con lo que la mejor manera es separar cada parte del proyecto en su directorio correspondiente, de forma que los recursos estáticos (imágenes, CSS’s y Javascripts) estén en varios directorios, los objetos de negocio en otro, las vistas en otro, etc. Incluso cada uno de estos se puede distribuir internamente para facilitar su mantenimiento posterior.

Aquí es donde se aplica esta máxima de la informática que dice: «Divide y vencerás». Divide la localización de tus archivos y vencerás al problema del mantenimiento.

Pero en esto de la organización existe otro problema: el de la gestión de líneas de desarrollo y versiones. Y, como no, existen aplicaciones que nos ayudan enormemente a realizar esta labor, como CVS o Subversion.

Este problema, el de las versiones, se nos ha dado en el trabajo, cuando después de desarrollar una pequeña arquitectura en PHP siguiendo el modelo MVC, hemos desarrollado una aplicación que usa dicha arquitectura. Pero resulta que en un momento dado, la arquitectura cambió lo suficiente (al estar en desarrollo es totalmente normal) que si se aplicaban dichos cambios a la aplicación, ésta dejaba de funcionar y los cambios que había que realizar eran demasiado grandes para adaptarla. Y es por esto por lo que se decidió hacer una versión con lo que ya había para luego seguir con el desarrollo de la rama principal por otro lado.

A priori esto no es más que un diseño lógico de la distribución de los archivos del proyecto, pero Subversion, el sistema de control de versiones que usamos, propone una distribución de directorios de lo más… lógica. Veamos:

• En cada proyecto se crean tres directorios: trunk, tags y branches.
• En el directorio trunk se encuentra la rama principal de desarrollo, es decir, la rama donde está la última versión estable y funcional de la aplicación o arquitectura.
• En tags se hacen copias de la rama principal como versiones independientes. Esto es lo que ha solucionado nuestro problema de la aplicación que usaba la arquitectura en un punto determinado. Ha bastado con hacer la versión 0.1 (tags/0.1) y usarla para la aplicación en cuestión. Esta versión ya no se puede tocar.
• En branches están versiones en desarrollo, es decir, versiones inestables cuyas características están siendo implementadas. Por ejemplo, se puede hacer un branch especial que pruebe una nueva teconolgía en branches/specialbranch. Una vez que esa tecnología ha sido probada y aprobada para la inclusión en la rama principal, se hace un merge de los distintos archivos en trunk y la rama branch se puede eliminar.
• La única diferencia entre un tag y un branch es que los tags nunca cambian. En el primer momento que cambien se convierten en branches.
• En resumen, trunk es la rama principal de desarrollo, tags son versiones estables e inmutables y branches son versiones de prueba de nuevas características.

Este tipo de organización puede parecer compleja o, incluso, innecesaria. Pero en cuanto se empiezan a gestionar varios proyectos que usen las características de otros o que se hagan releases de versiones, esta arquitectura se vuelve imprescindible. Además, Subversion cuenta con comandos que ayudan a realizar todas estas acciones como svn copy ..., svn merge ..., svn move ..., etc.

Lo malo de esto es que no se puede aplicar a nuestro cerebro .