Primeros pasos a la hora de versionar las bases de datos relacionales

En estas últimas semanas hemos hablado sobre la importancia de versionar, evolucionar e integrar las bases de datos a la par que el código fuente (¿Y qué pasa con la integración continua de bases de datos?) y sobre quiénes se encargan de gestionar temas de bases de datos en los equipos ágiles (En Scrum, ¿quién es el responsable de gestionar las bases de datos?).
Necesitamos versionar la base de datos para ser capaces de promocionar los cambios de nuestra aplicación de un entorno a otro, de una manera consistente, reproducible y probable. Y ser capaces así también de volver a una versión estable (código + base de datos) en caso de que algo no vaya bien.
Pero, ¿cómo llevamos esto a la práctica? ¿cómo versionamos las bases de datos?
He querido dividir el tema del versionado de base de datos en 2 post.
En este primer post te voy a comentar unas primeras pautas básicas que veo útiles a la hora de gestionar y aplicar cambios de base de datos.
Y en el próximo post, hablaré de dos estrategias de versionado de base de datos: por un lado realizar scripts incrementales con pequeños cambios de base de datos y por otro versionar un único fichero con el esquema de base de datos.
Junto con sus pros y sus contras, para que tomes ideas o elijas la estrategia que más te convenga.
Al fin y al cabo, no existe una única manera de versionar el software, ni el código ni la base de datos. Lo que si es importante es tener unas pautas claras, que todo el mundo esté de acuerdo en la estrategia que implementemos y que dicha estrategia sea útil para la gente en el día a día.
Por ello, si quiero empezar a versionar una base de datos, ¿por dónde empiezo?
Mi consejo es que antes de implementar cualquier estrategia de versionado de base de datos (ya sean incrementales, mantener un esquema de base de datos único en un fichero etc, tema que profundizaremos más la semana que viene), crees lo que llamo “una línea base de tu base de datos”, es decir, una base de lo que partir para los posteriores versionados.

¿Qué es una línea base de tu base de datos ?

Trasládate por un momento al mundo del versionado de código fuente, con la herramienta de control de versiones que prefieras.
La primera vez que empezásteis a utilizar el control de versiones, alguien tuvo que subir un primer código base a vuestra herramienta.
Y este código después sirvió de referencia para que el resto del equipo se lo descargara, programara a partir de él, realizara sus cambios y los subiera de nuevo al control de versiones.
Pues apliquemos la misma idea a la base de datos. Necesitamos un punto base para realizar posteriores desarrollos; un punto estable a partir del cual continuar versionando la base de datos.
En este caso, esta línea base de base de datos será un script o conjunto de scripts que contendrán todos los comandos SQL para generar la base de datos actual de tu aplicación.
Una vez creada esta línea base, tengo que poder irme a una nueva máquina, y a partir de ella ser capaz de recrear la base de datos actual.
Por ello incluiríamos en esta base comandos para crear tablas, vistas etc, incluso comandos para insertar un conjunto de datos iniciales.
Y una vez creado este fichero, lo subiremos a la herramienta de control de versiones.
Cualquiera de nuestras estrategias de versionado de base de datos partirán de un control de versiones.
Si queremos relacionar la versión de código y de base de datos, es recomendable que ambos estén en un único repositorio de código.
Así haciendo un tag en nuestra herramienta de control de versiones (etiquetar, poner un nombre reconocible a lo que hay en el control de versiones en un momento dado, por ejemplo 1.0.1-alpha) , podremos tener fija una versión de código asociada a su versión de base de datos, lista para ser probada.
Además, puedes crear esta línea base de base de datos desde el minuto cero del desarrollo o posteriormente, en un estado avanzado de la base de datos si se trata de desarrollos ya empezados, no importa.

Pero hay más…

Pero la cosa no queda ahí. Al igual que ocurre con el código, deberemos saber para cada entorno (en este caso para cada base de datos de cada entorno), qué scripts de base de datos se han pasado en cada momento, qué cambios se han ido haciendo.
Por ello, te aconsejo que en las bases de datos a gestionar (desarrollo, test etc.) crees además una nueva tabla, que se usará para almacenar qué cambios se han hecho en cada base de datos.
Un ejemplo de esta tabla podría ser el siguiente:
schemaChangesTable
Aquí por ejemplo iremos guardando en qué fecha pasamos el script, cómo se llama el script y qué versión de código está asociada a dicho script.
De hecho, puede que esta visión de gestionar el versionado te resulte familiar. Muchas herramientas que se encargan del versionado y migración automática de bases de datos como Flyway (recuerda el post ¿Cómo mantengo bajo control las muchas bases de datos que hay en los entornos de desarrollo, pruebas, producción…? ) comienzan por este punto: creando una línea base de base de datos y añadiendo en cada base de datos una nueva tabla que almacenará identificadores de los scripts que se van pasado en cada entorno.
Por ello, tanto si
1 – quieres empezar a utilizar una herramienta tipo Flyway que automatice la gestión de cambios de base de datos en distintos entornos,
2 – quieres ir aplicando los cambios de distinta forma a través de tu servidor de integración continua (por ejemplo Jenkins, ¿Qué es Jenkins? Explicado en menos de 10 min para quienes no lo conocen de nada)
3 – solo quieres utilizar el control de versiones habitual y aplicar los cambios de scripts manualmente,
mi consejo es que crees ese esquema de base de datos inicial y mantegas algún sitio donde guardar qué scripts de base de datos se han pasado en qué entornos.
Tanto en la gestión manual y mucho más en la automatización, es muy útil tener un histórico de cambios, un sitio donde poder consultar si hemos pasado ciertos cambios de base de datos que tenemos en el control de versiones en un entorno o no.
Así, quien haga un cambio de base de datos, subirá de distinta manera dicho cambio al control de versiones (todo dependerá de la estrategia de versionado que sigamos).
Y cuando pasemos algún script de base de datos en algún entorno, tendremos que actualizar la tabla donde guardamos los cambios del esquema.
Podemos hacer este proceso manualmente, o automatizarlo por línea de comandos, en el servidor de integración continua al hacer compilaciones para cada entorno etc.
¿Utilizas alguna técnica de este tipo para gestionar los cambios de base de datos? ¡Coméntanos tu experiencia! 😀
Por cierto, si quieres saber más sobre integración continua, control de versiones, Jenkins etc, el próximo 4 de diciembre en Madrid daremos un curso sobre integración continua.

5 comentarios en “Primeros pasos a la hora de versionar las bases de datos relacionales”

  1. Nosotros hemos conseguido funcionar bastante bien gracias a la herramienta dbMaintain junto con su plugin para Maven.
    Así versionamos bbdd junto con código y nos permite tener bastante controlada la evolución de la bbdd.
    La propia herramienta bien configurada también permite actualizar la bbdd de una a otra versión aplicando únicamente los cambios necesarios.

  2. Buen dia, al momento estoy trabajando con dbmantain para el despliegue de la BD, pero estoy con algunos problemas, conoce de algun otro software que pueda utilizar para reemplazarlo.

  3. Josué Hernández

    Muchas gracias por compartir tus conocimientos, tus artículos son muy buenos y me gusta mucho como los explicas, tocas temas que nos toca que enfrentar en la vida real, he aprendido mucho con tus artículos, saludos desde El Salvador

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba