Um guia para iniciantes sobre a implantação de alterações do modelo Django na produção

Você pode encontrar muitos artigos na internet sobre como implantar um projeto Django em produção pela primeira vez. Mas, o que fazer quando seu projeto já está em produção, e durante as implantações, você precisa garantir a consistência dos sistemas relacionados e, ao mesmo tempo, a continuidade do seu produto?

O que é Produção?

A produção é um complexo de software e hardware que está disponível para os usuários finais. Inclui servidores, máquinas virtuais e contêineres com software estável instalado.

Existem muitos requisitos para a produção. No entanto, neste artigo, vamos nos concentrar na eficiência e na continuidade.

Eficiência é uma garantia de que o produto fará o que deve fazer.

A continuidade é uma garantia de trabalho eficiente ao usar este produto.

Ou seja, se uma tentativa de login sempre retornar um erro, isso é falta de eficiência. Mas, se um usuário raramente recebe esse erro, isso é uma violação de continuidade.

Dados iniciais

Vários contêineres, máquinas virtuais ou servidores são usados na produção, dependendo da arquitetura.

Não considero a situação em que apenas um processo está trabalhando em um servidor em produção, pois é semelhante ao ambiente de desenvolvimento usual.

Esquema de Produção

Em geral, você geralmente encontra o esquema com vários contêineres. Eles são acessados por meio de um balanceador. Pode haver mais de um balanceador. A partir de contêineres, um banco de dados é acessado, mas pode haver vários bancos de dados, incluindo sharding e réplicas. Eles também podem acessar corretores como Kafka e outros serviços. Outros serviços também podem, de alguma forma, trocar informações com back-ends.

Alterações simultâneas no código e no banco de dados

Por exemplo, vamos considerar apenas alterações no código e em um banco de dados.

As mudanças que podem ser feitas no código para que isso afete um banco de dados e vice-versa:

1. Adicionar/remover uma tabela.
2. Adicionar/remover uma coluna.
3. Renomeie uma coluna ou tabela.
4. Altere o tipo de coluna.
5. Altere os atributos (índice) da coluna (NULL, exclusivo, padrão).

Você também pode adicionar gatilhos e funções, alterar o esquema e muito mais. No entanto, as abordagens gerais para aplicar isso à produção são mostradas nesses mesmos exemplos.

Exemplo Detalhado

Se você precisar adicionar um modelo (tabela) a um aplicativo localmente no ambiente de desenvolvimento, faça o seguinte:

1. Adicione uma classe a um modelo Django.
2. Chame o comando: python manage.py makemigrations .
3. Então: python manage.py migrate .
4. E somente depois disso, reinicie o aplicativo.

Mas na produção, há muitas instâncias de seu aplicativo, git e um processo separado para executar migrações.

Muitas vezes você não tem acesso direto ao Prod. E isso é bom. Por exemplo, o fluxo pode ter esta aparência.

Nesse esquema, as migrações são executadas primeiro. Então, um por um, os pods são reiniciados.

Em tal arquitetura, sempre pode haver uma situação em que as migrações foram realizadas, mas o código na produção não foi alterado.

Em seguida, os pods estão sendo substituídos. Algumas instâncias têm um novo código, algumas têm o antigo.

Além disso, se você realizar migrações quando a substituição do pod estiver concluída, uma situação diferente ocorrerá: o código no servidor é atualizado, mas o banco de dados não.

Ambas as situações implicam algum período de tempo em que o banco de dados e o código são inconsistentes.

Felizmente, o Django não verifica a consistência. No entanto, a ausência dos elementos necessários resulta em exceções.

Eles são:

1. A presença de uma classe no modelo no código, mas a ausência dela no banco de dados
2. A presença de um campo na classe no código, mas a ausência dele no banco de dados
3. Nomes diferentes de tabelas e colunas no código e no banco de dados
4. Diferentes tipos de dados no código e na tabela
5. Valores padrão, NULL e outras diferenças, se for para usá-los
6. Outras diferenças que o banco de dados não espera quando acessado a partir do código

Soluções

A migração precisa ser realizada antes de alterar o código quando isso implicar:

1. Adicionando uma tabela
2. Adicionando uma coluna
3. Adicionando a capacidade de inserir NULL no campo

A migração precisa ser realizada após a alteração do código quando isso implicar:

1. Removendo uma tabela
2. Removendo uma coluna
3. Removendo a capacidade de inserir NULL no campo

A renomeação é realizada em várias etapas:

1. Criando um novo campo ou tabela
2. Adicionando sincronização de um campo ou tabela nova e antiga
3. Copiar dados históricos, se necessário
4. Começando a usar um novo campo ou tabela
5. Removendo um campo ou tabela antiga junto com a sincronização

Tudo isso parece complicado. Mas olhe para os esquemas dados acima. Na produção multi-pod, durante a implantação, sempre acontece que parte do código funciona com o esquema de banco de dados antigo enquanto outra parte funciona com o novo. Isso pode resultar em exceções.

Assim, os algoritmos básicos para lidar com modelos Django não funcionam quando se trata de produção. As alterações precisam ser implantadas em várias etapas, dependendo da arquitetura do código e do fluxo de CI/CD usado em um caso específico.

No entanto, ao fazer alterações, você sempre pode se guiar pelo que o código espera ao enviar solicitações ao banco de dados. Além dos casos padrão, pode haver várias exceções e obstáculos que exigem engenhosidade para encontrar uma maneira de contornar.

Nos próximos artigos, descreverei em detalhes alguns dos casos mencionados aqui.