¿Qué sistema de versionado usas?

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?

2 thoughts on “¿Qué sistema de versionado usas?

  1. En mi caso, al tratarse de un proyecto desarrollado internamente, todas nuestras entragas son “partial deliveries” (excepto, quizá la última a final de año… pero será una “partial delivery” especial que coincida con el fin del contrato).

    Cada entregas supone un paso al entorno de integración (y, quiza, preproducción y producción) y son versionadas aumentando el segundo dígito en cada una (1.0.0, 1.1.0, 1.2.0…).
    Si, tras el paso a integración, detectamos problemas, esto se solucionan lo más rápidamente posible y se publica una nueva versión (1.0.1, 1.1.1, 1.2.1…).

    Por simplicidad, versionamos todos los módulos del proyecto con el mismo valor, por lo que incluso aquellos módulos cuyo código no ha cambiado sufren una subida de versión con cada entrega.

    Finalmente, no controlamos la versión concreta usada en integración continua. Simplemente es “la última versión en desarrollo disponible”, aunque utilizamos Hudson como motor de CI y está configurado para conservar los entregables de cada build. Además, Hudson nos permite crear desde la propia interfaz un tag a partir de la revisión concreta usada para una build, de forma que si alguna build es “importante”, podemos darle un nombre.

Leave a Reply

Your email address will not be published. Required fields are marked *