¿Y qué pasa con la integración continua de bases de datos?

Ayer la gente de 233 Grados de TI (¿todavía no sabes quiénes somos? 233 Grados de TI: Nace una empresa + una comunidad de voluntariado ¡Hello World!) fuimos al Enterprise DevOps Day, que se celebró en Madrid, en el Bernabeu.
Lo cierto es que nos interesan mucho las buenas prácticas de Ingeniería del Software en general y mejora de la calidad del software (donde la integración continua tiene un papel importante) tanto de procesos, producto y equipos.
DevOps es un concepto que está muy de moda en estos últimos años, y que también está muy relacionado con las prácticas ágiles.
La idea es romper la barrera entre los departamentos de una empresa, sobre todo entre sistemas y desarrollo, y fomentar un ambiente colaborativo, multidisciplinar y de mejora de calidad continua.
Aquí desarrolladores y sistemas no son roles separados que no se comunican.
La idea es que por ejemplo los desarrolladores no vayan por un lado programando y cuando finalicen su trabajo sistemas se encargue de los despliegues y sean los únicos que sepan y tengan control absoluto sobre ellos. Sino que el conocimiento se distribuya en el equipo.
Por eso aquí entran conceptos y prácticas como integración continua y entrega y despliegue continuos.
Como veis estos conceptos no son nada nuevos, pero están tomando mucho peso últimamente, sobre todo, porque muchas empresas no solo quieren tender hacia integración continua, sino hacia temas más avanzados como entrega y despliegue continuos (existen diferencias entre ambos conceptos: Un libro en español sobre Integración Continua e… ¿integración, despliegues o entrega continua?).
En querer ser capaces de hacer despliegues continuos ha influido que ciertas empresas se enfrentan a tener que evolucionar muy rápido y necesitan adaptarse a los cambios constantes de su negocio, maximizando la calidad y valor que aportan a sus clientes.
Y en este día, se habló sobre todo de enfocarse hacia un despliegue continuo.
Nosotros, desde 233 Grados de TI – Empresa, entre otras cosas, llevamos a cabo implantaciones de integración continua, intentando llegar en último punto a la entrega y despliegue continuos (que no es nada fácil).
Para mí integración continua, además de lo que es como concepto en sí (detectar fallos lo antes posible en etapas tempranas del desarrollo) y las buenas prácticas que engloba (si no sabes lo que es integración continua, dediqué una serie de post sobre qué es y cómo implantarla: Aprende a implantar integración continua desde cero (I): ¿Por qué integración continua? ) significa hacer que la vida de los desarrolladores y, en general, de la empresa (en términos técnicos) sea más cómoda.
Para ello, uno de los puntos de mejora de productividad, muy relacionado con lo que comentaba antes de DevOps es automatizar los procesos repetibles, cuya realización manual no aporte valor a la empresa.
Así esas personas que se dedicaban a esa tediosa tarea, pueden dedicarse a otras cosas de más valor.
Y uno de estos procesos o tareas repetibles son los despliegues (subidas de software a distintos entornos).
Aunque no tengamos despliegue continuo, si hablamos de integración continua, también necesitamos desplegar código, aunque sea en entornos bajos (desarrollo y pruebas, por ejemplo).
Realmente en tu organización, ya se saben hacer despliegues. Ya sabe los pasos y el orden que hay que seguir para desplegar una aplicación, por lo que no aporta mucho valor seguir haciendo ese proceso manualmente.
Si es cierto que dependiendo de para qué entorno, sobre todo para el paso producción, hay que tener distintos factores en cuenta a la hora de realizar y automatizar el despliegue.
Por ello siempre se suele empezar a automatizar los despliegues desde entornos bajos hacia arriba, dejando producción en última instancia, cuando el proceso esté muy elaborado.
Pero si realizamos a mano esos procesos repetibles, podemos cometer errores, y siempre un proceso manual es mucho más difícil de ejecutar de forma frecuente y rápida.
Si queremos orientarnos a despliegue continuo, esta parte debe estar automatizada, además de que el equipo tenga interiorizadas las buenas prácticas de integración continua y tengamos una buena infraestructura de integración continua, entre otras cosas.
Y es en este punto, donde me resulta curioso como a veces cuando hablamos de despliegues, de automatización de procesos repetibles, nos olvidamos de la gestión de bases de datos.
Integración continua también engloba lo que llamaríamos integración continua de bases de datos, es decir, saber cuál es el estado de las bases de datos de cada entorno, qué scripts se han pasado en qué entorno, cómo afrontar y gestionar los cambios en los scripts de bases de datos etc.
Personalmente creo que esto es una de las cosas que más problemas suelen dar. Aunque llevamos más tiempo versionando código, y la automatización de los despliegues y vuelta a versiones anteriores de software en caso de que algo falle en el despliegue (rollback) está bastante elaborado, tanto la gestión manual, como la gestión, versionado y despliegue automatizado de bases de datos es más tedioso, da más problemas, miedo y no está tan interiorizado en nosotros. Y lo mismo con el rollback.
En muchos sitios que aplican integración continua, esta gestión de base de datos se sigue haciendo manualmente. No se atreven a dar otro paso más.
Y esto es uno de los principales retos que tu empresa tiene que afrontar si quieres orientarte a la entrega y despliegue continuos.
Una aplicación software es base de datos y código. Y sí se puede aplicar integración continua sobre base de datos.
Para ello hay que tener una buena gestión de scripts de base de datos y versionado (al fin y al cabo es código).
¡Que una aplicación no falle en un entorno, porque se nos olvidaron pasar los cambios de base de datos! En estos casos, estamos perdiendo tiempo, y aumentando la frustración de la gente del equipo.
Lo ideal es que sepamos qué versión de código tenemos en un entorno y cuál es su versión de base de datos asociada.
Si por ejemplo falla algo en la versión 1.0.2, tenemos que ser capaces de saber qué versión de base de datos le corresponde, y ser capaces de levantar un entorno con esa versión de código y base de datos, para poder solucionar ese error.
Por eso veo interesante dedicar algunos post en las próximas semanas a este tema: control de versiones de bases de datos, gestionar cambios de bases de datos e integración continua de bases de datos (introducimos algo de estos temas al hablar de Flyway).
Por otro lado, siempre que vamos sitios donde se hablan cosas de DevOps, integración continua y demás, me gusta sacar este tema de gestión de base de datos.
Y es que muchas veces no hace falta reinventar la rueda, sino adaptarla.
Desde 233 Grados de TI, creemos muchísimo en la difusión y creación del conocimiento de Ingeniería del Software, y nos gusta compartir nuestras experiencias y aprender de las experiencias de los demás. Y hacia ello orientamos también la Comunidad 233.
Por ello, a lo largo de estos post, me encantaría saber cuál es vuestra experiencia con temas de este tipo. ¡Así que no dudéis en comentar! 🙂

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023