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.Seguimiento y seguimiento de código y datos
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.
¿Por qué quieres migrar datos de dev para empujar? –
@sheepsimulator: muchos frameworks (por ejemplo, Magento, ATG, etc.) almacenan datos de configuración en la base de datos que necesitan ser portados para replicar el entorno dev/staging –