source - Cualquiera que use el control de fuente SQL de Red Gate

sql source control free (4)

Hemos estado buscando posibles soluciones para nuestro control de fuente SQL. Acabo de encontrar el control de Red Gates SQL Source y me pregunto si alguien lo ha implementado. Voy a descargar la versión de prueba y probarla, pero solo quería ver si otros tienen experiencia real.

Como siempre apreciamos mucho la entrada.

--S

Acabo de empezar a trabajar para una nueva empresa y usan el control de código fuente de Redgate SQL para todos sus proyectos, entre ellos uno grande y complejo. Hace el trabajo bien junto con TFS. El único inconveniente desde mi punto de vista es que la integración de SQL Server Management Studio es altamente inestable. Los bloqueos frecuentes de SQL Server Management Studio ocurren cuando se instalan las herramientas.

Realizamos una evaluación exhaustiva del producto de Red Gate y encontramos algunas fallas importantes. Si desea ver quién cambió un objeto, no puede hacerlo sin los privilegios de SysAdmin. El producto debe ver la traza en su servidor, que requiere esos derechos. Estoy en un equipo de más de 5 personas, y no saber quién tuvo cambios pendientes es lo que nos impedirá usar el producto.

Uso la Comparación de SQL para generar scripts cuando se pasa de dev -> test -> production y me ahorra muchísimo tiempo.

Sin embargo, para el control de origen, usamos SVN y ScriptDB ( http://scriptdb.codeplex.com/ ). Utilizo principalmente el control de código fuente de los scripts SQL para realizar un seguimiento de los cambios. Creo que revertir una versión de la base de datos rara vez (si es que alguna) funciona, ya que los datos pueden haber cambiado al realizar cambios en la estructura.

Esto funciona bien para algunos de nuestros proyectos actuales (el más grande es de 200 mesas 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 la Comparación de SQL (Evito agregar dependencias a proyectos comerciales a menos que sea realmente necesario).

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).

Debido a que esta pregunta se realizó hace más de un año, mi respuesta puede no serle de ayuda, pero para otras personas que actualmente están evaluando el SSC, pensé que le daría mis dos centavos. Acabamos de comenzar a usar el control de fuente SQL (SSC) y, en general, estoy bastante satisfecho con él hasta ahora. Sin embargo, tiene algunas peculiaridades, especialmente si está trabajando en un entorno de base de datos compartido (a diferencia de todos los desarrolladores que trabajan localmente) y, particularmente, en un entorno heredado donde los objetos en la misma base de datos se dividen al azar entre los equipos de desarrollo.

Para ofrecer una breve descripción general de cómo estamos utilizando el producto en nuestra organización, estamos trabajando en un entorno compartido donde todos hacemos cambios en la misma base de datos de desarrollo, por lo que adjuntamos la base de datos compartida al repositorio de control de origen. Cada desarrollador es responsable de realizar cambios en los objetos en la base de datos a través de SQL Server Management Studio (SSMS), y cuando terminen, pueden enviar sus cambios al control de origen. Cuando estamos listos para desplegar a la puesta en escena, el maestro de compilación (yo) combina la rama de desarrollo del código de la base de datos con la rama principal (de la etapa) y luego ejecuta la Comparación de SQL usando la versión del repositorio de la rama principal de la base de datos como la fuente y la fuente La base de datos provisional como destino, y SQL Compare genera los scripts necesarios para implementar los cambios realizados en el entorno de ensayo. La puesta en escena para implementaciones de producción funciona de manera similar. Otro punto importante a tener en cuenta es que, dado que estamos compartiendo la misma base de datos con otros equipos de desarrollo, usamos una función incorporada de SSC que le permite crear filtros en los objetos de la base de datos por nombre, tipo, etc. establezca filtros en los objetos de nuestro equipo específico, excluyendo todos los demás objetos, para que no cometamos accidentalmente los cambios de otros equipos de desarrollo cuando hacemos nuestras implementaciones.

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, a diferencia de los archivos de script desconectados almacenados en un repositorio de origen separado que corre el riesgo de no estar sincronizados. . También es bueno porque SQL Compare genera los scripts de implementación para que usted 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 va a crear los scripts adecuados para usted.

Sin embargo, dicho esto, aquí están algunas de las peculiaridades que he encontrado hasta ahora:

El SSC es bastante hablador en cuanto a la comunicación con el servidor db para realizar un seguimiento de los elementos de la base de datos que no están sincronizados con el repositorio de control de origen. Sondea cada pocos milisegundos y si agrega varios desarrolladores trabajando todos en la misma base de datos utilizando SSC, puede imaginar 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 notificaciones visuales de respuesta cuando se han cambiado los objetos.
Al usar la función de filtrado de objetos, no se puede saber fácilmente al ver los objetos en SSMS qué objetos están incluidos en su filtro. Por lo tanto, no está seguro si un objeto está bajo control de origen, a diferencia de Visual Studio, donde los iconos se usan para indicar objetos controlados de origen.
El 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 posee nuestro equipo y los que son propiedad de otros equipos, por lo que para evitar que cometamos / implementemos accidentalmente los cambios de otros equipos , hemos establecido un esquema de filtrado para incluir explícitamente cada objeto específico que poseemos. Como 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 dolorosa, especialmente al 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).
Usando 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. El SSC le da una advertencia si intenta verificar en un montón de cambios que estos cambios podrían no ser suyos, pero aparte de eso, usted está solo. De hecho, encuentro que este es uno de los "caprichos" más peligrosos del SSC.
Actualmente, la Comparación de SQL no puede compartir los filtros de objetos creados por el SSC, por lo que tendría que crear manualmente un filtro coincidente en la Comparación de SQL, por lo que existe el peligro de que estos no estén sincronizados. Acabo de terminar de cortar y pegar los filtros del archivo de filtro SSC subyacente en el filtro de proyecto de Comparación de SQL para evitar tratar con la GUI de filtrado de objetos torpes. Creo que la próxima versión de la Comparación de SQL le permitirá compartir filtros con el SSC, por lo que al menos este problema es solo de corto plazo. (NOTA: Este problema se resolvió en la última versión de SQL Compare. SQL Compare ahora puede usar los filtros de objetos creados por SSC).
La comparación de SQL tampoco puede compararse con un repositorio de base de datos SSC cuando se inicia directamente. Tiene que ser lanzado desde dentro de SSMS. Creo que la próxima versión de Comparación de SQL 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 de que esté actualizando el esquema de tablas existentes que no estén vacías, por lo que actualmente tiene que escribir scripts manuales. y gestiona el proceso usted mismo. Afortunadamente, esto se abordará a través de los "scripts de migración" en la próxima versión de SSC, y al observar la versión de lanzamiento temprano del producto, parece que la implementación de esta nueva característica fue bien pensada y diseñada. (NOTA: la funcionalidad de los scripts de migración se ha lanzado oficialmente. Sin embargo, actualmente no es compatible con la bifurcación. Si desea usar los scripts de migración, deberá ejecutar sql compare con su bifurcación de código de desarrollo original ... la que se registró sus cambios ... lo cual es bastante torpe y me ha obligado a modificar mi proceso de compilación de una manera menos que ideal para evitar esta limitación. Esperemos que esto se aborde en una versión futura.)

En general, estoy bastante 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 todo, de lo que necesitamos.