Cualquiera que use SQL Source Control desde Red Gate

Question

Hemos estado buscando posibles soluciones para nuestro control de fuente SQL. Me encontré con el control de origen SQL de Red Gates y me pregunté si alguien lo había implementado. Voy a descargar la versión de prueba y darle una oportunidad, pero solo quería ver si otros tienen una experiencia real.

Como siempre aprecian en gran medida la entrada de

-S

Answer 1

que utiliza SQL Compare para generar secuencias de comandos cuando se pasa de dev -> prueba -> producción y me ahorra un montón de tiempo.

Para control de fuente, sin embargo, usamos SVN y ScriptDB (http://scriptdb.codeplex.com/). Utilizo principalmente el control de fuente de scripts SQL para hacer un seguimiento de los cambios. Creo que rara vez funciona una versión de la base de datos, ya que los datos pueden haber cambiado al hacer cambios en la estructura.

Esto funciona bien para algunos de nuestros proyectos actuales (el más grande es 200 tablas y 2000 sprocs). Sin embargo, la razón principal para hacer esto es el costo, ya que no todos los miembros del equipo tienen que comprar SQL Compare (evito agregar dependencias a proyectos comerciales a menos que realmente lo necesiten).

Answer 2

Realizamos una evaluación exhaustiva del producto de Red Gate y encontramos algunos fallos importantes. Si desea ver quién cambió un objeto, no puede hacerlo sin privilegios de SysAdmin. El producto necesita ver el rastreo en su servidor, que requiere esos derechos. Estoy en un equipo de más de 5 personas, y no saber quién tenía cambios pendientes es lo que nos impedirá usar el producto.

Answer 3

He actualizado mi publicación original a continuación para reflejar los cambios en las últimas versiones de SQL Source Control (3.0) y SQL Compare (10.1).

Dado que esta pregunta se formuló hace más de un año, mi respuesta puede no ser de ayuda para usted, pero para otras personas que actualmente están evaluando SSC, pensé que podría dar mis dos centavos. Recién comenzamos a utilizar SQL Source Control (SSC) y, en general, estoy bastante satisfecho con él hasta el momento. Sin embargo, tiene algunas peculiaridades, especialmente si trabaja en un entorno de base de datos compartido (en oposición a cada desarrollador que trabaja localmente) y particularmente trabajando en un entorno heredado donde los objetos en la misma base de datos se dividen aleatoriamente entre los equipos de desarrollo.

Para dar una breve descripción de cómo estamos utilizando el producto en nuestra organización, trabajamos en un entorno compartido donde todos hacemos cambios en la misma base de datos de desarrollo, así que adjuntamos la base de datos compartida al repositorio de control de origen. Cada desarrollador es responsable de realizar cambios en los objetos de la base de datos a través de SQL Server Management Studio (SSMS), y cuando finalizan, pueden enviar sus cambios al control de origen. Cuando estamos listos para implementar en etapas, el maestro de compilación (yo) fusiona la rama de desarrollo del código de la base de datos con la rama principal (en etapas) y luego ejecuta la comparación de SQL utilizando la versión de repositorio de la rama principal de la base de datos como fuente y la base de datos de etapas como el objetivo y SQL Compare genera las secuencias de comandos necesarias para implementar los cambios realizados en el entorno de transición. La etapa de implementación de producción funciona de manera similar. Otro punto importante a tener en cuenta es que, dado que compartimos la misma base de datos con otros equipos de desarrollo, utilizamos una función incorporada de SSC que le permite crear filtros en los objetos de la base de datos por nombre, tipo, etc. configurar filtros en los objetos de nuestro equipo específico, excluyendo todos los demás objetos, de modo que no comprometamos accidentalmente los cambios de otros equipos de desarrollo cuando hacemos nuestras implementaciones.

Por lo tanto, en general es un producto bastante simple de configurar y usar y es realmente bueno porque siempre está trabajando con objetos en vivo en SSMS, en lugar de archivos de script desconectados almacenados en un repositorio de origen separado que corre el riesgo de fuera de sincronización. También es bueno porque SQL Compare genera los scripts de implementación para que no tenga que preocuparse por introducir errores como lo haría si estuviera creando los scripts por su cuenta. Y como SQL Compare es un producto muy maduro y estable, puede sentirse bastante seguro de que creará los scripts adecuados para usted.

Con eso se dice, sin embargo, aquí están algunas de las peculiaridades que se han topado hasta el momento:

• SSC es bastante hablador fuera de la caja en cuanto a la comunicación con el servidor db con el fin de realizar un seguimiento de los elementos de la base de datos que no están sincronizados con el repositorio de control de origen. Realiza sondeos cada pocos milisegundos y si agrega varios desarrolladores trabajando todos contra la misma base de datos utilizando SSC, puede imaginarse que nuestros dba no estaban muy contentos. Afortunadamente, puede reducir fácilmente su frecuencia de sondeo a algo más aceptable, aunque a costa de sacrificar las notificaciones visuales receptivas de cuándo se han cambiado los objetos.
• Al utilizar la función de filtrado de objetos, no se puede ver fácilmente, al mirar los objetos en SSMS, qué objetos están incluidos en su filtro. Por lo tanto, no está seguro de si un objeto está bajo control de código fuente, a diferencia de Visual Studio, donde los iconos se utilizan para indicar objetos controlados por origen.
• La GUI de filtrado de objetos es muy torpe. Debido al hecho de que estamos trabajando en un entorno de base de datos heredado, actualmente no existe una separación clara entre los objetos que nuestro equipo posee y los de otros equipos, para evitar que accidentalmente confirmemos/implementemos los cambios de otros equipos. , hemos configurado un esquema de filtrado para incluir explícitamente cada objeto específico que poseemos. Como se puede imaginar, esto se vuelve bastante engorroso, y como la GUI para editar los filtros está configurada para ingresar un objeto a la vez, podría ser bastante doloroso, especialmente tratar de configurar su entorno por primera vez (terminé escribiendo una aplicación para hacer esto). En el futuro, estamos creando un nuevo esquema para nuestra aplicación para facilitar el filtrado de objetos (además de ser una mejor práctica de todos modos).
• Utilizando el modelo de base de datos compartida, los desarrolladores pueden confirmar cualquier cambio pendiente en una base de datos controlada por fuente, incluso si los cambios no son suyos. SSC te da una advertencia si intentas ver un montón de cambios que estos cambios pueden no ser tuyos, pero aparte de eso, estás solo. De hecho, creo que esta es una de las "peculiaridades" más peligrosas de SSC.
• SQL Compare actualmente no puede compartir los filtros de objetos creados por SSC, por lo que tendría que crear manualmente un filtro que coincida en SQL Compare, por lo que existe el peligro de que estos no puedan sincronizarse. Acabo cortando y pegando los filtros del archivo de filtro SSC subyacente en el filtro del proyecto SQL Compare para evitar lidiar con la gruesa GUI de filtrado de objetos. Creo que la próxima versión de SQL Compare le permitirá compartir filtros con SSC, por lo que al menos este problema es de corto plazo. (NOTA: Este problema se ha resuelto en la última versión de SQL Compare. SQL Compare ahora puede usar los filtros de objetos creados por SSC.)
• SQL Compare también no se puede comparar con un repositorio de base de datos SSC cuando se inicia directamente. Tiene que ser lanzado desde SSMS. Creo que la próxima versión de SQL Compare proporcionará esta funcionalidad, así que de nuevo es otro problema a corto plazo. (NOTA: Este problema se ha resuelto en la última versión de SQL Compare).
• A veces SQL Compare no puede crear los scripts adecuados para obtener la base de datos de destino de un estado a otro, generalmente en el caso donde está actualizando el esquema de tablas existentes que no están vacías, por lo que actualmente tiene que escribir scripts manuales y administrar el proceso usted mismo.Afortunadamente, esto se abordará a través de "scripts de migración" en la próxima versión de SSC, y al observar la versión de lanzamiento anticipado del producto, parece que la implementación de esta nueva característica fue bien pensada y diseñada. (NOTA: la funcionalidad de scripts de migración se ha lanzado oficialmente. Sin embargo, actualmente no es compatible con la bifurcación. Si desea usar scripts de migración, deberá ejecutar la comparación sql en comparación con su bifurcación de código de desarrollo original ... la que verificó en sus cambios ... que es bastante torpe y me ha obligado a modificar mi proceso de construcción de una manera menos que ideal para evitar esta limitación. Espero que esto se aborde en una versión futura.)

En general, estoy muy contento con el producto y con la capacidad de respuesta de Redgate a los comentarios de los usuarios y la dirección que está tomando el producto. El producto es muy fácil de usar y está bien diseñado, y creo que en la próxima versión o dos el producto probablemente nos dará la mayoría, si no la totalidad, de lo que necesitamos.