Lista de verificación para actualizaciones del esquema de base de datos

Question

Tener que actualizar el esquema de una base de datos hace que la instalación de una nueva versión de software sea mucho más complicada.¿Cuáles son las mejores prácticas para hacer esto?

Estoy buscando una lista de verificación o un cronograma de elementos de acción, como

• 8:30 cerrar aplicaciones
• 8:45 modificar esquema
• 9:15 instalar nuevas aplicaciones
• 9:30 reiniciar db

etc., mostrando cómo minimizar el riesgo y el tiempo de inactividad.Cuestiones como

• retroceder en la actualización si las cosas salen mal
• minimizar el impacto en las aplicaciones existentes
• Actualizaciones "calientes" mientras la base de datos se está ejecutando.
• promoción desde el desarrollo hasta los servidores de prueba y de producción

son de especial interés.

Answer 1

Tengo mucha experiencia con esto.Mi aplicación es muy iterativa y los cambios de esquema ocurren con frecuencia.Hago un lanzamiento de producción aproximadamente cada 2 o 3 semanas, con 50-100 elementos eliminados de mi lista FogBugz para cada uno.Cada lanzamiento que hemos realizado en los últimos años ha requerido cambios de esquema para admitir nuevas funciones.

La clave para esto es practicar los cambios varias veces en un entorno de prueba antes de realizarlos en los servidores activos.

Mantengo un archivo de lista de verificación de implementación que se copia de una plantilla y luego se edita intensamente para cada versión con cualquier cosa que esté fuera de lo común.

Tengo dos scripts que ejecuto en la base de datos, uno para cambios de esquema y otro para programabilidad (procedimientos, vistas, etc.).El script de cambios está codificado a mano y el que tiene los procesos está escrito a través de Powershell.El script de cambio se ejecuta cuando todo está apagado (debe elegir un momento que moleste a la menor cantidad de usuarios para esto) y se ejecuta comando por comando, manualmente, en caso de que algo salga raro.El problema más común con el que me he encontrado es agregar una restricción única que falla debido a filas duplicadas.

Cuando me preparo para un ciclo de prueba de integración, reviso mi lista de verificación en un servidor de prueba, como si ese servidor fuera de producción.Luego, además de eso, obtengo una copia real de la base de datos de producción (este es un buen momento para cambiar las copias de seguridad externas) y ejecuto los scripts en una versión local restaurada (lo cual también es bueno porque demuestra mi la última copia de seguridad es correcta).Estoy matando muchos pájaros de un tiro aquí.

Entonces son 4 bases de datos en total:

1. Desarrollador:todos los cambios deben realizarse en el script de cambios, nunca con el estudio.
2. Prueba:Las pruebas de integración ocurren aquí
3. Copia de producción:Práctica de implementación de último minuto
4. Producción

Realmente necesitas hacerlo bien cuando lo haces en producción.Revertir los cambios de esquema es difícil.

En cuanto a las revisiones, solo corregiré los procedimientos, nunca los esquemas, a menos que sea un cambio muy aislado y crucial para el negocio.

Answer 2

¿Supongo que has considerado las lecturas de Scott Ambler?http://www.agiledata.org/essays/databaseRefactoring.html

Answer 3

Este es un tema del que justo estaba hablando en el trabajo.Principalmente, el problema es que, a menos que su marco maneje bien las migraciones de bases de datos, por ejemplo, Rails y sus scripts de migración, entonces queda en sus manos.

La forma actual en que lo hacemos tiene fallas aparentes y estoy abierto a otras sugerencias.

1. Tenga un volcado de esquema con datos estáticos que deben mantenerse actualizados y en control de versiones.
2. Cada vez que realiza una acción de cambio de esquema, ALTERAR, CREAR, etc.volcarlo en un archivo y colocarlo en el control de versiones.
3. Asegúrese de actualizar el volcado de base de datos SQL original.
4. Al realizar push to live, asegúrese de que usted o su script apliquen los archivos sql a la base de datos.
5. Limpie los archivos SQL antiguos que están en control de versiones a medida que se vuelven obsoletos.

Esto de ninguna manera es óptimo y en realidad no pretende ser una base de datos de "respaldo".Es simplemente para facilitar la vida y mantener a los desarrolladores en sintonía.Probablemente haya algo interesante que puedas configurar con capistrano en cuanto a automatizar la aplicación de los archivos sql a la base de datos.

El control de versiones específico de Db sería bastante impresionante.Probablemente haya algo que haga eso y, si no lo hay, probablemente debería haberlo.

Answer 4

Y si el artículo de Scott Ambler le abre el apetito, puedo recomendarle su libro escrito por Pramod J Sadolage llamado 'Refactoring Databases'. http://www.ambysoft.com/books/refactoringDatabases.html

También hay muchos consejos e información útiles en el grupo Agile Database de Yahoo. http://tech.groups.yahoo.com/group/agileDatabases/

Answer 5

Dos notas rápidas:

1. No hace falta decir nada...Así que lo diré dos veces.
   Verifique que tenga una copia de seguridad válida.
   Verifique que tenga una copia de seguridad válida.

2. @mk.Verificar Publicación del blog de Jeff sobre el control de versiones de la base de datos (si aún no lo ha hecho)