Pages Menu
Categories Menu

Posted by on Jul 25, 2014 in General | 5 comments

¿Cómo mantengo bajo control las muchas bases de datos que hay en los entornos de desarrollo, pruebas, producción…?

En el día a día del desarrollo del software, tenemos que gestionar las bases de datos a las que se conectan nuestros programas.

En el caso más sencillo, podemos encontrarnos que nuestro software simplemente se conecta a una única base de datos.

Ante un esquema así, nos resulta sencillo mantener controlada la base de datos: saber en qué estado está, si hemos modificado sus campos, su esquema o no, etc.

software-bdPero normalmente las cosas se complican un poco más. Aunque el software se conecte a una única base de datos (en muchas ocasiones la situación es algo más compleja y el software se conecta a distintos tipos de bases de datos) la realidad con la que chocamos es que solemos tener distintos entornos: el de los desarrolladores, uno para las pruebas, el de integración para el servidor de integración continua, el de producción… cada uno con su base de datos.

entornos

Y a medida que vamos desarrollando, nuestro software tiene que ir pasando por estos entornos, para someterlo a distintas pruebas hasta llegar a producción.

Por eso, cada uno de los entornos debe tener una réplica parecida de la base de datos. Y sobre todo, si utilizamos bases de datos relacionales, el esquema de la base de datos debe mantenerse igual en todos los entornos.

Así, tenemos que gestionar múltiples entornos, y concretamente saber qué versión del software está en cada uno de ellos y en qué estado está su base de datos.

Los retos de tener varios entornos de desarrollo de software

Lo cierto es que tener varios entornos de desarrollo, que se utilicen para distintas cosas, nos aporta beneficios.

Por ejemplo, permite que el trabajo de los distintos roles del equipo o de la empresa no se pise entre sí. También se fomenta la colaboración o hace que podamos probar cosas en un entorno y solucionar los fallos sin afectar al usuario, entre otras cosas.

Sin embargo, tenemos que saber qué hay en cada entorno, tanto el software que hay desplegado, como la base de datos.

A lo largo de estos años, en el lado del software, hemos ido desarrollando distintas técnicas y buenas prácticas para mantener lo que hay en cada entorno bajo control: está el control de versiones para gestionar las modificaciones en el código; las builds (compilaciones) automáticas, la integración continua (La integración continua y el “smoke test”), hacer tagueos cuando una versión pasa a producción, despliegues automáticos (cosa que podemos hacer con herramientas como Puppet:  Simplifica drásticamente la administración de sistemas: Puppet en 10 min) etc.

Ayudándonos de todas estas buenas prácticas podemos saber qué versión del software está en cada entorno y gestionar la trazabilidad (Por qué la trazabilidad software importa).

¿Pero qué pasa con la base de datos?

Mientras que las buenas prácticas o recomendaciones a la hora de gestionar el código están más elaboradas, con el tema de gestionar las bases de datos y sus versiones no ocurre lo mismo.

Al tener varios entornos, suelen surgir las siguientes preguntas:

–        ¿Cuál es el estado de la base de datos en esta máquina?

–        ¿Ya está aplicado este script de base de datos en esta máquina?

–        ¿Lo que solucionamos en la base de datos de producción se ha transmitido al resto de entornos?

–        ¿Podríamos crear una copia de la base de datos partiendo de cero?

Y muchas veces, no tenemos claro este tipo de cosas. Muchos proyectos incluso dependen de scripts SQL lanzados manualmente, o incluso de scripts de última hora sobre alguna base de datos para arreglar los fallos.

La solución: ¡herramientas de migración de base de datos!

Para ayudarnos en esto, surgen las herramientas de migración de base de datos. Entre las más conocidas están Liquidbase y Flyway, ambas open-source, gratuitas.

Con este tipo de herramientas podemos crear réplicas de bases de datos desde cero, saber en qué estado está cada base de datos de cada entorno, saber qué cambios se han ido haciendo en la base de datos y quién los ha hecho, migrar de una versión de la base de datos a otra etc.

Además de poder estar seguros de que nuestro software funcionará con el estado actual de la base de datos del entorno en el que se está probando.

Flyway

Para ponerte un ejemplo de qué hacen estas herramientas, me gustaría contarte cómo funciona Flyway. No digo que sea mejor que Liquidbase, porque aunque tienen diferencias, ambas cumplen su función.

Además las dos se integran perfectamente con herramientas Maven o Ant (Simple y rápido. Entiende qué es Maven en menos de 10 min. )

Flyway, por ejemplo, para saber en qué estado está una base de datos, se basa en una tabla de metadatos especiales, que crea automáticamente cuando lo ejecutamos por primera vez.

Después, cada vez que se aplica una modificación en la base de datos, los detalles se guardan ahí. Así Flyway puede consultar qué migraciones se han aplicado, cuál es la versión actual del esquema de la base de datos y si la última migración fue un éxito o falló.

Cuando llega a una base de datos y observa que en su tabla de metadatos no se han aplicado las nuevas migraciones, las va aplicando en orden, manteniendo todo sincronizado.

Si la migración falla, Flyway hace un roll back, una vuelta atrás al estado anterior estable a la migración.

Migración de base de datos en la integración continua, continuous delivery y continuous deployment.

Aunque este tipo de herramientas pueden ser también muy útiles en cualquier situación, cobran mucha importancia al aplicar la integración continua, sobre todo en la entrega continua y despliegue continuo.

Tanto Liquidbase como Flyway pueden integrarse con Jenkins (¿Qué es Jenkins? Explicado en menos de 10 min para quienes no lo conocen de nada.), garantizando por ejemplo, que al realizar despliegues automáticos del código el estado de la base de datos está actualizado.

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

5 Comments

  1. Hace tiempo me preguntaba si existía algún software de este tipo, y me parece súper interesante, pero muchas veces nos encontramos con varios problemas:
    1. No siempre te dejan instalar este tipo de software en máquinas de producción (casi nunca).
    2. En muchos casos son reacios a instalar software open-source aunque sean máquinas de desarrollo.
    En cualquier caso muy interesante y si surge la ocasión intentaré probarlos.
    Un saludo y gracias por tan buena información.

  2. Las herramientas (al menos Liquibase) permiten generar el SQL en lugar de ejecutar los cambios. De esa manera, se pasa al DBA correspondiente como cualquier otro script que se deba ejecutar en la base de datos de producción durante el despliegue de una nueva versión.

  3. Un equipo con cierto grado de madurez no debería tener problemas en hacer que se propaguen los cambios (versiones) de la base de datos desde el entorno de desarrollo a producción, pasando por n entornos intermedios. Hay que dar la misma importancia al código de la aplicación que al de bdd.

    Lo que realmente me parece muy interesante es la capacidad de hacer rollback automáticos de cambios en la estructura de la base de datos. Habra que probarlas! Gracias!

  4. Más allá del rollback del esquema, me interesa que se pueda conversar sobre la data que reside en dicho rollback y como no romper logicamente los modelos de datos dejando inconsistencias. Si bien el versionamiento del esquema es un problema, desde mi punto de vista son los datos los que hacen que todo esto se vuelva una tarea titánica.

    Saludos

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This