Como versionar nuestras aplicaciones y algunas ideas para automatizar

Si será importante el versionado de nuestras aplicaciones que lo primero que preguntamos cuando nos reportan un problema es "¿Que versión tiene de la aplicación?".

Nomenclatura

Lo primero es definir la nomenclatura vamos a utilizar. La nomenclatura utilizada normalmente es:

x.y.z

x: Cambio mayor.
Esto podría ser interpretado como un cambio importante en la aplicación. En un lenguaje como .Net podría representar el cambio de la versión del framework o Java de la máquina virtual. También, o más importante, una nueva versión de todo el sistema o un cambio significativo, por ejemplo, un nuevo frontend.

y: Cambio menor.
En este caso, generalmente se utiliza para al agregado de nuevas funcionalidades al cierre de un ciclo, por ejemplo, de un sprint.
En mi caso, normalmente lo incremento en cada cambio de base de datos. De esta forma puedo saber cuáles versiones incluyen cambios de estructuras.

z: Correcciones/patches
Puede ser utilizado para hotfixes, funcionalidades y otros, de forma que estén vinculados a una versión específica.

Como saber en qué versión estamos trabajando

Es de suma importancia saber en qué versión estamos, y tener en cuenta que podemos tener, por un lado, la versión de la estructura de datos y por otro, la versión de los binarios las cuales no siempre están alineadas, o al menos por un corto período de tiempo mientras se actualiza el sistema.

Sabiendo esto, se pueden ejecutar procesos de conversión de datos y otros en cada actualización del sistema, como veremos más adelante.

Versión en los binarios o de la aplicación

La versión en el binario es la versión que se está ejecutando de la aplicación, y debe estar dentro de los propios binarios.

Para logar esto, debemos tener una función en nuestra aplicación que nos retorne la versión actual hardcoded. Si estamos en POO puede ser un atributo o propiedad estática de una clase.

En GeneXus podemos crear un procedimiento (Ej.: "VersionGet") el cual retornará el número de versión y quedará dentro de los binarios generados.

Versión de la base de datos

La versión de la base de datos debiera estar sincronizada con la versión de la aplicación. Seguramente puedan variar por un instante en el momento en que se ejecuta una actualización de la aplicación.

Esta versión queda guardada dentro de la base de datos, normalmente como un parámetro. Finalmente se termina sincronizando con la versión de la aplicación, como veremos en el siguiente punto.

Actualización de la versión de base de datos

Una vez que tenemos las dos versiones, podremos ejecutar procesos de reconversión automáticos dependiendo de la diferencia entre ambas versiones. Este es un momento de oportunidad para realizar alguna acción mientras la versión de la base de datos sea menor que la versión de la aplicación.

Un pseudo código para esto podría ser el siguiente:
&VersionTmp = VersionDBGet()
do while (&VersionTmp < VersionAPPGet())
    do case
        case &VersionTmp < A
            TransformacionA()
            &VersionTmp = A
     
        case &VersionTmp < B
            TransformacionB()
            &VersionTmp = B
     
        ...
     
        case &VersionTmp < N
            TransformacionN()
            &VersionTmp = N
     
        Otherwise
            &VersionTmp = VersionAPPGet()
    endcase
enddo
if VersionDBGet() < &VersionTmp
    ActualizarVersionDB( &VersionTmp)
endif
Como se puede ver, con esto tenemos la oportunidad de generar conversiones de datos, creación de parámetros e inicialización de funcionalidades de forma automática luego de realizar una actualización de la aplicación. Seguramente esto esté encapsulado en algún proceso como parte de la actualización.
También es muy útil en sistemas distribuidos cuando la actualización puede ser de varias versiones a la vez.

Comentarios

Entradas más populares de este blog

Buenas prácticas al registrar logs en desarrollo de software

Buenas prácticas trabajando con parámetros o configuración del sistema

Enviando nuestros logs a Kibana rápido y simple