En nuestro proyecto TPVFOX versionamos X.Y.Z
Método de crear versiones (tag)
Esto quiere decir que:
X: Fin de una etapa, ya se terminó de implantar de nuevas funcionalidades.
Y: Añadimos alguna funcionalidad o cambios bastante grandes.
Z: Pequeños cambios y pequeñas mejoras. Este número indicar cuantos commit esta por encima de la última versión (pequeños parches), si eres desarrollador y quieres saber que numero de version ver la respuesta a el punto siguiente , donde te explica como obtener cuando commits esta por encima.
¿Cómo sabemos en versión estamos?
De momento saber cuál es la única forma de saber cuál es la versión en la que estamos es a través de un repositorio de Git y desde la terminal poniendo la siguiente instrucción:
git describe
La respuesta es algo así
▶ git describe
v0.3.0-29-g3266211c
v0.3.0 es el tag, la versión que estamos. 29 indica que la rama actual esta 29 commit por encima de ese tag.
En la rama STABLE no debería indicar ningun numero, ya que no es habitual que estemos encima sin tener versionado. En otras ramas, como MASTER si puede estar por encima, ya que son ramas que estan en constante desarrollo.
Versiones de nuestra Base de Datos
Todos sabemos que los cambios en la estructura de la Base datos implica siempre posibles problemas con el código
Como versionamos nuestra Base de datos
En nuestro proyecto TPVFOX cuando realizamos un cambio en la estructura de la base de datos, lo que hacemos es un fichero con los cambios indicando la versión, este fichero se guarda en el directorio BD/Update con el nombre y sufijo de la versión, como indicamos a continuación:
install_update_vX.Y.[Z]
[Z] Estos al igual que al anterior, nos indica cuantos commits estamos por encima de la rama actual. No tiene por qué existir esa versión con esa terminación, pero sí son correlativas.
En estos ficheros puede encontrar las instrucciones SQL para ejecutar y así actualizar tu Base de Datos.
Siempre que hagamos un cambio en la base datos, generamos un fichero install_update_vX.Y.Z que es realmente el commit que vamos a hacer justo después de crearlo.
Cuando vayamos a actualizar un repositorio, simplemente debemos saber en versión estamos y luego actualizar el repositorio, luego solo tenemos que ejecutar los ficheros superiores a la versión que estábamos.
Por ejemplo, si estamos en la versión v0.2.22 del código, si actualizamos hasta la versión v.0.3.30, debemos ejecutar todos los ficheros que hay con las versiones superiores v0.2.22 en el directorio BD/Update, hasta la versión que vamos a actualizar.
Posibles problemas con Base Datos de backup
Nos podemos encontrar con el problema que cuando tenemos un backup de base de datos, ya que no sabemos en qué versión está esa copia. Y tampoco podemos comprobarlo con el código, puesto que realmente no está en funcionamiento y no tenemos repositorio instalado para ese backup.
Por este motivo, creamos este issue en el proyecto, para poder registrar el número de versión en una tabla de configuración, así de esa forma podemos guardar en esa tabla el número versión de la base de datos y luego simplemente tendríamos que actualizar desde esa versión.