Mi espacio

Version Naming, Software Versioning o Sistemas de Versionado, es lo que se conoce como el proceso con el que identificamos de forma única el estado de los fuentes de un proyecto. Obviamente puede hacerse extensible no sólo al software, sino también a un documento de texto. Según los sistemas de gestión de la calidad debe incluirse un histórico de cambios.

¿Qué objetivos pretende cubrir un sistema de versionado?

1. Identificar de forma sencilla el estado de los fuentes. Esa identificación estará asociada a un instante de tiempo
2. Establecer una codificación que permita distinguir unas versiones de otras
3. Informar sobre qué contiene la versión

Existen muchas propuestas y cada una de ellas se adecua a unas necesidades. Nosotros hasta la fecha usábamos una muy conocida basada en:

• alpha
• beta
• Releases Candidate
• X.Y.Z

La versión alpha es una versión completa desde un punto de vista funcional. El equipo de proyecto debería ser capaz de justificar que los requisitos y expectativas detectadas se han alcanzado. Los que nos dedicamos a esto sabemos que es prácticamente imposible, especialmente en proyectos de más de 6 meses. La entrega oficial de una versión es un punto de inflexión en la relación entre el cliente y el proveedor. Está claro que el proveedor le está transmitiendo al cliente que para el proyecto se encuentra en su etapa final y que es el momento de ir cerrando los temas pendientes (artefactos documentales, sesiones de formación, etc).

La versión beta constituye otro momento importante en la vida del proyecto. Tras la entrega de la versión alpha se recoge comentarios, opiniones, peticiones de cambio, “…es que yo pensaba, yo creía que…” (por ambas partes), el departamento de sistemas añade sus “…esto lo quiero así, si hibernate te genera el DDL eso me da igual…“, y evidentemente si no quieres que el proyecto se te vaya en costes, negocias. Personalmente creo que es una -falsa- negociación porque como proveedor comienzas a ver el final y tu mayor deseo es implantar el proyecto y verlo como ayuda a los verdaderos usuarios finales.

Y luego vienen las versiones RCx, que junto con la versión beta, modelan las distintas iteracciones cliente-proveedor. Así, hasta llegar a la versión 1.0.0 donde se hace entrega oficial de los fuentes y corresponde con la versión que pasa a producción. A partir de ahí, comienza el soporte y mantenimiento que dará lugar a:

• 1.0.Z: Resolución de incidencias sobre la versión 1.0.0
• 1.Y.0: Si aumenta la Y, la Z se pone a cero e implica que se han incorporado mejoras y probablemente resolución de incidencias
• Z.0.0: Conlleva lo anterior pero además implica cambios importantes a múltiples niveles (diseño, funcionalidades, UI, etc..)

Esto es, de forma muy resumida, lo que venimos usando desde hace 2 años. Muy relacionado con otras prácticas de nuestra metodología nos hemos visto obligados a realizar una pequeña modificación e incorporar el concepto Partial Delivery:

1. No están reflejadas en el roadmap del proyecto, no constituyen ningún hito
2. Normalmente vienen originadas por una petición externa al equipo de proyecto
3. Están referenciadas en la herramienta de gestión de proyecto
4. Se podrían haber sustituido por conceptos como revisión propios de los S.C.M. pero resulta más sencillo trabajar con alpha-PD1 que con rev657.

Por aclarar algunos puntos:

1. En nuestro entorno de despliegue, y como parte de las actividades de integración continua, el estado de los fuentes es referenciado como 1.0.0-SNAPSHOT-r2203 o 1.0.0-DEV-r2203. Para la revisión usamos buildNumber.
2. Sólo versionados aquello que necesitamos referenciar.

En ciertos proyectos, por su diseño y base tecnológica, incorporamos otras prácticas. Por ejemplo, en aquellos con un alto índice de modularidad  cada módulo mantiene su propio versionado y las entregas incluyen un documento (o MasterBuild) en el que se detalla o define la entrega. Como ejemplo podemos ver aquellos que se basan en OpenCms o Drupal.

Y tú, ¿Cómo llevas a cabo este proceso?

Hace algunas semanas escribía una breve entrada sobre librerías para trabajar con hojas de cálculo Excel desde Java. En esta ocasión he tenido la necesidad de exportar un conjunto de datos en formato CSV. Generar un archivo con datos separados por comas o punto y coma es sencillo, y quizás, no compense añadir una nueva dependencia para algo tan simple. Antes de ponerme a codificar, decidí ojear un poco:

1. Java CSV
2. SuperCSV

Opté por la segunda porque me ha permitido trabajar directamente con JavaBeans y es algo más completa que la primera. Otra librería que conocí hace algún tiempo es Smooks. Aunque hubiera sido como cortar el césped con una excavadora, estuve tentado a usarla. Tiene muy buena pinta y las referencias y ejemplos que he visto, son muy interesantes.

Como viene siendo habitual en los últimos meses, todo aquello que estamos haciendo con OpenCms y creemos que puede ser de interés, lo liberamos con licencia GNU/GPLv3. En esta ocasión un módulo que permite importar múltiples módulos de una sola vez.

Nuestro enfoque al trabajar con OpenCms es granularizar todo lo posible los módulos (tipos de contenidos, widgets, puntos de administración, etc). Esto tiene mucho beneficios, pero también complica el mantenimiento del sistema. Para evitarlo:

1. Todos los módulos están modelados con Apache Maven y dependen de un proyecto padre desde el que lanzamos tareas comunes.
2. Gracias a Apache Maven, preparamos un distribuible binario que genera un ZIP con todos los módulos. Este ZIP es el que le proporcionamos al módulo MultiModuleImporter.

Como no podía ser de otra forma, dar la enhorabuena a mis compañeros.

Desde luego no es la primera vez que me lo planteo pero recientemente he vivido alguna situación que me ha hecho reaccionar. En Andalucía existe un conjunto de proyectos horizontales (@firma, Trew@, Solicit@, @ries, etc) que conforman el soporte de la administración electrónica.

Muchos de los proyectos que se desarrollan para la administración pública andaluza están condicionados por estos proyectos. Y digo condicionados por desde el propio pliego ya se indica qué componentes deben usarse.  En algunos casos su integración es muy positiva pero en otros es ganas de disparar los indicadores de riesgo de proyecto. Dejando a un lado opiniones no argumentadas, me hago la siguiente pregunta:

¿Por qué resulta tan complicado para los proveedores de software que NO hemos participado en esos proyectos horizontales acceder a esos servicios?

Sé que existe documentación publicada, la posibilidad de acceder a los binarios de algunos de estos servicios, que siempre circulan por ahí CD con contenido no oficial, etc. ¿Pero no sería más conveniente e inteligente acercar estos servicios a los proveedores de software para que todo resultase más sencillo? ¿Sabéis lo frustrante que resulta tener que descompilar una clase para solucionar una incidencia? Bueno, y depurar una odisea.

Tengo que reconocer que algunos de estos servicios (denominados normalmente plataformas), por su naturaleza no pueden estar accesibles de forma pública. Sin embargo, creo que existen alternativas sencillas que pueden facilitar el trabajo. Recientemente he realizado algunas propuestas:

1. Estos proyectos ofrecen en su mayoría interfaces basadas en servicios web para su integración. Sería de gran utilidad, si no se quieren/pueden distribuir, ofrecer simuladores para que los equipos de desarrollo puedan diseñar al menos sus pruebas de integración y funcionales.
2. ¿Por qué no distribuir máquinas virtuales con estos proyectos instalados y configurados? Son muchos los ecosistemas software que cuentan con entornos virtualizados donde resultaría trivial desplegar estas máquinas y así poder configurar entornos despliegue.

La propuesta ha sido realizada donde corresponde e incluso me he ofrecido a formalizarlas para conocer costes e impacto. ¿Alguna otra propuesta?