Cómo llevar los cambios de una base de datos de desarrollo a producción

Cuando tenemos una aplicación en producción (Es decir, siendo utilizada por usuarios reales) es muy común que nos encontremos con necesidades que no han sido cubiertas por el desarrollo original.

Esto puede deberse a diversos factores como la falta de análisis, una pobre comprensión de la problemática a encarar o simplemente al hecho de que la realidad va cambiando conforme pasa el tiempo.

Independientemente de cuál de éstas haya sido, cuando se detecta una necesidad que el software no cubre se requiere realizarle modificaciones para adaptarlo al nuevo escenario.

Algunas veces los cambios en el código vienen de la mano de cambios en la estructura de la base de datos utilizada para dar soporte a la aplicación.

Y ahí comienzan los problemas 🙂

En un ambiente de trabajo profesional es muy común contar con diferentes entornos de ejecución.

Al menos deberíamos tener dos:

• Desarrollo (Donde trabajamos y los datos no son precisamente valiosos)
• Producción (Donde trabajan los usuarios y los datos son sagrados).

Parte de nuestro trabajo será realizar las modificaciones al código de la aplicación, probarlo y eventualmente desplegarlo en el servidor de producción.

Para llevar el control de los cambios realizados sobre el código existen muchos sistemas de control de versiones, como por ejemplo Git o Subversion.

Utilizar uno de estos sistemas simplifica mucho conseguir la perfecta sincronización entre el código que ejecutamos en nuestro entorno de desarollo y el de producción, pero… ¿cómo hacemos para que la estructura de la base de datos también esté sincronizada?

Actualizar la base de datos manualmente

El enfoque más simple consiste en aplicar los cambios a la base en forma manual.

Esto significa entrar al servidor de bases de datos (Usando phpMyAdmin por ejemplo) y ejecutar los comandos que dejen la base en el estado deseado.

Para usar esta estrategia no se necesita mucho más que buena memoria o buenas notas.

Claro que la desventaja de este mecanismo es que es sumamente riesgoso y propenso a errores.

Utilizar scripts SQL

Otra opción más interesante es generar los scripts SQL que se utilizan durante el desarrollo y almacenarlos como parte del código, de modo de aprovechar el versionado de la propia aplicación.

Este enfoque es mejor que el anterior ya que disminuye el riesgo de ejecutar comandos diferentes en cada ambiente y, de ese modo, minimiza las chances de terminar con estructuras de bases de datos distintas.

Uno de los problemas que aún no resuelve este enfoque es cómo determinar de un modo simple cuáles cambios ya han sido aplicados y cuáles no.

Versionar la base de datos

Un enfoque alternativo es el uso de alguna herramienta para el versionado de la base de datos.

En este esquema los cambios en el ambiente de desarrollo no se realizan escribiendo SQL, si no mediante código.

Liquibase

Liquibase es una herramienta basada en conjuntos de cambios (changeSets) descriptos usando diferentes lenguajes posibles (SQL, XML, Json o YAML).

Una vez definidos los cambios que deben realizarse se utiliza el ejecutor de los cambios que es el encargado de verificar el estado actual, traducir los nuevos cambios a SQL e impactarlos.

Migraciones de Doctrine

Otra herramienta similar (y mi favorita :)) es el mecanismo de migraciones de Doctrine.

Las migraciones son una parte de este gran ORM que describen los cambios que deben realizarse a la base de datos.

Una gran ventaja de este mecanismo sobre Liquibase o similares es que todo el código se escribe utilizando puro PHP y al momento de ejecutar la migración queda a cargo de Doctrine realizar la traducción a SQL.

Notas finales

Como siempre, cuanto más automatizada sea nuestra operación más confiable será ya que podremos realizar tantos ensayos como necesitemos hasta contar con un mecanismo correcto.

La contracara de utilizar una herramienta como esta es que es un camino de una sola vía: si no mantenemos la disciplina de escribir todos nuestros cambios del mismo modo nos vamos a encontrar con más problemas de soluciones… aunque, en la realidad, una vez que domines una de estas técnicas dificulto que quieras volver atrás 🙂