¿Cómo administrar los cambios al esquema db en diferentes twigs cuando se usa db primero?

Tengo un proyecto de Entity Framework 5 DB-First, que recién estamos migrando de TFS a Git. En TFS mantuvimos la database actualizada usando SQL Source Control de RedGate, que era una buena forma de hacer las cosas, asumiendo que todos se desarrollan fuera de la troncal de todos modos porque la ramificación es muy difícil, así que casi todo el mundo está trabajando en la última versión del Esquema DB

Sin embargo, ahora que estamos en Git, me gustaría que los cambios de db se vuelvan parte de la twig de características. Dado que Git permite saltar tan fácil de una twig a otra, espero que los desarrolladores puedan pasar de las características que incluyen cambios de DB a las características sin esos cambios. El código se actualiza muy bien, pero ¿qué pasa con el DB? Dudo que el producto de RedGate maneje las migraciones de arriba hacia abajo en ese momento, ¿o estoy equivocado? Y si RedGate no puede manejar esas migraciones hacia arriba y hacia abajo, ¿cuál es la forma correcta de hacerlo en mi código?

Por cierto, sí busqué otras preguntas similares, y encontré esta , aunque la respuesta es include los scripts de migration en las twigs de características. Eso está muy bien para las migraciones "arriba", pero si estoy, por ejemplo, escribiendo una function en una twig, entonces cambio a otra twig para hacer una revisión del código de la request de extracción de otra persona, luego los cambios que realicé en mi el DB local en mi twig debería revertir de alguna manera. ¿Pero cómo?

ACTUALIZACIÓN: RedGate respondió a una llamada de soporte remitiéndome a este artículo . Básicamente, si desea cambiar de twig, tiene que desvincular / volver a vincular su database desde el control de fuente. Y no puedes crear o unir twigs. En resumen, ugh. ¿Alguna mejor sugerencia?

La mejor solución que he encontrado hasta ahora proviene de RedGate, su versión beta de Migrations V2 . Puede realizar sus confirmaciones en cada twig, y ​​cuando cambia de twig, "Obtenga lo último" en la pestaña Base de datos para actualizar su BD local al esquema de BD aplicable a esa twig.

Funciona bien en el 80% de los casos, pero no es (todavía) una solución perfecta

  • Si cambia las twigs a una versión anterior del esquema antes de una migration, no hay forma de ejecutar un script "inactivo".
  • El sistema se pone un poco defectuoso cuando tiene FILESTREAM habilitado. He informado esto a su soporte técnico y han reconocido el error, por lo que espero que esto se solucione pronto.

Básicamente, hay una razón por la cual se llama "Beta".

De todos modos, estoy marcando esto como la solución por ahora, pero si alguien tiene una mejor idea, escuchemos.

Un problema tedioso de hecho. Actualmente estoy usando carpetas separadas para cada twig principal (desarrollo, lanzamiento y mejora) lo que me obliga a hacer lo siguiente

  • Una database para cada twig principal
  • Cada twig principal está configurada para conectarse a la database correspondiente. Para testings unitarias y desarrollo en general
  • El server web está configurado para cada twig también. Por ejemplo, http: // localhost / develop

La fusión es un poco tediosa debido a los files de configuration, pero esta técnica ha funcionado durante algunos años hasta el momento.