Mi espacio

Esta será una de esas entradas cortas que escribo simplemente para hacer referencia a ella en el futuro. Cuando nos compramos un electrodoméstico, ya sea una lavadora, un frigorífico o un lavavajillas, procuramos que vengan a casa, lo instalen y nos muestren que lo que hemos comprado funciona. Luego tenemos el manual de instrucciones que muy poca gente lee y que nos permite sacarle el máximo partido al electrodoméstico.

Pues bien, cuando nos están mostrando que aquello funciona si vemos que un sospecho piloto con la etiqueta error se pone rojo, lo normal es que preguntemos: ¿Qué significa ese piloto? ¿Estás usted seguro que funciona? Si no funciona no lo quiero, se lo tiene usted que llevar y me trae uno nuevo, con su embalaje original.

Lo que quiero decir es que cuando nos entregan algo nuevo no es normal que los LCDs o los indicadores informen de que algo no está funcionando bien y que hay problemas. ¿Por qué cuando se hace la entrega de un software (desarrollado a medida, llave en mano) no hacemos lo mismo? En este caso, en su defecto tenemos algo muy básico pero no por ello menos efectivo que son los logs. No quiere decir esto que los logs sean algo en lo que debamos centrarnos exclusivamente pero sí que son suficientes para decirle al proveedor, “Sr. Jefe de Proyecto, este entregable no lo aceptamos hasta que esos problemas que ahí se indican no estén resueltos”.

Está claro que un entorno de despliegue dotado de herramientas de monitorización se agradece y es un lujo, pero a veces me conformaría con que el servidor de aplicaciones o el servidor web tenga los logs configurados convenientemente. También podemos prestar atención a las distintas opciones que nos brindan los distintos stacks tecnológicos. En Java tenemos muchas herramientas, pero también las tenemos en PHP o Python.

Y también me gustaría decir:

Empresas que en su sitio web pone que están certificadas en CMMi nivel 3 y sin embargo ponen path absolutos en medio de scripts de PHP ;(

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?

La verdad es que ha costado, pero por fin, puedo anunciar el nacimiento de QABox. Aun tenemos que resolver ciertos aspectos técnicos pero eran tantas las ganas que no hemos podido esperar más. Espero y deseo que en breve, tengáis nuevas noticias con respecto a esta iniciativa.

Hace unos instantes he recibido un correo de la organización de ExpoQA diciendo que han publicado el material de las ponencias.

Como ya hiciera el año pasado, este año asistiré a una nueva edición de expo:QA. Este año espero escribir una pequeña crónica de los dos días que asistiré. El programa de este año -parece- que incluye contenidos más cercanos a nuestro día a día. El año pasado me quedé con mal sabor de boca, especialmente porque todo el aseguramiento de la calidad consistía en adquirir herramientas carísimas y las experiencias reales brillaron por su ausencia, y las que hubo, pertenecían a sectores (industriales, banca, etc…) que se escapan de mi alcance.