Seguimiento y seguimiento de código y datos

Question

Durante mucho tiempo, hemos almacenado nuestros datos en el repositorio del proyecto. Simplemente mantuvimos todo bajo data/sql, y cada tabla tenía sus propios archivos create_tablename.sql y data_tablename.sql.

Acabamos de implementar nuestro segundo proyecto en Scalr y nos hemos dado cuenta de que es un poco complicado.

La forma en que desplegar:

Tenemos una colección "packageup" de scripts que desgarran el proyecto en 3 archivos (datos, código, archivos estáticos) que a su vez los que almacenamos en 3 cubos separados en S3.

Cada vez que se inicia una función, descarga uno de los archivos (según el rol: datos, nfs o web) y luego un guión "desempaquetar" configura todo para cada función, carga los datos en mysql, configura nfs, etc.

Lo hacemos así porque no queremos guardar imágenes de servidor, siempre partimos de instancias de vanilla en las que instalamos todo desde cero utilizando varios scripts internos. El tiempo de inicio no es un problema (tenemos una granja lista para usar en 9 minutos).

El problema es que es un dolor tratar de encontrar la versión correcta de la base de datos cada vez que intentamos configurar una nueva compilación de desarrollo (en cualquier punto del tiempo, tenemos aproximadamente 4 compilaciones de desarrollo para un proyecto). Además, git está empezando a ahogarse una vez que entramos en producción, ya que los archivos sql terminan por un total de alrededor de 500mb.

La pregunta es:

¿Cómo está todo el mundo administrar bases de datos? He estado buscando algo que hace que sea fácil sacar datos de la producción en dev y también migrar datos del desarrollador a la producción, pero no he tropezado con nada.

Answer 1

Debería echarle un vistazo a dbdeploy (dbdeploy.com). Está portado a muchos idiomas, los principales son Java y PHP.Está integrado en herramientas de desarrollo como Ant y Phing, y permite compartir fácilmente los llamados archivos delta.

Un archivo delta siempre consta de una sección de despliegue, pero también puede contener una sección de deshacer. Cuando compromete su archivo delta y otro desarrollador lo comprueba, puede ejecutar dbdeploy y todos los cambios nuevos se aplican automáticamente a su base de datos.

estoy usando dbdeploy para mi blog de código abierto, por lo que puedo echar un vistazo a cómo los archivos se organizan delta: http://site.svn.dasprids.de/trunk/sql/deltas/

Answer 2

Consulte capistrano. Es una herramienta que usa la comunidad de ruby ​​para su implementación en diferentes entornos y la encuentro realmente útil.

Además, si su implementación está empezando a ahogarse intente con una herramienta de twitter llamada llamada Murder.

Answer 3

Cómo entiendo que su principal pregunta es la experiencia de otras personas en la migración de datos SQL del desarrollador a la producción.

Uso Microsoft SQL Server en lugar de My SQL, por lo que no estoy seguro de que mi expirience se pueda usar directamente. Sin embargo, esta forma funciona muy bien.

Uso Visual Studio 2010 Ultimate edition para comparar datos en dos bases de datos. La misma característica existe también en Vinsual Studio Team Edition 2008 (o edición de base de datos). Puede leer http://msdn.microsoft.com/en-us/library/dd193261.aspx para entender cómo funciona. Puede comparar dos bases de datos (dev y prod) y generar SQL Script para modificar los datos. Puede fácilmente excluir algunas tablas o algunas columnas de la comparación. También puede examinar los resultados y excluir algunas entradas de la generación del script. Por lo tanto, uno puede generar scripts de forma fácil y flexible que se puedan utilizar para el despliegue de los cambios en la base de datos. Puede comparar por separado los datos de dos bases de datos de la estructura (comparación de esquemas). De modo que puede actualizar datos en dev con los datos de prod o generar scripts que modifiquen la base de datos prod a la última versión de la base de datos dev. Te recomiendo que veas estas características y algunos productos de http://www.red-gate.com/ (como http://www.red-gate.com/products/SQL_Compare/index.htm).

Answer 4

Personalmente me vería en sapo

http://www.toadworld.com/

Menos de 10k;) ... analizará las estructuras de la base de datos, producirá scripts para modificarlos y también migrará los datos.

Answer 5

Una parte de la solución es capturar la versión de cada uno de los módulos de código y sus recursos de datos correspondientes en una única ubicación, y compararlos para garantizar la coherencia. Por ejemplo, un incremento en el número de versión de su, por ejemplo, customer_comments módulo requerirá un archivo delta SQL correspondiente para actualizar las tablas de base de datos pertinentes al número de versión igual para los datos.

Por ejemplo, eche un vistazo a core_resource de Magento approach según lo documentado por @AlanStorm.

Saludos, JD