Eu acho que há duas partes para este problema.

A primeira é gerenciar o esquema do banco de dados e suas alterações. Fazemos isso usando o South, mantendo os modelos de trabalho e os arquivos de migração em nosso repositório SCM. Por segurança (ou paranóia), fazemos um dump do banco de dados antes (e se estivermos realmente com medo, depois) de executar qualquer migração. Sul tem sido adequado para todas as nossas necessidades até agora.

O segundo é implantar a mudança de esquema que vai além de apenas executar o arquivo de migração gerado pelo South. Na minha experiência, uma alteração no banco de dados normalmente requer uma alteração no código implantado. Se você tiver um pequeno web farm, manter o código implantado em sincronia com a versão atual do esquema do banco de dados pode não ser trivial - isso fica pior se você considerar as diferentes camadas de cache e o efeito para um usuário do site já ativo. Sites diferentes lidam com esse problema de maneira diferente e não acho que haja uma resposta única.

Resolver a segunda parte deste problema não é necessariamente simples. Não acredito que haja uma abordagem única para todos, e não há informações suficientes sobre seu site e ambiente para sugerir uma solução que seja mais adequada para sua situação. No entanto, acho que há algumas considerações que podem ser mantidas em mente para ajudar a orientar a implantação na maioria das situações.

Colocar todo o site (servidores web e banco de dados) offline é uma opção em alguns casos. É certamente a maneira mais direta de gerenciar atualizações. Mas o tempo de inatividade frequente (mesmo quando planejado) pode ser uma boa maneira de fazer nossos negócios rapidamente, torna cansativo implantar até mesmo pequenas alterações de código e pode levar muitas horas se você tiver um grande conjunto de dados e/ou migração complexa. Dito isso, para sites que eu ajudo a gerenciar (que são todos internos e geralmente usados ​​apenas durante o horário de trabalho em dias úteis), essa abordagem faz maravilhas.

Tenha cuidado se você fizer as alterações em uma cópia do banco de dados mestre. O principal problema aqui é que seu site ainda está ativo e, presumivelmente, aceitando gravações no banco de dados. O que acontece com os dados gravados no banco de dados mestre enquanto você está ocupado migrando o clone para uso posterior? Seu site precisa estar inativo o tempo todo ou ser colocado em algum estado somente leitura temporariamente, caso contrário você os perderá.

Se suas alterações são compatíveis com versões anteriores e você tem um web farm, às vezes você pode atualizar o servidor de banco de dados de produção ao vivo (o que acho inevitável na maioria das situações) e, em seguida, atualizar incrementalmente os nós no farm, tirando-os do balanceador de carga por um curto período. Isso pode funcionar bem - no entanto, o principal problema aqui é se um nó que já foi atualizado enviar uma solicitação para um URL que não é suportado por um nó mais antigo, você falhará, pois não pode gerenciar isso no nível do balanceador de carga.

Eu vi/ouvi algumas outras maneiras de funcionar bem.

A primeira é agrupar todas as alterações de código em um bloqueio de recurso que pode ser configurado em tempo de execução por meio de algumas opções de configuração em todo o site. Isso significa essencialmente que você pode liberar o código onde todas as suas alterações estão desativadas e, depois de fazer todas as atualizações necessárias em seus servidores, você altera sua opção de configuração para habilitar o recurso. Mas isso torna o código bastante pesado ...

A segunda é deixar o código gerenciar a migração. Já ouvi falar de sites em que as alterações no código são escritas de forma a lidar com a migração em tempo de execução. É capaz de detectar a versão do esquema que está sendo usado e o formato dos dados que recebeu - se os dados forem do esquema antigo, ele fará a migração no local, se os dados já forem do novo esquema, não fará nada . Do uso natural do site, uma grande parte de seus dados será migrada por pessoas que usam o site, o resto você pode fazer com um script de migração sempre que quiser.

Mas acho que neste momento o Google se torna seu amigo, porque, como eu disse, a solução é muito específica ao contexto e estou preocupado que essa resposta comece a ficar sem sentido ... Procure por algo como "implantação de tempo de inatividade zero" e você obterá resultados como isto com muitas ideias...