version-control - tag - svn trunk
¿Cómo gestionas las revisiones de la base de datos en un proyecto de tamaño medio con sucursales? (3)
Mantenemos todos nuestros scripts de base de datos (datos y esquema / ddl) en 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 un script 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 creado una pequeña utilidad interna que lee los cambios en el catálogo y crea un script de actualización grande basado en los contenidos del catálogo, tomando los contenidos de cada revisión en el catálogo y aplicándolos. El concepto es bastante similar a la herramienta DBDeploy , que creo que originalmente provino de Thoughtworks , por lo que es posible que pueda utilizarlo. Al menos le dará un buen lugar para comenzar, desde ese punto podrá personalizar una solución más adecuada a sus necesidades.
¡La mejor de las suertes!
En el trabajo, tenemos 4 personas trabajando juntas en algunos proyectos diferentes. Para cada proyecto, cada uno de nosotros tiene una copia local en la que trabajamos y luego hay un desarrollo, una puesta en escena y una implementación en vivo, junto con todas las ramas que tenemos (usamos subversión). Nuestra base de datos es MySQL.
Entonces mi pregunta es, ¿cuál es una buena manera de gestionar qué revisiones de la base de datos se han realizado para cada implementación (y para los desarrolladores sus copias locales). En este momento, cada cambio entra en un archivo de texto que tiene una marca de tiempo en el nombre y se coloca en una carpeta del proyecto. Esto no está funcionando muy bien para ser honesto. Necesito una solución que te ayude a hacer un seguimiento de lo que se aplicó.
http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx
El blog anterior nos trajo a nuestro sistema actual de control de versiones de la base de datos. En pocas palabras, no se realizan cambios en las bases de datos sin una secuencia de comandos 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 puede / desearí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 manualmente las actualizaciones de la base de datos, etc. Aunque esto puede llevar un poco de tiempo, pospuso parte del esfuerzo que un sistema totalmente automático hubiera requerido. Sin embargo, una cosa que automatizamos fue el seguimiento de la versión db en el software: esto fue bastante simple y garantiza que nuestro software conozca la base de datos contra la que se ejecuta y SÓLO se ejecutará si conoce el esquema con el que está trabajando.
La parte más difícil de nuestra solución fue cómo fusionar las actualizaciones de nuestras sucursales en nuestro baúl. Dedicamos un tiempo a desarrollar un flujo de trabajo para abordar la posibilidad de que dos desarrolladores intenten fusionar sucursales con actualizaciones de BD al mismo tiempo y cómo manejarlo. Finalmente nos decidimos por bloquear un archivo en control de versiones (el archivo en cuestión para nosotros es en realidad una versión de software de mapeo de tablas a db que ayuda en nuestra estrategia de administración manual), al igual que la sección crítica de un hilo y el desarrollador que obtiene la cerradura se ocupa de su actualización del maletero. Cuando se haya completado, el otro desarrollador podrá bloquear y es su responsabilidad hacer los cambios necesarios en sus scripts para garantizar que se eviten las colisiones de la versión esperada y otras malas juju.
Si su base de datos se corresponde perfectamente con un conjunto de objetos de acceso a datos, considere usar ''migraciones''. La idea es almacenar su modelo de datos como código de la aplicación con pasos para avanzar y retroceder en 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 .NET .
Para cambiar las versiones, ejecuta un script simple que recorre todas las versiones hacia arriba o hacia abajo para acceder a la versión que desea. Lo mejor de todo es que comprueba sus migraciones en el mismo repositorio de origen que el código de su aplicación; todo está en un solo lugar.
Quizás otros puedan sugerir otras bibliotecas de migración.
Aclamaciones.
Editar: Consulte también https://.com/questions/313/net-migrations-engine y el resumen de la herramienta de migración de base de datos .NET (de la publicación anterior).