Así han aparecido multitud de metodologías de desarrollo ágil como pueden ser Extreme Programming o Scrum. Parte de la filosofía de estas metodologías consiste en reducir al mínimo el proceso de documentación y evitar mantener largas reuniones para tomar las decisiones necesarias.

Sin embargo, que el desarrollo se haga de manera ágil no significa que se deba obviar el proceso de captura de requisitos, testeo y documentación. Por el contrario, consiste en utilizar otro tipo de técnicas que permita realizar estos procesos de manera sencilla y productiva.

En 21projects y en muchas otras empresas de desarrollo se utiliza una herramienta de gran valor y potencial. Se trata de Trac. En la web de este proyecto open source se define a la herramienta de la siguiente manera:

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management.

Resumiendo, Trac es una herramienta que permite llevar un control de las funcionalidades y errores del código que se está implementando. Sin embargo, Trac es una herraminta mucho más completa que esto, pues está construido sobre una wiki que permite documentar todo el software sobre una única plataforma, integrando la documentación con el control de funcionalidades y errores a implementar así como también con el propio código a través de un repositorio de Subversion del cual ya se habló en un post anterior.

Conozco mucha gente que después de haber probado Trac en su equipo de desarrolladores han dicho frases como: “No se como puedo haber vivido hasta ahora sin una herramienta como Trac”. Y la verdad es que, aunque no se trata de una herramienta imprescindible, sí que resulta extremadamente útil. Además de las opciones básicas de Trac, también es posible instalar nuevos plugins que cubren desde la integración de repositorios Git hasta la gestión de metodologías ágiles como Scrum.

¿Pero qué significa todo esto a la hora de la práctica? Lo mejor es verlo con un ejemplo. Veamos como sería el proceso de creación de un nuevo proyecto en el equipo de 21projects (Trac puede utilizarse para cualquier tipo de lenguaje, ya sea una aplicación web, desarrollo para iPhone o Android o bien para gestionar documentación, imágenes o cualquier otro tipo de contenido).

Captura de requisitos:

En esta fase, nos reunimos todo el equipo de desarrolladores (y el cliente, si se trata de un proyecto para terceros) bien en persona o utilizando un documento compartido en GoogleDocs para definir cuáles son los requisitos de la aplicación. Normalmente, primero desarrollamos los casos de uso básicos de la aplicación y a partir de ellos creamos la lista de requisitos, siempre en colaboración directa con el cliente.

De esta fase saldrá una lista de requisitos funcionales con una descripción de cada uno, dejando claro qué es lo que se espera y que ha de tener para que se considere que ese requisito está “hecho”.

Integración de los requisitos en Trac:

A partir de este momento, procederíamos a ingresar en Trac cada uno de los requisitos como un nuevo Ticket. En Trac, cada funcionalidad a implementar o cada bug debe ser introducido como un Ticket, que estará asociado a una persona y a un Milestone del proyecto así como a una serie de propiedades adicionales como pueden ser la versión del desarrollo, el tipo de Ticket, o la severidad de este. Un Milestone es un hito de desarrollo que se propone. Dentro de Trac podemos crear tantos Milestones como queramos y ponerles una fecha límite. Así, se podría decidir crear un nuevo Milestone que representa el lanzamiento de la primera versión del producto y todos los Tickets de esta iteración serán agregados a este Milestone.

Interfaz de creación de Tickets

Trás haber ingresado todos los Tickets en el sistema, cada desarrollador participante podrá decidir en qué funcionalidad va a trabajar y asignarse ese Ticket, que quedará marcado con su nombre para que los demás sepan que él está trabajando en su implementación.

Mientras el desarrollo esté en curso, podremos utilizar la Wiki de Trac para ir documentando todo el proceso. Aunque esta Wiki tiene una sintaxis particular que viene reflejada en la documentación de la aplicación, sus posibilidades son muy amplias e interesantes, ya que por ejemplo, cada vez que pongamos el caracter “#” seguido de un número se creará un enlace automáticamente al Ticket que tenga asignado ese número (cada Ticket tiene un identificador numérico único).

En nuestro caso, utilizamos la página principal de nuestro Trac (que es una página wiki) para enlazar los diferentes documentos que utilizamos, mantener una lista de enlaces externos de interés y documentar los proyectos propios y de clientes así como las ideas de posibles proyectos futuros.

Página principal del Trac de 21projects

De esta manera, es posible ir documentando todo el proceso de desarrollo, incluir imágenes, enlaces y crear una documentación fácil de modificar y sobre todo, muy potente gracias a las funcionalidades de Trac.

Cada vez que un desarrollador acabe con la implementación de un Ticket, deberá marcar ese Ticket como resuelto y trás haber subido el código al repositorio Subversion, este cambio se reflejará en Trac a través de la sección que nos permite navegar por nuestro código.

Aunque existen muchas otras funcionalidades que vienen con Trac por defecto y muchas más que pueden añadirse a través de nuevos plugins, os dejamos que experimentéis con esta fantástica herramienta que permite mejorar la gestión de un nuevo proyecto software tanto a nivel de código como a nivel de documentación. Otra fantástica idea es abrir el Trac para que los usuarios u otras empresas puedan ver lo que hacemos e incluso colaborar añadiendo nuevos Tickets al encontrar un bug en la aplicación.

Si tenéis cualquier duda acerca de esta herramienta u os interesa utilizarla en vuestro negocio y no sabéis como empezar contactad con nosotros, estaremos encantados de ayudaros.

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