sql server - source - Verificar los cambios en la base de datos(control de versión)

sql source control (11)

Con suerte, alguien tiene una mejor solución que esta, pero lo hago usando un par de métodos:

Tener una base de datos "troncal", que es la versión de desarrollo actual. Todo el trabajo se hace aquí, ya que está siendo preparado para ser incluido en un lanzamiento.
Cada vez que se realiza un lanzamiento:
- La base de datos "limpia" de la última versión se copia a la nueva, por ejemplo, "DB_1.0.4_clean"
- SQL-Compare se usa para copiar los cambios de trunk a 1.0.4_clean; esto también permite verificar exactamente qué se incluye.
- SQL Compare se usa nuevamente para encontrar las diferencias entre las versiones anteriores y las nuevas (cambios de DB_1.0.4_clean a DB_1.0.3_clean), lo que crea una secuencia de comandos de cambio "1.0.3 a 1.0.4.sql".

Todavía estamos creando la herramienta para automatizar esta parte, pero el objetivo es que haya una tabla para rastrear cada versión en la que haya estado la base de datos, y si se aplicó la secuencia de comandos de cambio. La herramienta de actualización busca la última entrada, luego aplica cada script de actualización uno a uno y finalmente el DB está en la última versión.

No tengo este problema, pero sería trivial proteger las bases de datos _clean de la modificación de otros miembros del equipo. Además, debido a que utilizo SQL Compare después del hecho para generar los scripts de cambio, no hay necesidad de que los desarrolladores los sigan a medida que avanzan.

De hecho, hicimos esto por un tiempo, y fue un ENORME dolor. Era fácil de olvidar, y al mismo tiempo, se hacían cambios que no necesariamente lo hacían, por lo que el script de actualización completo creado usando los scripts de cambios creados individualmente a veces agregaría un campo, luego lo eliminaría, todo en un lanzamiento Obviamente, esto puede ser muy doloroso si hay cambios en el índice, etc.

Lo bueno de la comparación de SQL es que el script que genera está en una transacción, y si falla, lo retrotrae todo. Entonces, si el DB de producción se ha modificado de alguna manera, la actualización fallará, y luego el equipo de implementación puede usar SQL Compare en el DB de producción contra el _clean db, y corregir manualmente los cambios. Solo tuvimos que hacer esto una o dos veces (malditos clientes).

Los scripts de cambio .SQL (generados por SQL Compare) se almacenan en nuestro sistema de control de versiones (subversión).

He leído muchas publicaciones sobre la importancia del control de la versión de la base de datos. Sin embargo, no pude encontrar una solución simple para comprobar si la base de datos está en el estado correcto.

Por ejemplo, tengo una base de datos con una tabla llamada "Versión" (el número de versión se almacena allí). Pero los desarrolladores pueden acceder y editar la base de datos sin cambiar el número de versión. Si, por ejemplo, el desarrollador actualiza el procedimiento almacenado y no actualiza el estado de la base de datos de la versión no está sincronizado con el valor de la versión.

¿Cómo rastrear esos cambios? No necesito hacer un seguimiento de lo que ha cambiado, solo necesito verificar si las tablas de la base de datos, las vistas, los procedimientos, etc. están sincronizados con la versión de la base de datos que se guarda en la tabla de versiones.

¿Por qué necesito esto? Al hacer la implementación, necesito verificar que la base de datos sea "correcta". Además, no se deben rastrear todas las tablas u otros objetos de la base de datos. ¿Es posible verificar sin usar disparadores? ¿Se puede hacer sin herramientas de terceros? ¿Las bases de datos tienen sumas de comprobación?

Digamos que usamos SQL Server 2005.

Editado:

Creo que debería proporcionar un poco más de información sobre nuestro entorno actual: tenemos una "línea de base" con todos los scripts necesarios para crear una versión base (incluye objetos de datos y "metadatos" para nuestra aplicación). Sin embargo, hay muchas instalaciones de esta versión "base" con algunos objetos de base de datos adicionales (tablas adicionales, vistas, procedimientos, etc.). Cuando hacemos algún cambio en la versión "base" también tenemos que actualizar algunas instalaciones (no todas), en ese momento tenemos que verificar que la "base" esté en el estado correcto.

Gracias

En uno de nuestros proyectos, habíamos almacenado la versión de la base de datos dentro de la base de datos.

Cada cambio en la estructura de la base de datos se generó en un archivo SQL separado que incrementó la versión de la base de datos además de todos los demás cambios. Esto fue hecho por el desarrollador que cambió la estructura de db.

La secuencia de comandos de implementación se comprobó con la versión de db actual y la secuencia de comandos de cambios más recientes y, si es necesario, se aplicaron estas secuencias de comandos de sql.

Estoy usando un archivo VBScript simple basado en este artículo de proyecto de código para generar secuencias de comando drop / create para todos los objetos de la base de datos. Luego puse estos scripts bajo control de versión.

Entonces, para verificar si una base de datos está actualizada o si los cambios aún no se pusieron en control de versiones, hago esto:

Obtenga la última versión de las secuencias de comando drop / create del control de versiones (subversión en nuestro caso)
Ejecute el script SqlExtract para que se compruebe la base de datos, sobrescribiendo los scripts del control de versiones
ahora puedo consultar con mi cliente de subversión (TortoiseSVN) qué archivos no coinciden con la versión bajo control de versión
ahora actualice la base de datos o ponga los scripts modificados bajo control de versión

Primer punto: es difícil mantener las cosas en orden sin "regulaciones". O para su ejemplo, los desarrolladores que cambien cualquier cosa sin previo aviso lo llevarán a problemas graves.

De todos modos, dices "sin usar activadores". ¿Alguna razón específica para esto?

Si no, revisa los disparadores DDL. Tales factores desencadenantes son la forma más fácil de verificar si sucedió algo.

E incluso puede registrar lo que estaba pasando.

Usamos DBGhost para controlar la base de datos. Los scripts para crear la base de datos actual se almacenan en TFS (junto con el código fuente) y luego DBGhost se utiliza para generar un script delta para actualizar un entorno a la versión actual. DBGhost también puede crear scripts delta para cualquier información estática / referencia / código.

Requiere un cambio de mentalidad del método tradicional, pero es una solución fantástica que no puedo recomendar lo suficiente. Si bien es un producto de terceros, se integra perfectamente en nuestro proceso automatizado de desarrollo e implementación.

Si tiene Visual Studio (específicamente la edición de la base de datos), hay un Database Project que puede crear y dirigirlo a una base de datos de SQL Server. El proyecto cargará el esquema y básicamente le ofrecerá muchas otras características. Se comporta como un proyecto de código. También le ofrece la ventaja de escribir la tabla y el contenido completos para que pueda mantenerlo bajo Subversion. Cuando construyes el proyecto, valida que la base de datos tenga integridad. Es bastante inteligente.

Debe restringir el acceso a todas las bases de datos y solo dar acceso a los desarrolladores a una base de datos local (donde se desarrollan) y al servidor de desarrollo donde pueden hacer la integración. Lo mejor sería que solo tengan acceso localmente a su área de desarrollo y realicen tareas de integración con una compilación automatizada. Puede usar herramientas como las comparaciones de redgate sql para hacer diffs en las bases de datos. Le sugiero que mantenga todos sus cambios bajo control de fuente (archivos .sql) para que tenga un historial de quién hizo qué y cuándo para que pueda revertir los cambios de DB cuando sea necesario.

También me gusta poder hacer que los desarrolladores ejecuten un script de compilación local para reiniciar su caja de desarrollo local. De esta forma, siempre pueden retroceder. Lo que es más importante, pueden crear pruebas de integración que prueben la fontanería de su aplicación (repositorio y acceso a datos) y la lógica escondida en un procedimiento almacenado de forma automática. La inicialización se ejecuta (reiniciando db), las pruebas de integración se ejecutan (creando pelusa en el db), la reinicialización para devolver el db al estado limpio, etc.

Si usted es un usuario de estilo SVN / nant (o similar) con un único concepto de rama en su repositorio, puede leer mis artículos sobre este tema en DotNetSlackers: http://dotnetslackers.com/articles/aspnet/Building-a- -inspired-Knowledge-Exchange-Build-automation-with-NAnt.aspx y http://dotnetslackers.com/articles/aspnet/Building-a--inspired-Knowledge-Exchange-Continuous-integration-with-CruiseControl- NET.aspx

Si es un tipo de maestro de compilación de varias ramas, tendrá que esperar hasta que escriba algo sobre ese tipo de automatización y administración de configuración.

ACTUALIZAR

@Sazug: "Sí, utilizamos algún tipo de construcciones de múltiples ramas cuando usamos script base + scripts adicionales :) ¿Algún consejo básico para ese tipo de automatización sin artículo completo?" Hay más comúnmente dos formas de bases de datos:

usted controla el DB en un nuevo entorno de tipo no de producción (solo desarrollo activo)
un entorno de producción donde tienes datos en vivo acumulando a medida que desarrollas

La primera configuración es mucho más fácil y se puede automatizar completamente desde dev a prod e incluir la aceleración de retorno si es necesario. Para esto, simplemente necesita una carpeta de scripts en la que cada modificación de su base de datos se pueda mantener en un archivo .sql. No sugiero que conserve un archivo tablename.sql y luego la versión como si fuera un archivo .cs donde las actualizaciones de ese artefacto sql se modifican en el mismo archivo a lo largo del tiempo. Dado que los objetos sql dependen mucho el uno del otro. Cuando construye su base de datos desde cero, sus scripts pueden encontrar un cambio radical. Por esta razón, le sugiero que guarde un archivo separado y nuevo para cada modificación con un número de secuencia en la parte delantera del nombre del archivo. Por ejemplo algo como 000024-ModifiedAccountsTable.sql. Luego puede usar una tarea personalizada o algo fuera de NAntContrib o una ejecución directa de una de las muchas herramientas de línea de comandos de SQL.exe para ejecutar todos sus scripts en una base de datos vacía desde 000001-fileName.sql hasta el último archivo en la carpeta updateScripts. Todos estos scripts se registran en el control de su versión. Y como siempre comienza desde un db limpio, siempre puede retroceder si alguien nuevo sql rompe la compilación.

En el segundo entorno, la automatización no siempre es la mejor ruta ya que puede afectar la producción. Si se está desarrollando activamente contra / para un entorno de producción, entonces realmente necesita un entorno / ramas múltiples para que pueda probar su automatización antes de empujar realmente contra un entorno de producción. Puede usar los mismos conceptos que se han indicado anteriormente. Sin embargo, en realidad no se puede empezar desde cero en un prod DB y retroceder es más difícil. Por esta razón, sugiero usar RedGate SQL Compare de similar en su proceso de compilación. Los scripts .sql se registran con fines de actualización, pero debe automatizar una diferencia entre su db de etapas y prod db antes de ejecutar las actualizaciones. A continuación, puede intentar sincronizar los cambios y retroceder prod si se producen problemas. Además, se debe realizar alguna forma de copia de seguridad antes de una inserción automatizada de cambios sql. ¡Tenga cuidado al hacer cualquier cosa sin un ojo humano vigilante en producción! Si realizas una verdadera integración continua en todos tus entornos dev / qual / staging / performance y luego tomas algunos pasos manuales cuando te lanzas a la producción ... ¡realmente no es tan malo!

En primer lugar, su base de datos de producción no debe ser accesible para los desarrolladores, o los desarrolladores (y todos los demás) deben seguir instrucciones estrictas de que no se realizan cambios de ningún tipo en los sistemas de producción fuera de un sistema de control de cambios.

El control de cambios es vital en cualquier sistema que espere que funcione (Donde hay> 1 ingeniero involucrado en todo el sistema).

Cada desarrollador debe tener su propio sistema de prueba; si desean realizar cambios en eso, pueden hacerlo, pero el análisis del sistema debe realizarse en un sistema de prueba del sistema más controlado que aplique los mismos cambios que la producción: si no lo hace, no puede confiar en las versiones trabajando porque están siendo probados en un entorno incompatible.

Cuando se realiza un cambio, los scripts apropiados deben crearse y probarse para garantizar que se apliquen limpiamente sobre la versión actual, y que la reversión funcione *

* estás escribiendo scripts de reversión, ¿verdad?

Parece que está infringiendo la primera y la segunda regla de " Tres reglas para el trabajo de la base de datos ". Usar una base de datos por desarrollador y una sola fuente autorizada para su esquema ya sería de gran ayuda. Entonces, no estoy seguro de que tenga una línea base para su base de datos y, lo que es más importante, de que esté usando scripts de cambio . Finalmente, puede encontrar otras respuestas en Vistas, Procedimientos almacenados y similares, y en Bifurcar y fusionar .

De hecho, todos estos enlaces se mencionan en este gran artículo de Jeff Atwood: Obtenga su base de datos bajo control de versiones . A debe leer en mi humilde opinión.

Estoy de acuerdo con otras publicaciones en que los desarrolladores no deberían tener permisos para cambiar la base de datos de producción. O bien los desarrolladores deberían compartir una base de datos de desarrollo común (y correr el riesgo de pisarse los pies) o deberían tener sus propias bases de datos individuales. En el primer caso, puede usar una herramienta como SQL Compare para implementar en producción. En este último caso, debe sincronizar periódicamente las bases de datos de desarrolladores durante el ciclo de vida de desarrollo antes de promocionar a producción.

Aquí, en Red Gate, lanzaremos en breve una nueva herramienta, SQL Source Control, diseñada para facilitar mucho este proceso. Nos integraremos en SSMS y habilitaremos la adición y recuperación de objetos hacia y desde el control de fuente con solo presionar un botón. Si está interesado en obtener más información o suscribirse a nuestro Programa de acceso anticipado, visite esta página:

http://www.red-gate.com/Products/SQL_Source_Control/index.htm

Tengo que estar de acuerdo con el resto de la publicación. Las restricciones de acceso a la base de datos resolverían el problema en la producción. Luego, usar una herramienta de control de versiones como DBGhost o DVC ayudaría a usted y al resto del equipo a mantener el control de versiones de la base de datos.