Verificar cambios en la base de datos (control de versión)

Question

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 guardada 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?

supongamos que usamos SQL Server 2005.

Editado:

creo que debería proporcionar un poco más de información acerca de nuestro entorno actual - tenemos una "línea de base" con todos los scripts necesarios para crear la base versión (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

Answer 1

Estoy usando un archivo VBScript simple basado en this codeproject article para generar gota/crear secuencias de comandos para todos los objetos de la base. Luego puse estos scripts bajo control de versión.

Así que para comprobar si una base de datos está actualizada o tiene cambios que aún no se pusieron en el control de versiones, hago esto:

• obtener la última versión de la gota/crear secuencias de comandos de la versión de control (la subversión en nuestro caso)
• ejecutar el script SqlExtract para la base de datos para comprobar, sobrescribiendo las secuencias de comandos de control de versiones
• ahora puedo comprobar con mi cliente subversión (TortoiseSVN), que los archivos no coinciden con la versión bajo control de versión
• n o actualiza la base de datos o coloca los scripts modificados bajo el control de versión

Answer 2

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. Si bien es un producto de terceros, se integra perfectamente en nuestro proceso automatizado de desarrollo e implementación.

Answer 3

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 traerán a problemas serios.

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

Si no, echa un vistazo a 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.

Answer 4

Esperemos que alguien tiene una solución mejor que esto, pero hacer esto usando un par de métodos:

• Tener una base de datos "tronco", que es la versión actual del desarrollo. Todo el trabajo se hace aquí, ya que está siendo preparado para ser incluido en un lanzamiento.
• Cada vez que un lanzamiento se realiza:
  • base de datos "limpios" El último de liberación se copia en el nuevo, por ejemplo, "DB_1.0.4_clean"
  • SQL-Compare se utiliza para copiar los cambios desde el tronco para el 1.0.4_clean - esto también permite verificar exactamente qué se incluye.
  • SQL Compare se usa de nuevo para encontrar las diferencias entre las versiones anteriores y nuevas (cambios de DB_1.0.4_clean a DB_1.0.3_clean), que crea un script de cambio "1.0.3 a 1.0.4.sql".

Todavía están construyendo la herramienta para automatizar esta parte, pero el objetivo es que hay una mesa de seguimiento de cada versión de la base de datos ha estado en, y si se aplica el guión 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 por parte 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).

Answer 5

Tiene que restringir el acceso a todas las bases de datos y solo dar a los desarrolladores acceso 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 cuadro 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), reinicialización para volver a poner el db en estado limpio, etc.

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

Si es un tipo de maestro de compilación de múltiples ramas, tendrá que esperar hasta que escriba algo sobre ese tipo de automatización y gestión de la configuración.

ACTUALIZACIÓN

@Sazug: "Sí, utilizamos una especie de rama de múltiples construye cuando usamos la escritura de guiones adicionales base + :) Cualquier consejos básicos para ese tipo de automatización y sin artículo completo" Hay más comúnmente dos tipos de bases de datos:

• que controlas el PP en un nuevo entorno de tipo no-producción (sólo dev activo)
• un entorno de producción donde se han acumulando datos en tiempo real a medida que desarrolle

La primera configuración es mucho más fácil y se puede automatizar por completo desde dev a prod e incluir rolling prod 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 todas sus secuencias de comandos contra 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!

Answer 6

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 construye el proyecto, valida que la base de datos tenga integridad. Es bastante inteligente.

Answer 7

En uno de nuestros proyectos teníamos una versión de base de datos almacenada 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 aplicó estas secuencias de comandos de sql si es necesario.

Answer 8

Parece que está infringiendo la primera y la segunda regla de "Three rules for database work". 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 un Baseline para su base de datos y, lo que es más importante, que esté usando change scripts. Finalmente, puede encontrar algunas otras respuestas en Views, Stored Procedures and the Like y en Branching and Merging.

En realidad, todos estos enlaces se mencionan en este gran artículo de Jeff Atwood: Get Your Database Under Version Control. A debe leer en mi humilde opinión.

Answer 9

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 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 hace un cambio, las secuencias de comandos apropiados deben ser creados y probados para asegurar que se aplican limpiamente en la parte superior de la versión actual, y que la reversión de las obras *

* está escribiendo scripts de rollback, ¿verdad?

Answer 10

Estoy de acuerdo con otras publicaciones 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 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 inscribirse en nuestro Programa de Acceso Temprano, visite la página:

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

Answer 11

Estoy de acuerdo con el resto de la entrada. 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 lo ayudaría a usted y al resto del equipo a mantener el control de versiones de la base de datos