Automatizar las migraciones de objects de BD desde el control de código fuente

Estoy buscando algunas "Mejores prácticas" para automatizar la implementación de Procedimientos almacenados / Vistas / Funciones / Cambios de tabla desde el control de origen. Estoy usando StarTeam & ANT para que el labeldo se cumpla; Lo que estoy buscando es cómo algunos de ustedes se han acercado a la automation de la atracción de estos objects desde la fuente, no necesariamente StarTeam.

Me gustaría terminar con una secuencia de commands que luego se puede ejecutar, registrar y labelr.

NO estoy pidiendo a nadie que escriba eso, solo algunas ideas o enfoques que han funcionado (o no) en el pasado.

Estoy tratando de limpiar un desastre y quiero asegurarme de get esto tan cerca de "lo correcto" como pueda.

Estamos almacenando las tablas / vistas / funciones, etc. en files individuales en StarTeam y nuestra database es SQL 2K5.

Usamos SQL Compare de networkinggate ( http://www.networking-gate.com/ ).

Tenemos una database de producción, una database de desarrollo y cada desarrollador tiene su propia database.

La database de desarrollo se sincroniza con los cambios que un desarrollador ha realizado en su database cuando verifican sus cambios.

El desarrollador también comtesting un script de synchronization y un informe de comparación generado por SQL Compare.

Cuando desplegamos nuestra aplicación simplemente sincronizamos la database de desarrollo con la database de producción usando SQL Compare.

Esto funciona para nosotros porque nuestra aplicación es solo para uso interno. Si este no es su escenario, entonces vería SQL Packager (también de networkinggate).

Verifique migraciones (señalado por Andrew Peters en otra publicación )

Prefiero separar vistas, procedimientos y triggers (objects que pueden volver a crearse a voluntad) de las tablas. Para vistas, procedimientos y activadores, simplemente escriba un trabajo que los revisará y volverá a crear el último.

Para las tablas, prefiero tener una tabla de versión de database con una fila. Use esa tabla para determinar qué nuevas actualizaciones no se han aplicado. Luego se aplica cada actualización y se actualiza el número de versión. Si falla una actualización, solo tiene que verificar esa actualización y puede volver a ejecutar para saber que las actualizaciones anteriores no volverán a suceder.

Como Carl señaló, puede usar una utilidad de diferencias para crear sus scripts de actualización. RedGate es un buen producto, pero SQL Server 2k5 viene con TableDiff, que también debería hacer el trabajo.