¿Cómo configurar el proceso de desarrollo de base de datos local para un pequeño equipo web?

Antecedentes

Estoy trabajando en la creación de un nuevo proceso de desarrollo para un pequeño equipo web de aproximadamente 4 programadores y 4 diseñadores, con el evidente potencial de hacer crecer el equipo en el futuro. Nuestro producto es una aplicación central que impulsa sitios web de clientes que también diseñamos y alojamos.

Anteriormente, todos trabajábamos a través de FTP en un servidor de desarrollo, con una única base de datos de desarrollo. "Funcionó" ^* por un tiempo, pero nos estamos moviendo en una nueva dirección, por lo que es hora de madurar nuestro proceso.

Usamos Percona Server 5.5, pero esto debería ser independiente de la base de datos, con la idea de mantener los costos bajos.

Objetivos :

Estoy pensando en crear un proceso de integración continua (CI) para el desarrollo de bases de datos con lo siguiente en mente:

1. Los desarrolladores tienen una copia local de datos para ejecutar el código de desarrollo en
2. Capaz de revertir la estructura de la base de datos a un conjunto de cambios anterior
3. Capaz de separar los nuevos cambios en el esquema de características frente a los cambios en el diseño del esquema
4. Capaz de modificar la estructura de la base de datos localmente para probar

Concepto inicial

He esbozado un proceso a continuación usando SVN y LiquiBase, aunque se elimina por completo #4.

• crear una rama de "desarrollo" desde el tronco
• el servidor de base de datos de 'desarrollo' se ejecuta fuera de la rama de 'desarrollo'
• Los desarrolladores locales se configuran como esclavos de la rama de desarrollo (se proporciona más #1arriba)
• Los conjuntos de cambios de liquibase se comprometen regularmente con la rama de desarrollo, que ejecuta un enlace posterior al compromiso para actualizar la base de datos de desarrollo central (que se filtrará a las máquinas locales que se ejecutan como esclavos de este servidor de desarrollo) (liquibase proporciona más #2arriba)
• cuando las características o las correcciones de esquema están listas para pasar al control de calidad, DBA (me) fusionará los cambios apropiados de la rama de desarrollo en el tronco. Este acto creará un script sql para aplicar a un servidor de base de datos provisional.
• El servidor de ensayo debe reflejar TRUNK, que debe tener la misma estructura que Production, más los cambios que se encuentran en QA
• después de ejecutar el script sql en el servidor de ensayo, realice un control de calidad en los cambios.
• Si todo se ve bien, etiqueta la estructura. Esto generará el script .sql para que el DBA lo ejecute en producción manualmente (para las horas de menor actividad si es necesario)

Este proceso requiere que todos los desarrolladores se ejecuten en la misma rama de "desarrollo", lo que significa que solo hay una versión del esquema de la base de datos en un momento dado (no estoy seguro de querer esto).

También significa que cualquier cambio en el esquema no puede probarse localmente y podría afectar a otros desarrolladores si no se hace correctamente. En nuestro entorno, los desarrolladores pueden agregar nuevas tablas pero rara vez modifican la estructura existente. Como DBA, las correcciones de diseño las hago yo. Pero la imposibilidad de probar las soluciones localmente es mi mayor problema del proceso.

¿Cómo se puede ajustar el proceso anterior para permitir el desarrollo local, mientras se mantiene una copia de datos relativamente actualizada (como lo proporciona la replicación en mi proceso propuesto)? No necesito que los datos estén actualizados hasta la última semana.

---

^* Por 'trabajado', quiero decir que fue suficiente pero fue un PITA.

Administrar entornos

Creo que definitivamente no quieres ser forzado a una sola versión de base de datos. Tiene suficientes desarrolladores que inevitablemente tendrá múltiples flujos de trabajo de desarrollo y requisitos para aplicar parches al entorno de producción actual independientemente de los flujos de trabajo de desarrollo.

Puede usar Liquibase o un proceso manual para producir scripts de parches para actualizar versiones. Sugiero comenzar con un proceso manual y usar la herramienta de comparación de esquemas para el control de calidad en los parches. La sincronización limpia, automatizada y transparente de una base de datos no trivialmente compleja es un poco utópica.

Su modelo de datos central puede mantenerse en cualquier sistema que desee. He usado todo, desde tediosas herramientas de repositorio empresarial para crear scripts de tabla. Las secuencias de comandos de creación de tablas funcionan bien con herramientas de control de código fuente ordinarias, como la subversión, y no todas las herramientas de repositorio hacen un buen trabajo de versiones.

Independientemente de lo que utilice como repositorio de modelo de datos maestros, necesita un mecanismo bastante limpio para implementar un entorno a partir de ese modelo. Debe estar estructurado de manera que los despliegues a un entorno sean fáciles. También necesita un mecanismo para parchear de una versión lanzada a la siguiente.

Qué he hecho

He hecho lo siguiente en el pasado cuando administraba entornos de desarrollo. No es particularmente de alta tecnología, pero es susceptible de control de versiones y compilaciones automatizadas, por lo que facilita el despliegue de un entorno a una versión específica, y mantener una gran cantidad de entornos es bastante práctico.

Mantener un repositorio central: este podría ser un conjunto de scripts de creación de bases de datos contenidos en un sistema de control de versiones, o un modelo de repositorio en una herramienta de modelado de datos. Elige tu opción. Este modelo debe tener un mecanismo de compilación que permita implementar un entorno desde los scripts sin mucha intervención manual.

Si tiene muchos datos de referencia, necesitará un mecanismo de carga para ello. Dependiendo de cómo desee hacerlo, puede guardar esto en una base de datos o en un conjunto de archivos. La ventaja de los archivos es que también se pueden versionar y etiquetar desde el mismo sistema de control de versiones que su código base. Un montón de archivos CSV y scripts de carga masiva en un repositorio de control de código fuente pueden hacer esto con bastante facilidad.

Una opción para implementar entornos de desarrollo es realizar copias de seguridad de la base de datos de producción parcheada en la versión adecuada y hacer que estén disponibles para que los desarrolladores las restauren en un entorno de desarrollo.

Facilite la implementación: al igual que cualquier proceso de compilación de CI, la base de datos debe desplegarse desde un solo script. Configúrelo para que las conexiones de la base de datos se puedan parametrizar, o el script es independiente de la ubicación y solo se puede ejecutar a través de la conexión.

Scripts de parches: necesitará revertir y probablemente revertir los scripts de cada versión lanzada.

Cree entornos de prueba a partir del modelo de repositorio: esto garantiza que el desarrollo en entornos que no estén sincronizados con el repositorio quede atrapado en las pruebas.

Pruebe el proceso de implementación: los scripts de parches automatizados, sin embargo, se crean deben ser comprobables. Las herramientas de comparación de esquemas son bastante buenas para esto, incluso si no las usa para generar los scripts de parche.

• Cree un entorno de referencia con la compilación del modelo de repositorio contra el que probó

• Cree un entorno de prueba de humo con una copia de seguridad de su versión de producción o una compilación basada en la versión lanzada actual.

• Ejecute el script de parche en el entorno de prueba de humo.

• Use la herramienta de comparación de esquemas para comparar el entorno de prueba de humo con el entorno de referencia. La secuencia de comandos del parche debe hacer que las dos bases de datos sean idénticas, por lo que puede investigar cualquier diferencia.

Lo que me gusta de este proceso

Esto es un poco pesado y fue diseñado para implementarse en entornos de producción bastante burocráticos y opacos. Sin embargo, tiene las siguientes fortalezas:

• Los desarrolladores pueden jugar donde lo necesitan.

• Se pueden acomodar múltiples ramas y flujos de desarrollo.

• Los scripts de implementación pueden probarse de manera repetible. Esto es muy útil para cerrar los enfrentamientos de despliegue, ya que se puede demostrar la repetibilidad.

• Las herramientas de comparación de esquemas proporcionan control de calidad en la implementación misma.

• Las pruebas siempre se realizan con respecto a lo que se espera que se publique, y esto detectará problemas derivados de entornos que no están sincronizados.

• La implementación basada en modelos de repositorio y scripts de parches significa que la basura no controlada no se migra accidentalmente de los entornos de desarrollo a la producción.

• Gran parte del proceso puede automatizarse, aunque a menudo es conveniente preparar y probar los scripts de parche de implementación manualmente.

• Los entornos son baratos y fáciles de implementar sin tener que saltar a través de aros.

• Los desarrolladores se ven obligados a crear un sistema que se adapte a un proceso simple de construcción e implementación.

• Los desarrolladores se ven obligados a aprender tareas básicas de administración de bases de datos, pero los entornos de prueba y producción están aislados de errores novatos.

Cómo aborda sus requisitos

1. Los desarrolladores tienen una copia local de datos para ejecutar el código de desarrollo.
   
   Los scripts de implementación o las imágenes de base de datos significan que pueden configurar un entorno desde cualquier versión que esté disponible.

2. Capaz de revertir la estructura de la base de datos a un conjunto de cambios anterior
   
   Nuevamente, ordenado por los scripts de implementación. Ya sea a través de DDL o imágenes de respaldo de la base de datos de prueba creadas a través de un proceso controlado, los desarrolladores pueden abrir un entorno para cualquier versión específica que tenga.

3. Capaz de separar los nuevos cambios de esquema de características frente a los cambios de corrección de diseño de esquema
   
   Los parches a una versión común se pueden mantener en una bifurcación separada en el árbol svn. Si las copias de seguridad de la base de datos se utilizan como entornos de referencia, deben almacenarse en algún lugar con la misma estructura de carpetas que la ramificación de los proyectos de control de origen.

4. Capaz de modificar la estructura de la base de datos localmente para realizar pruebas
   
   El sencillo proceso de implementación permite a los desarrolladores modificar y restaurar fácilmente un entorno a un estado local, o abrir un entorno de referencia para hacer comparaciones y realizar conjuntos de cambios.