deployment - Codificación y seguimiento/implementación de datos
cloud database-management (5)
Durante mucho tiempo, hemos retenido 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.
Ahora hemos implementado nuestro segundo proyecto en Scalr y nos hemos dado cuenta de que es un poco complicado.
La forma en que implementamos:
Tenemos una colección de "paquetes" de scripts que desgarran el proyecto en 3 archivos (datos, código, archivos estáticos) que luego almacenamos en 3 sectores diferentes 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 una secuencia de comandos "desempaquetar" configura todo para cada rol, carga los datos en mysql, configura el nfs, etc. .
Lo hacemos así porque no queremos guardar imágenes de servidor, siempre partimos de instancias estándar 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 versión de desarrollo (en cualquier momento, 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án todos los demás administrando las bases de datos? He estado buscando algo que facilite sacar los datos de la producción a dev y también migrar datos del desarrollador a la producción, pero no he tropezado con nada.
Echa un vistazo a 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 estrangular intente con una herramienta de twitter llamada Asesinato .
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.
Utilizo Microsoft SQL Server en lugar de My SQL, así que no estoy seguro de que mi expirience se pueda usar directamente. Sin embargo, esta forma funciona muy bien.
Uso la edición Visual Studio 2010 Ultimate 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 comprender 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 ).
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 consiste en 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, para que pueda ver cómo se organizan los archivos delta: http://site.svn.dasprids.de/trunk/sql/deltas/
Personalmente, miraría a Sapo
Menos de 10k;) ... analizará las estructuras de la base de datos, producirá scripts para modificarlos y también migrará los datos.
Una parte de la solución es capturar la versión de cada uno de los módulos de código y los recursos de datos correspondientes en una sola ubicación, y compararlos para garantizar la coherencia. Por ejemplo, un incremento en el número de versión de su módulo, por ejemplo, customer_comments 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 al enfoque core_resource de Magento según lo documentado por @AlanStorm.
Cheers, JD