la gestión del cambio de base de datos y el proceso de construir utilizando TFS [cerrada]

Question

Cualquier persona utilizando Team Foundation Server para gestionar sus bases de datos? Actualmente estamos utilizando la subversión. Equipo se queja de que es difícil crear un proceso de generación de TFS y está renunciando a él.

Cualquier buenos consejos, artículos, experiencias?

Answer 1

DB gestión del cambio no tiene mucho que ver con la elección de los sistemas de control de versiones, siempre y cuando usted tiene uno en el primer lugar. Por supuesto, si usted está usando herramientas de gestión del cambio de MS puede estar completamente seguro de que han sido probados contra TFS y el resto de la pila desarrollador MS bastante bien. Eso es cierto si se utiliza DBPro o las formas mucho más antiguas / crappier de integración se ven en el "proyecto de base de datos" clásico VS o en los enlaces de proyecto simplificada / solución de SQL Management Studio. Pero no hay ninguna razón por la que no se puede utilizar DBPro con Subversion, o Puerta roja con TFS para el caso.

Lo mismo va para la generación de acumulación. CC.NET vs equipo de construcción, de NAnt vs MSBuild, etc ... las herramientas oficiales MS tienden a ser más o menos a la par con la competencia. No ha descrito el proceso de implementación DB con mucho detalle, pero no puedo imaginar que sería mucho más difícil programar en MSBuild que lo que se está utilizando ahora, en todo caso. Tampoco es difícil elegir diferentes conjuntos de herramientas en diferentes puntos de la pila: se puede tener a base de MSBuild unidad CC.NET construcciones que utilizan despliegue de línea de comandos de Red Gate, o cualquier otra combinación. Sucede que creo que la estrecha integración ofrecido por pegar al mundo MS es mucho mayor que las peculiaridades de cualquier herramienta, pero la opción está ahí.

A ver si al grano: Parece que su principal problema no es técnico, pero conseguir que los administradores de bases de adoptar realmente el control de versiones en el primer lugar. Si su "dev" y "entornos prod" son sus propias entidades vivientes, en lugar de máquinas genéricas define exclusivamente por el resultado de un proceso de construcción repetible, entonces usted no está realmente utilizando el control de versiones en mi libro . Imagínese si un desarrollador de cliente de vez en cuando a mano ajustado las DLL en varias máquinas alrededor de la empresa, a continuación, se quejó de que eran demasiado duro para sincronizar; se podría pensar que estaba loco.

Más allá de eso, la inversión más importante es llegar a un lugar donde nada se hace para una base de datos directamente (más de lo que cabría hurgar en% ProgramFiles%). Si no está en el repositorio de código fuente, que no existe.

No creo que la forma de llegar allí es tan importante. Se podría escribir toda su crea y modifica en el Bloc de notas, los comprueba a partir de la línea de comandos, y que su "proceso de construcción" ser una secuencia de comandos shell de 2 líneas que los concatena en un archivo conocido, donde la secuencia de comandos de despliegue sabe buscar . O puede utilizar una herramienta de lujo como DBPro para amplificar su productividad con IntelliSense / unidad de prueba en línea de modelado / / etc Hay buenas razones para la cabeza en la última dirección (especialmente si usted cree programación declarativa es algo que buscan en general), pero realmente creo que la primera paso es el más grande.

Answer 2

Estamos utilizando Visual Studio 2008 Team Suite junto con TFS. Yo era capaz de importar nuestras bases de datos en TFS con relativa facilidad. Sin embargo, he encontrado que la mayoría del equipo (incluyendo el DBA) se olvida de actualizar TFS cuando modifican un objeto en SQL.

Cualquier tipo de proceso de construcción va a depender de DB Pro para generar secuencias de comandos de diferencia entre su entorno de desarrollo y el entorno de destino. He encontrado que esto es problemático porque nuestro entorno de desarrollo no es un partido limpio en nuestro entorno de producción. Los permisos son ciertamente diferentes y tenemos un número de otros casos en que se aplicaron los cambios en dev / QA, pero no se movió a prod (pero también nunca fueron invertidos). Intentando aislar los cambios de una gran cantidad de otros cambios en DB Pro es un reto, ya que la interfaz de usuario hace que se excluya objetos del guión final (por lo que si modifica 2 objetos y otros 1000 son diferentes, hay que desmarcar los otros 1.000 objetos). Además, la configuración de la comparación de esquemas se hace a menudo en Herramientas-> Opciones mientras que otras herramientas como Red Gate le permiten configurar la comparación en la misma pantalla que se inicia.

Creo que la herramienta tiene potencial, pero sin duda tenemos que adaptar nuestros procedimientos y sistemas existentes para trabajar con TFS. Además, tener el control de versiones de sus objetos de base es muy valiosa, incluso si no es del 100% hasta la fecha.

Answer 3

Utilizamos TFS con la edición de base de datos.

El script de creación de base de datos tiene guiones postales Para cargar los datos en la base de datos Dev.

Lo hacemos despliega regulares al entorno de desarrollo. Todos los desarrolladores han instalado SQL localmente y hacer su propia Obtener la última y desplegar.

En el entorno de prueba de unidad, los inicios de sesión, Bases de Datos (OLTP y OLAP), replicación, paquetes ETL, SQL Jobs, etc, todos ellos desplegados en sus ubicaciones individuales y todo lo que se siembra.

Los desarrolladores no realizar ningún cambio fuera y no comprueban en porque entonces el despliegue de probar la unidad no funciona.

Answer 4

Hay mucho más en esta opinión en esta cuestión desbordamiento de pila: ¿Cuáles son los beneficios reales de visual Studio Team System Database Edition (RDA)? (No sé por qué, pero mis búsquedas me trajo a esta pregunta en su lugar, y he tenido un montón de problemas para encontrar opiniones sobre esto. Con suerte este enlace ayudará a otros que realizan la misma búsqueda.)