¿Cómo se mueven los cambios de Dev Database en la base de datos de producción?

Question

He estado trabajando en un proyecto y lo he pasado en la primera etapa. Sin embargo, los requisitos terminaron cambiando y tengo que agregar nuevas tablas y volver a hacer algunas de las referencias clave clave en el DB.

El problema que tengo es mi falta de conocimiento sobre cómo hacer este tipo de cambio en una base de datos de producción luego de que haya terminado el desarrollo en la base de datos de desarrollo.

¿Cuáles son algunas estrategias para migrar los cambios al esquema de la base de datos y mantener los datos en la base de datos?

Por lo que yo sé, este es abrir Sql Server Management Studio y comenzar a agregar tablas manualmente. Sé que esta es probablemente una mala forma de hacerlo, por lo que busco cómo hacerlo correctamente y me doy cuenta de que probablemente comencé mal.

Answer 1

Normalmente utilizo algo como el SQL Server Publishing Wizard para producir scripts SQL de los cambios. Ese es un enfoque bastante simple y fácil. La desventaja principal con esa herramienta es que el producido caerá y volverá a crear tablas que no se cambian sino que se usan por procedimientos que han cambiado (y no puedo entender por qué), por lo que se necesita un poco de trabajo manual para revisar el script y eliminar cosas que no necesitan estar allí.

Nota que no necesita descargar e instalar esta herramienta; puede ejecutarlo desde Visual Studio. Haga clic con el botón derecho en una conexión en el Explorador del servidor y seleccione "Publicar en proveedor" en el menú contextual.

Answer 2

Hay algunas herramientas disponibles para ayudarlo con eso.

Si usted tiene edición de Visual Studio Team, verificar los proyectos de bases de datos (también conocido como DataDude del equipo conocido como Visual Studio for Database Professionals) See here y here

Se le permite generar un modelo de la base de datos dev/integración y luego (por muchos, pero no todos los casos) crean automáticamente scripts que actualizan su base de datos de prod con los cambios que hizo a dev/integration.

Para VS 2008, asegúrese de obtener los parches GDR2.

Answer 3

Tienes que tener algo llamado "KIT". Obviamente, si mantiene algún tipo de control de fuente, todos los scripts para los cambios que realice en los entornos de desarrollo deben mantenerse en la herramienta de configuración de control de origen.

Una vez que haya terminado con todos los scripts/cambios que considera certificados para pasar al siguiente entorno superior. Prepare el kit con todas estas secuencias de comandos en carpetas (idealmente clasificadas como Procedimientos, Tablas, Funciones, Bootstraps) Y luego tenga un archivo por lotes que pueda ejecutar estos scripts en el kit en un orden particular utilizando la utilidad de línea de comandos OSQL.

Tengan archivos por lotes separados para UAT/Puesta en escena/producción para que pueda hacer doble clic en el archivo por lotes para ejecutar el kit en el servidor apropiado. Verifique las opciones de OSQL.

¡De esta forma todos sus entornos están sincronizados!

Answer 4

Es posible que desee echa un vistazo a una herramienta como Liquibase: http://liquibase.org/

Answer 5

Hemos encontrado la mejor manera de impulsar cambios es para el tratamiento de bases de datos como cambios de código. Todos los cambios están en scripts, están en control de fuente y son parte de una versión.Nunca se empuja bajo ninguna circunstancia a la producción que no esté codificada y en control de fuente. De esta forma, no se presionan accidentalmente los cambios que están en desarrollo, pero que aún no están listos para ser empujados a prod. Además, puede restaurar los datos prod al recuadro de desarrollo y volver a ejecutar todos los scripts que aún no se han insertado y tiene datos actualizados y todo el trabajo de desarrollo conservado. Esto también funciona muy bien cuando tienes valores de búsqueda para tablas que están cambiando y no quieres presionar hasta que otras cosas se muevan también. Escriba el inserto y colóquelo con el resto del código para la versión.

Es bueno usar esas herramientas para hacer una comparación para ver si se omite algo en las secuencias de comandos, pero NUNCA confié solo en ellas. Demasiado riesgo de empujar algo que aún no está listo para el horario de máxima audiencia.

Answer 6

Red Gate SQL Compare y SQL Data Compare todo el camino. Desde que mi compañía lo compró, me ahorró muchísimo tiempo organizar nuestras bases de datos desde DEV hasta TEST hasta ACEPTACIÓN y PRODUCCIÓN.

Y puede hacer que se sincronice con una carpeta de scripts también para una fácil integración en un sistema de control de fuente.

http://www.red-gate.com

Answer 7

Para mantener Cambios en el esquema se puede utilizar ApexSQL Diff, una comparación de esquema y herramienta de sincronización de SQL Server y SQL Azure, y para mantener los datos en la base de datos puede utilizar ApexSQL Data Diff, un servidor SQL Server y la comparación de datos SQL Azure y herramienta de sincronización.

Esperanza esto ayuda

responsabilidad: yo trabajo para ApexSQL como ingeniero de soporte

Answer 8

Una buena herramienta de diseño de base de datos (como Sybase PowerDesigner) a permitir la creación de los cambios de diseño en el modelo de datos , luego genere el código para implementar esos cambios. A continuación, puede almacenar y ejecutar el código como lo desee. Esta herramienta también debería poder realizar ingeniería inversa cuando heredes una base de datos que no construiste.

Encontrar todos los cambios entre el desarrollo y la producción suele ser difícil incluso en un entorno organizado y bien documentado. Idera tiene una herramienta para SQL Server que detectará las diferencias estructurales entre su base de datos de desarrollo y producción y otra herramienta que detectará cambios en los datos. De hecho, a menudo los uso para ir en la otra dirección y sincronizar el desarrollo con la producción para comenzar un nuevo proyecto.