¿Cómo rastreas los cambios en la base de datos en el control de código fuente?

votos
22

Usamos SQL Server 2000/2005 y Vault o SVN en la mayoría de nuestros proyectos. No he encontrado una solución decente para capturar cambios de esquema / proc de base de datos en cualquiera de los sistemas de control de origen.

Nuestra solución actual es bastante engorrosa y difícil de aplicar (escriba el objeto que modifica y consérvelo en la base de datos).

Tenemos muchas ideas de cómo abordar este problema con algún desarrollo personalizado, pero prefiero instalar una herramienta existente (las herramientas de pago están bien).

Entonces, ¿cómo hace un seguimiento de los cambios en el código de su base de datos? ¿Tienes alguna herramienta recomendada?


Editar:

Gracias por todas las sugerencias. Debido a las limitaciones de tiempo, preferiría no hacer mi propio aquí. Y la mayoría de las sugerencias tienen el inconveniente de que requieren que el desarrollador siga algún procedimiento.

En cambio, una solución ideal supervisaría la base de datos SQL para detectar cambios y confirmaría cualquier cambio detectado en SCM. Por ejemplo, si SQL Server tuviera un complemento que pudiera registrar cualquier cambio en DML con el usuario que realizó el cambio, entonces, debe enviar el script de ese objeto a SCM, estaría encantado.

Hablamos internamente sobre dos sistemas: 1. En SQL 2005, use permisos de objetos para restringir la alteración de un objeto hasta que haya realizado un pago. Luego, el procedimiento de registro lo guiaría al SCM. 2. Ejecute un trabajo programado para detectar cualquier cambio y enviarlo (anónimamente) a SCM.

Sería bueno si pudiera saltear la parte de acción del usuario y hacer que el sistema maneje todo esto automáticamente.

Publicado el 09/12/2008 a las 14:57
fuente por usuario
En otros idiomas...                            


14 respuestas

votos
15

Use la edición de la base de datos de Visual Studio para crear secuencias de comandos de su base de datos. Funciona como un amuleto y puede usar cualquier sistema de control de fuente, por supuesto, mejor si tiene complementos VS. Esta herramienta también tiene otras características útiles. Échales un vistazo aquí en esta gran publicación de blog

http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easily-with-Visual-Studio-2008.aspx

o echa un vistazo a MSDN para la documentación oficial

Respondida el 09/12/2008 a las 15:03
fuente por usuario

votos
5

Seguimiento de los cambios de base de datos directamente desde SSMS es posible utilizando diversas herramientas de 3 ª parte. ApexSQL control de código fuente de scripts automáticamente cualquier objeto de base de datos que se incluye en el control de versiones. Confirmaciones no se pueden realizar de forma automática por la herramienta. En su lugar, el usuario tiene que elegir qué cambios se han comprometido.

Al conseguir cambios de un repositorio, ApexSQL control de código fuente es consciente de una integridad referencial base de datos SQL. Por lo tanto, se creará un scripts de sincronización incluyendo todos los objetos dependientes que será envuelto en una transacciones así, o bien todos los cambios se aplicarán en el caso de que se encuentre ningún error, o se aplica ninguno de los cambios seleccionados. En cualquier caso, la integridad de base de datos no se ve afectado.

Respondida el 07/12/2017 a las 12:12
fuente por usuario

votos
5

Debo decir que creo que un proyecto de base de datos de estudio visual también es una solución razonable para el dilema de control de origen. Si está configurado correctamente, puede ejecutar los scripts contra la base de datos desde el IDE. Si su script es viejo, obtenga lo último, ejecútelo contra el DB. Tenga una secuencia de comandos que recrea también todos los objetos, si necesita, los nuevos objetos también deben agregarse a la secuencia de comandos a mano, pero solo una vez

Me gusta que cada tabla, proceso y función estén en su propio archivo.

Respondida el 09/12/2008 a las 15:19
fuente por usuario

votos
3

La solución de un pobre hombre sería agregar una secuencia de comandos de enlace de precompilación que vuelque el último esquema de base de datos en un archivo y que ese archivo se confirme en su repositorio de SVN junto con su código. Luego, puede diferenciar los archivos de esquema db de cualquier revisión.

Respondida el 09/12/2008 a las 15:01
fuente por usuario

votos
1

En nuestro entorno, nunca cambiamos la base de datos manualmente: todos los cambios se realizan mediante scripts en el momento de la publicación y los scripts se guardan en el sistema de control de versiones. Una parte importante de este procedimiento es asegurarse de que todos los scripts se puedan ejecutar de nuevo contra el mismo DB; los scripts son idempotentes?) Sin pérdida de datos. Por ejemplo, si agrega una columna, asegúrese de no hacer nada si la columna ya está allí.

Su comentario sobre "sugerencias tienen el inconveniente de que requieren que el desarrollador siga algún procedimiento" es realmente revelador. No es un defecto, es una característica. El control de versiones ayuda a los desarrolladores a seguir los procedimientos y hace que los procedimientos sean menos dolorosos. Si no quiere seguir los procedimientos, no necesita control de versiones.

Respondida el 09/12/2008 a las 17:32
fuente por usuario

votos
1

Hacerlo desde cero no sería muy factible, pero si utiliza una herramienta de comparación sql como Redgate SQL Compare SDK para generar sus archivos de cambio para usted, no tardaría mucho en medio rodar lo que desea y luego simplemente verificar esos archivos en el control de la fuente. Lancé algo similar para mí para actualizar los cambios de nuestros sistemas de desarrollo a nuestros sistemas en vivo en solo unas pocas horas.

Respondida el 09/12/2008 a las 15:34
fuente por usuario

votos
1

En SQL2000, genere cada objeto en su propio archivo y luego revíselos en su control de origen. Deje que su control de origen maneje el historial de cambios.

En SQL 2005, necesitará escribir un poco de código para generar todos los objetos en archivos separados.

Respondida el 09/12/2008 a las 15:04
fuente por usuario

votos
1

Aquí está Jeff Atwood en Get Your Database Under Version Control .

Respondida el 09/12/2008 a las 15:03
fuente por usuario

votos
1

Acabo de enviar el SQL-alter-Statement adicional a la declaración SQL-CreateDB completa.

Respondida el 09/12/2008 a las 15:01
fuente por usuario

votos
0

Con el fin de realizar un seguimiento de todos los cambios que Actualizar, insertar y eliminar Habrá un montón de gastos generales para el SVN. Es mejor realizar el seguimiento de los cambios DDL como (alterar, borrar, crear) que cambia el esquema. Esto se puede hacer el seguimiento de esquema fácilmente mediante la creación de una mesa y una trgger para insertar datos de esa tabla. Cualquier momento que desee u puede conseguir el cambio de estado mediante la consulta de esa mesa hay un montón de ejemplo aquí y aquí

Respondida el 26/06/2012 a las 16:02
fuente por usuario

votos
0

Desarrollamos una herramienta personalizada que actualiza nuestras bases de datos. El esquema de la base de datos se almacena en un archivo XML neutral de base de datos que luego es leído y procesado por la herramienta. El esquema se almacena en SVN y agregamos el comentario apropiado para mostrar lo que se cambió. Funciona bastante bien para nosotros.

Si bien este tipo de solución es definitivamente excesiva para la mayoría de los proyectos, a veces hace la vida más fácil a veces.

Respondida el 18/09/2009 a las 19:15
fuente por usuario

votos
0

Si usa .Net y le gusta el enfoque que toma Rails con Migrations, entonces recomendaría Migrator.Net .

Encontré un buen tutorial que incluye su configuración en Visual Studio. También proporciona un proyecto de muestra para referencia.

Respondida el 18/09/2009 a las 19:03
fuente por usuario

votos
0

En un proyecto, organicé una cuidadosa atención en el diseño para que todos los datos importantes en la base de datos puedan recrearse automáticamente desde lugares externos. Al inicio, la aplicación crea la base de datos si falta, y la rellena desde fuentes de datos externas, utilizando un esquema en el código fuente de la aplicación (y, por lo tanto, versionado con la aplicación). El nombre del almacén de la base de datos (un nombre de archivo sqlite aunque la mayoría de los administradores de bases de datos permiten múltiples bases de datos) incluye una versión de esquema, y ​​aumentamos la versión del esquema cada vez que confirmamos un cambio de esquema. Esto significa que cuando reiniciamos la aplicación a una nueva versión con un esquema diferente, se crea y completa automáticamente un nuevo almacén de base de datos. En caso de que tengamos que revertir una implementación a un esquema anterior, la nueva ejecución de la versión anterior utilizará el almacén de la base de datos anterior.

Esencialmente, la base de datos actúa como un montón de aplicaciones tradicionales, con las ventajas de la persistencia, la seguridad de las transacciones, el tipado estático (útil ya que usamos Python) y las restricciones de exclusividad. Sin embargo, no nos preocupamos en absoluto por eliminar la base de datos y empezar de nuevo, y las personas saben que si intentan realizar algún corte manual en la base de datos, se revertirá en la siguiente implementación, al igual que se revertirán los hacks de un estado de proceso. en el próximo reinicio

No necesitamos ningún script de migración ya que solo cambiamos el nombre de archivo de la base de datos y reiniciamos la aplicación y se reconstruye a sí mismo. Ayuda a que las instancias de la aplicación se fragmenten para usar una base de datos por cliente. También reduce la necesidad de copias de seguridad de bases de datos.

Este enfoque no funcionará si la compilación de la base de datos desde las fuentes externas tarda más de lo que permitirá que la aplicación permanezca inactiva.

Respondida el 15/12/2008 a las 14:14
fuente por usuario

votos
0

Nuestro dbas comprueba periódicamente la piquera contra lo que está en SVN y elimina cualquier objeto que no esté bajo control de origen. Solo toma una vez antes de que los devlopers nunca olviden poner algo en control de fuente de nuevo.

Tampoco permitimos que nadie mueva objetos a prod sin una secuencia de comandos ya que nuestros desarrolladores no tienen derechos de producción que es fácil de aplicar.

Respondida el 09/12/2008 a las 15:31
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more