Cómo gestionar los cambios en el esquema de la base de datos en versiones de proyectos de código abierto

Administro una aplicación web PHP / MySQL de código abierto utilizada por algunas escuelas K-12 y algunas universidades. También soy el único desarrollador del proyecto. Si bien solía ser poco más que una descarga de origen de una aplicación que aloja mi empleador, he trabajado durante el último año para convertirlo en un proyecto de código abierto "real", con documentación, lanzamientos numerados, registros de cambios públicos, etc.

Estoy buscando mejorar el proceso de actualización, y una de las áreas potencialmente dolorosas (especialmente para las escuelas hambrientas de experiencia en TI) está en los cambios en el esquema de la base de datos entre versiones. No suelen ocurrir con frecuencia ni son cambios drásticos, pero agradecería sugerencias sobre el proceso.

Actualmente, mantengo un script de instalación SQL base para configurar la base de datos en una nueva instalación. Esto incluye el esquema completo para la versión actual; No se requiere ninguna otra acción para una nueva instalación. Los cambios que ocurren entre versiones se almacenan en upgrade-$releasever.sqlscripts, y es necesario ejecutar todos los scripts de actualización de forma incremental para cualquier versión que se haya omitido.

Los scripts de shell no se ajustan bien, porque muchos de nuestros usuarios operan en hosts sin acceso a shell. Debido a otras prioridades, es poco probable que se materialice un complejo instalador / script de actualización basado en navegador PHP. Sin embargo, me gustaría hacer algo con un script PHP basado en navegador para simplificar las actualizaciones. ¿Sugerencias sobre cómo abordarlo?

Mi proyecto tiene un archivo update.php que el usuario ejecuta a través de su navegador después de haber instalado una nueva versión del software. Ese script de actualización verifica un número de versión de la base de datos que se mantiene en una tabla en la base de datos activa y realiza cualquier operación de alteración de la base de datos que llevará ese esquema de la base de datos hasta el último, que incluye actualizar ese número de versión de la base de datos.

Drupal CMS tiene una solución interesante para su problema. Sugiero echar un vistazo a Drupal en general, si está desarrollando soluciones basadas en la web utilizando PHP. Es mi CMS PHP favorito y estaré lo suficientemente sesgado como para decir que es el mejor que existe. ;)

Drupal ofrece un envoltorio de interacción de base de datos bastante sofisticado. Permite abstraer el tipo de base de datos real del desarrollador del módulo, por lo que realmente no le importa si el servidor ejecuta PostgreSQL, MySQL, etc. También puede crear su propia interfaz. Se requiere que cada módulo proporcione el archivo module.install que contiene hook_schemay hook_install. hook_schemase usa para declarar el esquema de tabla para el módulo, mientras se hook_installejecuta el procedimiento de instalación. La arquitectura también admite la noción de actualizaciones, por lo que si el usuario ya tiene el módulo instalado, se invocan los ganchos de actualización correctos y permiten actualizar fácilmente el esquema de la tabla.

Echa un vistazo: http://drupal.org/node/146862 Incluso si Drupal no es para ti, estoy seguro de que puedes aprender algo de sus decisiones arquitectónicas.

Lo hicimos creando carpetas de versiones. Colocamos todos los scripts de la base de datos en esa carpeta. Cuando llegó el momento de lanzar esto a un nuevo cliente, obtuvieron la última versión.

También guardamos los scripts de actualización en esta carpeta. De esa forma podríamos migrar un cliente de la versión x a la versión y.

No es el mejor método ... pero funcionó para nosotros.