Creo que hay dos partes en este problema.
Lo primero es administrar el esquema de la base de datos y sus cambios. Hacemos esto usando South, manteniendo tanto los modelos de trabajo como los archivos de migración en nuestro repositorio SCM. Por seguridad (o paranoia), hacemos un volcado de la base de datos antes (y si estamos realmente asustados, después) de ejecutar cualquier migración. South ha sido adecuado para todos nuestros requisitos hasta ahora.
En segundo lugar, está implementando el cambio de esquema que va más allá de simplemente ejecutar el archivo de migración generado por South. En mi experiencia, un cambio en la base de datos normalmente requiere un cambio en el código implementado. Si tiene incluso una pequeña granja web, mantener el código implementado sincronizado con la versión actual del esquema de su base de datos puede no ser trivial; esto empeora si considera las diferentes capas de almacenamiento en caché y el efecto para un usuario del sitio ya activo. Diferentes sitios manejan este problema de manera diferente, y no creo que haya una respuesta única para todos.
Resolver la segunda parte de este problema no es necesariamente sencillo. No creo que exista un enfoque único para todos, y no hay suficiente información sobre su sitio web y entorno para sugerir una solución que sea más adecuada para su situación. Sin embargo, creo que hay algunas consideraciones que se pueden tener en cuenta para ayudar a guiar la implementación en la mayoría de las situaciones.
Desconectar todo el sitio (servidores web y base de datos) es una opción en algunos casos. Sin duda, es la forma más sencilla de administrar las actualizaciones. Pero el tiempo de inactividad frecuente (incluso cuando está planificado) puede ser una buena manera de terminar el negocio rápidamente, hace que sea tedioso implementar incluso pequeños cambios en el código y puede llevar muchas horas si tiene un gran conjunto de datos o una migración compleja. Dicho esto, para los sitios que ayudo a administrar (que son todos internos y generalmente solo se usan durante el horario laboral en días hábiles), este enfoque funciona de maravilla.
Tenga cuidado si realiza los cambios en una copia de su base de datos maestra. El principal problema aquí es que su sitio aún está activo y, presumiblemente, acepta escrituras en la base de datos. ¿Qué sucede con los datos escritos en la base de datos maestra mientras está ocupado migrando el clon para su uso posterior? Su sitio tiene que estar inactivo todo el tiempo o ponerse en un estado de solo lectura temporalmente, de lo contrario los perderá.
Si sus cambios son compatibles con versiones anteriores y tiene una granja web, a veces puede salirse con la suya actualizando el servidor de la base de datos de producción en vivo (que creo que es inevitable en la mayoría de las situaciones) y luego actualizando gradualmente los nodos en la granja sacándolos del balanceador de carga por un período corto. Esto puede funcionar bien; sin embargo, el problema principal aquí es que si un nodo que ya se actualizó envía una solicitud de una URL que no es compatible con un nodo anterior, fallará porque no puede administrar eso en el nivel del balanceador de carga.
He visto/escuchado un par de otras formas que funcionan bien.
El primero es envolver todos los cambios de código en un bloqueo de función que luego se puede configurar en tiempo de ejecución a través de algunas opciones de configuración en todo el sitio. Básicamente, esto significa que puede liberar código donde todos sus cambios están desactivados, y luego, después de haber realizado todas las actualizaciones necesarias en sus servidores, cambia su opción de configuración para habilitar la función. Pero esto hace un código bastante pesado...
El segundo es dejar que el código administre la migración. He oído hablar de sitios donde los cambios en el código se escriben de tal manera que maneja la migración en tiempo de ejecución. Es capaz de detectar la versión del esquema que se está utilizando y el formato de los datos que obtuvo:si los datos son del esquema anterior, realiza la migración en su lugar, si los datos ya provienen del nuevo esquema, no hace nada. . Desde el uso natural del sitio, las personas que usan el sitio migrarán una gran parte de sus datos, el resto lo puede hacer con un script de migración cuando lo desee.
Pero creo que en este punto Google se convierte en tu amigo, porque como digo, la solución es muy específica del contexto y me preocupa que esta respuesta empiece a perder sentido... Busca algo como "implementación sin tiempo de inactividad" y listo. Obtendrá resultados como esto con muchas ideas...
