A resposta de Jelayn é muito boa e representa uma prática mais ou menos padronizada, especialmente no mundo do Rails, onde uma solução semelhante é incorporada ao framework. No entanto, o estado da arte, como praticado pelo Facebook, Flickr, Heroku e IMVU - um pioneiro nisso - é um pouco mais avançado.
O problema com a prática padrão é que você pode escrever 2 versões de código e mudar de uma para outra com uma migração rápida à medida que você implanta. Há muitos problemas com isso:
-
Se você tiver muitos dados, uma migração levará tempo. Leva meses para o Facebook migrar dados, mas, a menos que você tenha poucos dados, é raro que a migração seja instantânea. A solução para isso é migrar lentamente. O IMVU foi pioneiro na estratégia aqui:
- em vez de migrar a tabela, crie uma tabela separada com o novo esquema
- quando uma linha é lida e não está presente na nova tabela, migre somente essa linha e salve-a na nova tabela. Você pode então excluir a linha antiga.
- também executa uma tarefa em segundo plano que executa as migrações em lotes (atente para conflitos!)
-
durante uma migração, seu código precisa suportar o esquema antigo e o novo. Portanto, você deve escrever o código que suporta ambos, depois migrar e, em seguida, remover o código antigo em uma implementação separada.
-
Após uma migração com falha, você deve decidir se pode migrar nas duas direções ou apenas para frente. O IMVU só avança - eu acho - então, se eles têm um bug em sua migração, eles consertam em vez de revertê-lo. Eu pessoalmente prefiro corrigir, mas há bons argumentos para revertê-lo também.
Esse material também é altamente relacionado à implantação contínua, e muitas dessas estratégias podem ajudar. Por exemplo, uma técnica comum de CD é habilitar seletivamente o novo código apenas para uma pequena base de usuários para fornecer mais testes, e somente depois habilitá-lo para públicos maiores e maiores (normalmente, você usa uma configuração de banco de dados para cada recurso). Essa prática permite que você ganhe mais confiança em suas migrações, especialmente quando elas são mais complicadas do que apenas adicionar um campo e sem apostar todos os seus dados em uma migração relativamente não testada.
Source : pesquisa de mercado e conversas com os clientes enquanto realizo minha Integração contínua e Implantação .
>