Migração de banco de dados e slots de implantação do Azure

15

Estou planejando enviar um novo aplicativo Web para um Serviço Web App do Azure (antigo Site do Azure). Eu gostaria de usar os slots de implantação para poder testar minha implantação antes de colocá-la em produção. Tudo bem, desde que não haja mudança no esquema do banco de dados. Mas se houver uma alteração de esquema, não posso ter duas versões de software operando na mesma versão de banco de dados. Como estou usando EF Migrations, o envio para o slot de teste resultaria instantaneamente em uma atualização do banco de dados para a versão mais recente.

Portanto, minha pergunta é: existe algum uso de slots de implantação quando uma migração de banco de dados é necessária?

Como é feito para grandes provedores de SaaS. Eles estão executando uma migração de banco de dados instantaneamente com a nova versão? Isso certamente causaria algum tempo de inatividade.

Só consigo pensar em soluções bastante complexas para esse problema, existe algo simples?

entity-framework deployment migration azure continuous-delivery Sam7
fonte
Então você não tem um banco de dados dev?
Jeffo
Sim, temos um sistema de desenvolvimento e controle de qualidade. O sistema descrito acima é para fins de produção.
precisa saber é
@ Sam7 você conseguiu encontrar uma solução para esse problema? Cheers
WestDiscGolf
Receio que não. No momento, estamos testando alterações de migração em um ambiente separado.
precisa saber é
@ Sam7: Eu acho que você pode gerenciar isso por um arquivo .config separado com uma cadeia de conexão própria ao seu banco de dados. mas você está certo, quando implanta do estágio para a produção, o benefício de uma reversão não funciona mais. as alterações de banco de dados serão aplicadas instantaneamente. Estou curioso para uma solução no futuro próximo ...
Roger S.

Respostas:

3

São possíveis lançamentos de tempo de inatividade zero usando slots do Serviço de Aplicativo do Azure e um único banco de dados compartilhado pelo Staging and Production - mas você precisa garantir que todas as alterações no banco de dados sejam compatíveis com versões anteriores, para que as versões atuais e novas do aplicativo Web possam ser executadas simultaneamente em os slots de teste e produção.

Algumas regras que garantem que isso funcione:

  • Quaisquer novas colunas do banco de dados devem ser anuláveis ​​ou ter valores padrão
  • Renomear colunas não é permitido
  • Soltar colunas não é permitido

Quando você precisar fazer alterações destrutivas, como renomear ou soltar colunas, precisará de 2 versões para fazer isso:

  1. A nova versão do aplicativo Web deve ser lançada, o que remove a dependência das colunas renomeadas / descartadas
  2. É feita uma liberação adicional que executa as alterações destrutivas

Embora isso pareça um pouco complicado, na prática você provavelmente não fará alterações destrutivas com muita frequência.

Cocowalla
fonte
0

você olhou para os itens de configuração específicos do slot? Em WebApp / Configurações / Configurações do aplicativo, você pode especificar configurações para o aplicativo Web, mas também definir se ele se aplica apenas a esse slot.

Portanto, você pode ter uma cadeia de conexão específica ao slot para o slot temporário e aplicar a migração também na troca de slots.

Owain Thomas
fonte
2
Isso vai contra a minha ideia de ter o site de teste funcionando exatamente no mesmo conjunto de dados (-> banco de dados) da produção.
Sam7