TFS bifurcación y bases de datos

Question

Tengo un proyecto en el que tenemos que configurar una estrategia de bifurcación simple para permitir el desarrollo de nuevas características sin dejar de corregir errores en otra rama.

El problema que estoy teniendo es con las bases de datos.

El esquema de la base de datos es parte de TFS como un proyecto de base de datos, pero para tener suficientes datos de prueba en un punto tomamos una copia de seguridad de una base de datos en vivo y la usamos para probar durante el desarrollo.

Actualmente las bases de datos (árbol en total) están ubicadas en un servidor de grupo de trabajo con un conjunto de bases de datos para cada desarrollador, y cada conjunto de bases de datos se actualiza de vez en cuando con scripts sql que los otros desarrolladores crean cuando cambian el esquema .

Mi pregunta es: ¿Cómo podemos reorganizar esto para que cada rama sea autónoma y podamos cambiar fácilmente de una rama a otra? Ya he analizado el uso de SQL Express y la colocación de las bases de datos dentro de la rama, pero esto no funcionó bien. También hemos buscado crear scripts con todos los datos y reconstruir la base de datos desde la base de datos, pero esto tomó demasiado tiempo, y algunos desarrolladores tendieron a olvidarse de hacerlo con la suficiente frecuencia.

¿Alguna idea?

Answer 1

Visual studio admite database projects. Úselo y luego, con suerte, la bifurcación será relativamente sencilla.

Puede restaurar una copia de seguridad de la base de datos y luego usar GDR para sincronizar/actualizar su esquema de base de datos. Necesitarás guiar los cambios de datos.

Requiere un poco de esfuerzo inicial de configuración.

• VSTS DB Team Blog

• Visual Studio TFS Branching and Merging Guidance

• Visual Studio Team Foundation Server Branching and Merging Guide

Answer 2

proyectos de bases de datos de Visual Studio no son la herramienta óptima para soportar actualizaciones de bases de datos, mientras que la preservación de datos.

Puede ser útil reconsiderar la relación entre las nuevas instalaciones y las actualizaciones. Para muchas empresas, las actualizaciones son una ocurrencia tardía y las secuencias de comandos de actualización se crean en función de los deltas de los nuevos scripts de instalación. Esto conduce a mantenimiento duplicado, inconsistencia y gran dependencia de los detalles del esquema "actual" en la ruta de actualización.

Me gustaría, por tanto, recomendar

• mantener solamente actualizar las secuencias de comandos (con excepciones donde se prefiere el código fuente declarativa y refresca completos son posibles sobre cada actualización)
• decidir si desea o no tener que soportar las rebajas
• garantizar a nivel de infraestructura que cada script de actualización se aplica como máximo una vez
• básicamente nunca edite una secuencia de comandos de actualización, intente seguir añadiendo nuevas al final de la secuencia de solicitud

Es un cambio bastante invasivo, y requiere un cambio de mentalidad, por lo que primero debe evaluar sus necesidades de actualización a largo plazo. Una indicación de que necesita pasar por el cambio es una expectativa de mucho desarrollo paralelo o mantenimiento en múltiples ramas de lanzamiento y desarrollo.