¿Cómo administra las revisiones de la base de datos en un proyecto de tamaño mediano con sucursales?

Question

En el trabajo tenemos 4 personas trabajando juntas en varios proyectos diferentes. Para cada proyecto, cada uno tiene una copia local en la que trabajamos y luego hay un desarrollo, organización y despliegue en vivo, junto con cualquier sucursal que tengamos (usamos subversión). Nuestra base de datos es MySQL.

Entonces, mi pregunta es, ¿cuál es una buena forma de administrar qué revisiones de la base de datos se han realizado en cada implementación (y para los desarrolladores sus copias locales)? En este momento, cada cambio entra en un archivo de texto con la marca de tiempo del nombre y se coloca en una carpeta debajo del proyecto. Esto no funciona muy bien para ser honesto ... Necesito una solución que me ayude a mantener un registro de lo que se ha aplicado dónde.

Answer 1

Si su base de datos se asigna bien a un conjunto de objetos de acceso a datos, considere el uso de 'migraciones'. La idea es almacenar su modelo de datos como código de aplicación con pasos para avanzar y retroceder a través de cada versión de la base de datos.

Creo que Rails lo hizo primero .

Java tiene al menos un proyecto .

Y aquí hay una biblioteca de migración de .NET .

Para cambiar las versiones, ejecuta un script simple que recorre todas las versiones arriba o abajo para llegar a la versión que desea. La belleza de esto es que verifica sus migraciones en el mismo repositorio de origen que el código de su aplicación, todo está en un solo lugar.

Tal vez otros puedan sugerir otras bibliotecas de migración.

Saludos.

Editar: Consulte también https://stackoverflow.com/questions/313/net-migrations-engine y resumen de la herramienta de migración de base de datos .NET (desde la publicación anterior).

Answer 2

http://odetocode.com/Blogs/scott /archive/2008/01/30/11702.aspx

El blog anterior nos llevó a nuestro sistema de control de versiones de la base de datos actual. En pocas palabras, no se realizan cambios en la base de datos sin un script de actualización y todos los scripts de actualización se encuentran en nuestro repositorio de control de origen.

Solo administramos los cambios de esquema, pero también es posible que esté dispuesto a considerar mantener los volcados de sus datos disponibles en el control de versiones; crear tales archivos es un ejercicio bastante trivial usando mysqldump.

Nuestra solución difiere de la solución presentada en el blog de una manera clave: no es automática. Tenemos que aplicar las actualizaciones de la base de datos, etc. Aunque esto puede tomar un poco de tiempo, pospuso parte del esfuerzo que hubiera requerido un sistema completamente automatizado. Sin embargo, una cosa que sí automatizamos fue el seguimiento de la versión db en el software: fue bastante simple y garantiza que nuestro software esté al tanto de la base de datos con la que se está ejecutando y SOLAMENTE se ejecutará si conoce el esquema con el que está trabajando.

La parte más difícil de nuestra solución fue cómo combinar las actualizaciones de nuestras sucursales en nuestro tronco. Pasamos un poco de tiempo para desarrollar un flujo de trabajo para abordar la posibilidad de que dos desarrolladores intenten combinar sucursales con las actualizaciones de DB al mismo tiempo y cómo manejarlas. Finalmente, decidimos bloquear un archivo en el control de versiones (el archivo en cuestión para nosotros es en realidad una versión del software de mapeo de tablas para la versión de base de datos que ayuda en nuestra estrategia de administración manual), como lo haría con la sección crítica de un hilo, y el desarrollador que recibe La cerradura va sobre su actualización del maletero. Una vez completado, el otro desarrollador podrá bloquear y es su responsabilidad realizar los cambios necesarios en sus scripts para garantizar que se eviten las colisiones de versión esperadas y otros juju malos.

Answer 3

Mantenemos todos nuestros scripts de base de datos (datos y esquema / ddl) en el control de versiones. También mantenemos un catálogo central de los cambios. Cuando un desarrollador realiza un cambio en un archivo de esquema / DDL o agrega una secuencia de comandos que cambia los datos de alguna manera, esos archivos se agregan al catálogo, junto con el número de confirmación de SVN.

Hemos reunido una pequeña utilidad interna que lee los cambios del catálogo y crea un gran script de actualización basado en el contenido del catálogo al tomar el contenido de cada revisión en el catálogo y aplicarlos. El concepto es bastante similar a la herramienta DBDeploy , que creo que originalmente provenía de Thoughtworks , por lo que es posible que pueda utilizarlo. Al menos le dará un buen punto de partida, desde el cual podrá personalizar una solución que se adapte más a sus necesidades.

¡Mucha suerte!