PHP – Esquema de la database: control de versiones, bifurcaciones, migraciones

Estoy tratando de encontrar (o encontrar) un sistema reutilizable para el control de versiones de esquema de bases de datos en proyectos php.

Hay una serie de proyectos de migration estilo Rails disponibles para php. http://code.google.com/p/mysql-php-migrations/ es un buen ejemplo. Utiliza marcas de time para files de migration, lo que ayuda con los conflictos entre sucursales.

Problema general con este tipo de sistema: cuando la twig de desarrollo A está desprotegida, y desea verificar la twig B en su lugar, B puede tener nuevos files de migration. Esto está bien, migrar a un contenido más nuevo es sencillo.

Si la twig A tiene files de migration más nuevos, deberá migrar hacia abajo al parche compartido más cercano. Si las twigs A y B tienen bases de código significativamente diferentes, es posible que deba migrar aún más. Esto puede significar: Verifique B, determine el número de parche compartido, revise A, migre hacia abajo a este parche. Esto debe hacerse desde A, ya que los parches reales aplicados no están disponibles en B. Luego, revise la twig B y migre al parche B más reciente. Invierta nuevamente el process cuando va de B a A.

Sistema propuesto: cuando migre hacia arriba, en lugar de simplemente almacenar la versión del parche, serialice todo el parche en la database para usarlo más adelante, aunque probablemente solo necesite el método down (). Al cambiar las twigs, compare las revisiones que se han ejecutado con parches que están disponibles en la sucursal de destino. Determine el parche compartido más cercano (o la diferencia más antigua, tal vez) entre la tabla db de los parches de ejecución y los parches en la sucursal de destino por ID o hash. También podría search parches nuevos o faltantes que están ocultos debajo de una serie de parches compartidos entre las dos twigs.

Combínelo automáticamente con el parche compartido más cercano, utilizando los methods almacenados de la tabla db down (), y luego fusione hasta el último parche de la twig.

Mi pregunta es: ¿este sistema está demasiado loco y / o cargado de consecuencias para molestarse en desarrollarse? Mi experiencia con el control de versiones de esquema de database está limitada a PHP autopatch, que es un sistema up () – only que requiere nombres de file con identificadores secuenciales.

Actualización, 2 años después

Esta es una publicación anterior, pero quería mencionar que he abandonado las migraciones en general durante el desarrollo, ya que son innecesariamente complicadas y propensas a errores.

En cambio, utilizo scripts de compilation para:

  1. borrar la database,
  2. crea el esquema,
  3. agregar datos de aplicaciones conocidas (contenido real) y
  4. agregar datos del accesorio (contenido de desarrollo).

Al cambiar twigs, o recibir actualizaciones de otros desarrolladores, recarga la database completamente con un command para llegar a un estado conocido.

Los serveres de producción aún necesitan parches de database, pero deberían crearse manualmente de todos modos.

Bueno, no pude encontrar ninguna razón para no seguir adelante.

El proyecto, tal como es, está aquí:

http://github.com/Billiam/MySQL-PHP-AutoMigrations

Necesita un poco de amor (comentarios precisos, testings unitarias, testings de errores reales), pero parece estar funcionando bien para mí ahora.

Es una bifurcación de http://code.google.com/p/mysql-php-migrations/ para include las ideas anteriores y algunas otras cosas pequeñas.

La migration hacia abajo se realiza desde methods guardados en la database en el path ascendente para que los cambios de files (como los que se realizan al cambiar de una twig a otra) no afecten a las migraciones descendentes. Agregó dos funciones:

  • una function mágica 'automática' que maneja la migration a la migration compartida más antigua y luego a la migration más reciente en el directory de migraciones.
  • function 'proponer' que muestra lo que realmente hará el auto.

Sin embargo, sigue siendo muy abierto para escuchar las trampas potenciales (o incluso esperadas) de este enfoque.

Intereting Posts