2010-05-20 8 views
7

Resumen del entorno.MSBuild: ¿automatizar la recopilación de scripts de migración db?

  • aplicación Asp.net Web (fuente almacenado en SVN) de base de datos
  • SQL Server. (El esquema de la base de datos (tablas/sprocs) se almacena en svn)
  • La versión de db se sincroniza con la versión del ensamblado de la aplicación web. (almacenado en la tabla 'CurrentVersion')
  • servidor hudson de CI que controla la aplicación web desde el repositorio y ejecuta el archivo personalizado msbuild para publicar/empaquetar la aplicación.

Mi secuencia de comandos msbuild actualiza la versión de ensamblaje de la aplicación web (Major.Minor.Revision.Build) en cada compilación. La 'Revisión' está configurada para la revisión svn actualmente desprotegida y 'Build' para el número de compilación de Hudson (incrementado en cada compilación automatizada).

De esta forma puedo hacer coincidir la aplicación con una revisión de troncal específica y obtener otras estadísticas de compilación a partir del número de compilación de Hudson.

Me gustaría automatizar la recopilación de scripts de migración (sprocs actualizados, etc.) para agregar al paquete zip. Supongo que al comparar la revisión svn del archivo db que aún no se ha implementado para la revisión que se está implementando, puedo encontrar qué archivos db han cambiado en el tronco desde la última implementación en esa base de datos/entorno.

Esto podría lograrse fácilmente llamando manualmente al comando svn diff -r REVNO:REVNO para listar archivos .sql cambiados. Estos archivos podrían luego agregarse manualmente al paquete. Sería fantástico si esto pudiese automatizarse.

En primer lugar, me imagino que tendré que escribir una tarea personalizada para comprobar la versión de la base de datos que aún no se ha implementado. Después de eso estoy bastante inseguro. ¿Alguien tiene alguna sugerencia sobre cómo se lograría esto a través de una tarea msbuild ya sea existente o personalizada?

Finalmente tendré que autogenar una secuencia de comandos para agregar al paquete que actualiza la tabla de versión de la base de datos para que esté sincronizada con la aplicación.

+0

Esta es una gran pregunta. Usamos un buen número de scripts de compilación, pero aún estoy luchando para obtener nuestro DB en SVN, a veces los desarrolladores pueden ser TAN resistentes al cambio :) –

+0

Ok, encontré un comando svn que puede generar una lista de los archivos cambiados a un archivo xml Desde allí, debería poder procesar ese archivo xml a través de msbuild para obtener los archivos individuales que necesito para el espacio de trabajo de construcción. El '>;' el comando era la clave;) svn diff -r REVNO: REVNO --xml --summarizar "svn: // PathToTrunk">; d: /temp.xml –

Respuesta

2

Eche un vistazo a los proyectos de bases de datos SQL. En VS 2010 se han mejorado bastante y han incorporado capacidades de implementación que pueden sincronizar su base de datos DEV a otros entornos.

Éstos son algunos buenos enlaces sobre los proyectos de base de datos en vs 2010: http://msmvps.com/blogs/deborahk/archive/2010/05/02/vs-2010-database-project-building-and-deployment.aspx

http://weblogs.asp.net/gunnarpeipman/archive/2009/07/29/visual-studio-2010-database-projects.aspx

4

La integración de cambios de SQL en un proceso automatizado de compilación/implementación es HARD. Lo sé, porque lo intenté un par de veces con un éxito limitado. Lo que intenta hacer está más o menos en el camino correcto, pero yo diría que en realidad es demasiado complicado. En su propuesta, sugiere recopilar las secuencias de comandos SQL específicas que deben aplicarse a su base de datos en el momento de la compilación/paquete.En su lugar, debe empaquetar todos los scripts delta (para todo el historial de su base de datos) con su proyecto, y calcular los deltas que realmente se deben aplicar cuando despliegue - de esa manera, su paquete desplegable puede implementarse a entornos con bases de datos de diferentes versiones. Hay dos piezas de implementación que necesita para lograr esto:

1) Debe empaquetar sus deltas en su paquete desplegable. Tenga en cuenta que debe empaquetar deltas - no archivos estáticos que crean el esquema en su estado actual. Estos scripts delta deben estar en control de fuente. Está bien mantener el esquema estático en control de fuente también, pero deberá mantenerlo sincronizado con los deltas. En realidad, puede utilizar una herramienta como SQLCompare de Red Gate o la versión de VS Database para generar (la mayoría) deltas del esquema estático. Para obtener los deltas en su paquete desplegable, y dado que está utilizando svn, es posible que desee buscar en svn: external como una forma de "enlace suave" de los scripts delta en su proyecto web. Su script de compilación puede simplemente copiarlos en su paquete desplegable.

2) Necesita un sistema que pueda leer la lista de archivos delta, compararlos con una base de datos existente, determinar qué deltas deben aplicarse a esa base de datos y luego aplicar los deltas (y actualizar la información de contabilidad, como la versión de la base de datos). Hay un proyecto de código abierto (patrocinado por ThoughtWorks) llamado dbdeploy que logra esto. He tenido cierto éxito con esa herramienta personalmente.

Buena suerte: esta es una tuerca difícil de romper (correctamente).

0

las soluciones disponibles hoy en día que se dirigen a una pila .NET/SQL Server son:

  • DBUp (código abierto)
  • ReadyRoll (mayor integración de Visual Studio, de auto-generación de secuencias de comandos)

El último producto es uno que estamos desarrollando activamente aquí en Redgate.

Cuestiones relacionadas