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:  Adicionar/remover uma tabela.  Adicionar/remover uma coluna.  Renomeie uma coluna ou tabela.  Altere o tipo de coluna.  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:  Adicione uma classe a um modelo Django.  Chame o comando:   . python manage.py makemigrations  Então:   . python manage.py migrate  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:  A presença de uma classe no modelo no código, mas a ausência dela no banco de dados  A presença de um campo na classe no código, mas a ausência dele no banco de dados  Nomes diferentes de tabelas e colunas no código e no banco de dados  Diferentes tipos de dados no código e na tabela  Valores padrão, NULL e outras diferenças, se for para usá-los  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:  Adicionando uma tabela  Adicionando uma coluna  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:  Removendo uma tabela  Removendo uma coluna  Removendo a capacidade de inserir NULL no campo   A renomeação é realizada em várias etapas:  Criando um novo campo ou tabela  Adicionando sincronização de um campo ou tabela nova e antiga  Copiar dados históricos, se necessário  Começando a usar um novo campo ou tabela  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.

Read My Stories

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Make resilience your competitive advantage

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps