Uno de los grandes problemas de las organizaciones que tienen externalizado el proceso de desarrollo de software es la disponibilidad del código fuente de las aplicaciones. Pasa en demasiadas ocasiones que cuando se quiere realizar un mantenimiento de un sistema no se tiene acceso a todo el código fuente, lo que dificulta o impide (depende del tipo de sistema y del estado de los fuentes) la realización de dicha tarea y puede provocar cautividad respecto de los proveedores.
Por este motivo resulta fundamental disponer del código fuente de las diferentes versiones de los sistemas de información y eso no se consigue exclusivamente implantando un gestor de fuentes como por ejemplo SVN, sino que hay que arbitrar una serie de mecanismos. Me voy a centrar en los desarrollos en tecnología Java, aunque estas ideas son perfectamente válidas (directa o con ligeras variaciones) con otras tecnologías.
Lo más importante es que romper con las entregas de las aplicaciones mediante empaquetados, como por ejemplo la entrega de .war, ya que si este proceso lo realiza el proveedor no tendremos ningún tipo de garantía de que los fuentes almacenados en nuestro gestor (SVN) se corresponden con lo que nos han entregado. Por tanto el proceso de compilación y despliegue debe recaer en nosotros y no en el proveedor.
En el caso de mi organización, el proveedor tendrá los fuentes actualizados en nuestro SVN, las librerías dependientes accesibles en repositorios públicos y/o en nuestro repositorio (Artifactory) y la especificación de la aplicación en un fichero .pom.xml. El proceso de compilación, despliegue, etc… lo realizamos haciendo uso de Hudson (sobre Maven). No quiero decir ni que el procedimiento que venimos utilizando sea el mejor o que las herramientas elegidas sean superiores a otras, lo que realmente es importante es controlar, sea por el mecanismo que sea, que lo que se instala se corresponde con lo que tenemos en el repositorio de fuentes.
Todo lo anterior hay que acompañarlo con una correcta política de etiquetado y comentarios de las diferentes versiones en el gestor de fuentes ya que facilitará en gran medida la recuperación de versiones anteriores.
Aunque de momento se permite según nuestro libro blanco de desarrollo, desde mi punto de vista no es una buena política almacenar el .war junto a los fuentes de la versión, además de por el espacio que ocupa, por el riesgo de que no se corresponda con los fuentes. Sin embargo sí que me parece una buena política guardar en el SVN junto a cada versión la documentación que describe a la misma (en el caso de que la versión sea lo suficientemente significativa como para almacenar la documentación con la misma), sé que puede resultar incongruente con lo que he dicho de los .war, ya que también existe el riesgo de que no se corresponda con la versión y al que lo piense le tengo que dar la razón, no obstante, considero más complicado asociar en un futuro qué documentación se corresponde con qué versión que generar un empaquetado de una determinada versión. Con esto no quiero decir que la documentación no se almacene donde corresponda, es más, aconsejo que persista en un lugar diferente al gestor de fuentes, lo que sí me parece recomendable es que junto a la versión se haga una foto de la documentación que se corresponde a la misma y se almacene en el gestor de fuentes.
Jummp 