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 hizo hace más de un año, es posible que mi respuesta no sea tan útil para usted, pero para otros que actualmente pueden estar evaluando SSC, pensé en aportar mi granito de arena. Acabamos de empezar a usar SQL Source Control (SSC) y, en general, hasta ahora estoy bastante satisfecho con él. Sin embargo, tiene algunas peculiaridades, especialmente si está trabajando en un entorno de base de datos compartida (a diferencia de todos los desarrolladores que trabajan localmente) y, en particular, si trabaja en un entorno heredado donde los objetos en la misma base de datos se dividen al azar entre los equipos de desarrollo.
Para brindar una breve descripción general de cómo estamos usando 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 código fuente. 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 hayan terminado, pueden confirmar sus cambios en el control de código fuente. Cuando estemos listos para la implementación en el ensayo, el maestro de compilación (yo) fusiona la rama de desarrollo del código de la base de datos con la rama principal (de ensayo) y luego ejecuta SQL Compare utilizando la versión del repositorio de la rama principal de la base de datos como fuente y en vivo. base de datos provisional como destino y SQL Compare genera los scripts necesarios para implementar los cambios realizados en el entorno provisional. Las implementaciones de ensayo a producción funcionan 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, usamos una función integrada 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, para que no confirmemos accidentalmente los cambios de otro equipo de desarrollo cuando hacemos nuestras implementaciones.
Entonces, 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 secuencias de comandos desconectados almacenados en un repositorio de origen separado que corren el riesgo de perder la sincronización. . También es bueno porque SQL Compare genera los scripts de implementación por usted 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 estar bastante seguro de que creará los scripts adecuados para usted.
Dicho esto, sin embargo, estas son algunas de las peculiaridades con las que me he topado hasta ahora:
- SSC es bastante hablador en términos de comunicación con el servidor de base de datos para realizar un seguimiento de los elementos de la base de datos que no están sincronizados con el repositorio de control de código fuente. Sondea cada pocos milisegundos y si agrega varios desarrolladores que trabajan en la misma base de datos usando 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 las notificaciones visuales receptivas de cuándo se han cambiado los objetos.
- Con la función de filtrado de objetos, no puede saber fácilmente al mirar los objetos en SSMS qué objetos están incluidos en su filtro. Por lo tanto, no sabe con certeza si un objeto está bajo control de código fuente, a diferencia de Visual Studio, donde los íconos se usan para indicar objetos controlados por código fuente.
- 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 hay una separación clara entre los objetos que posee nuestro equipo y los que pertenecen a otros equipos, por lo que para evitar que cometamos/implementemos accidentalmente los cambios de otros equipos , hemos configurado 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 volverse bastante doloroso, especialmente al intentar configurar su entorno por primera vez (Terminé escribir una aplicación para hacer esto). En el futuro, estamos creando un nuevo esquema para nuestra aplicación para facilitar mejor 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. SSC le advierte si intenta verificar un montón de cambios de que estos cambios pueden no ser suyos, pero aparte de eso, está 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 coincidente en SQL Compare, por lo que existe el peligro de que estos se desincronicen. Terminé cortando y pegando los filtros del archivo de filtro SSC subyacente en el filtro del proyecto SQL Compare para evitar tener que lidiar con la GUI de filtrado de objetos torpe. Creo que la próxima versión de SQL Compare le permitirá compartir filtros con SSC, por lo que al menos este problema es solo a 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).
- SQL Compare 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 SQL Compare proporcionará esta funcionalidad, por lo que nuevamente es otro problema a corto plazo. (NOTA:este problema se resolvió en la última versión de SQL Compare).
- A veces, SQL Compare no puede crear los scripts adecuados para llevar la base de datos de destino de un estado a otro, generalmente en el caso de que esté actualizando el esquema de las tablas existentes que no están vacías, por lo que actualmente tiene que escriba guiones manuales y administre 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 inicial 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 sql compare contra su código de desarrollo original branch... aquel en el que Verificaste tus 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. Con suerte, esto se abordará 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 siento que en la próxima versión o dos, el producto probablemente nos dará la mayor parte, si no todo, de lo que necesitamos.
