Hoy en día es fácil encontrar información sobre DevOps, es uno de los temas más populares y discutidos; muchos fabricantes, productos y plataformas están disponibles para guiarnos en el proceso de acelerar nuestra entrega de valor a nuestros clientes y usuarios; las guías son muy completas y detalladas, pero pocas abordan la problemática desde una perspectiva que no sea la del aplicativo. Este artículo es el primero de una serie que discutirá en detalle la definición de un esquema de DevOps para bases de datos.

Probablemente llegaste a este artículo buscando información sobre cómo aplicar una estrategia de DevOps, mucha de la información disponible se limita a cubrir los aspectos de versionamiento de código fuente y en algunos casos la liberación. Lo cierto es que cuando se trata de bases de datos no es fácil encontrar una guía completa que cubra todas las fases de forma integral.

Este va a ser un artículo un poco largo, pero es importante para poder establecer el marco conceptual antes de empezar con la resolución del problema.

El Problema

La principal diferencia entre una estrategia de DevOps para un aplicativo y una base de datos viene de la naturaleza de la base de datos; mientras que en una aplicación web es fácil pensar que al presentarse un problema bastaría con liberar la versión anterior para corregir todo, en una base de datos esa estrategia es simplemente imposible… Al pensar sobre bases de datos realmente debemos contemplar tres elementos:

  • Esquema o modelo
  • Código
  • Persistencia de información

El esquema o modelo es la organización de nuestra información, establece la forma en como los datos son almacenados y sirve de punto de partida para la programación, si modificamos la estructura nuestros procedimientos almacenados, vistas, etc., deben cambiar de forma acorde.

El código es la definición de nuestros objetos y, curiosamente, casi siempre es necesario para poder crear nuestro esquema, sin embargo, prácticamente todos los gestores de bases de datos proveen herramientas que generan el código tras bambalinas sin que sea necesario conocer los pormenores, de hecho, uno de los primeros problemas a la hora de querer implementar una estrategia de DevOps se deriva de esta práctica. De la misma forma que se tiene configuración como código e infraestructura como código es necesario tomar un enfoque de esquema como código y debe extenderse a cada uno de los objetos dentro de nuestra base de datos (incluyendo la creación de la base de datos).

Y finalmente, la persistencia es la característica que hace tan complejo trabajar con estrategias de integración y liberación continua, las versiones de una base de datos no depende únicamente de los cambios en el esquema, cada interacción de los usuarios genera una nueva versión para ese momento del tiempo, hacer una reversión implica cambiar el esquema para que refleje una versión anterior y hacer una integración (merge) de los datos que pertenecen a las estructuras de la versión anterior, descartando toda aquella información que sólo hacía sentido en el esquema de la versión que estamos desechando.

Desde mi punto de vista, una estrategia integral de DevOps para bases de datos debería contemplar los siguientes aspectos:

El objetivo de esta serie es explicar cada uno de estos aspectos de forma práctica, utilizando herramientas al alcance de todos, pero con un enfoque claro de cómo lograr los objetivos. Manténganse pendientes esto se pondrá interesante.

Hasta la próxima!