Quão semelhantes devem ser os ambientes do PreProd e Prod?

Eu estive recentemente em um projeto e, durante o lançamento, percebemos que ele não funcionava na produção. Funciona em todos os outros ambientes, mas, como temos uma equipe de lançamento separada e não podemos configurar os servidores e os ambientes, não temos visibilidade da configuração neles.

Suspeitamos que o Prod tenha algumas permissões de usuário em sua conta ou configurações do IIS diferentes, por isso estamos trabalhando agora.

Então, acho que tudo isso foi uma experiência de aprendizado para mim e não quero que a mesma coisa seja repetida novamente. Eu gostaria de perguntar, quão diferentes devem ser esses ambientes? Eu sempre pensei que o PreProd deveria ser uma cópia idêntica ao ambiente Prod, usando uma cópia do mesmo banco de dados, usando uma cópia da mesma conta de usuário, deveria ser instalada nos mesmos servidores etc.

Mas até onde devo levá-lo? Se o site estiver voltado para o exterior, o PreProd deve estar voltado para o exterior? E se o site tiver componentes que não exijam uma conta de usuário ou senha para navegar? Ainda é bom expô-lo ao mundo exterior?

Você certamente deve testar em um ambiente idêntico aos seus servidores de produção, na medida do possível. Caso contrário, você não está testando o que seus clientes usarão. Se nada mais, você precisa desse ambiente para testar quaisquer relatórios de erros.

Obviamente, haverá coisas que você não desejará idênticas - vêm à mente links para sistemas de pagamento, mas eles devem ser ridicularizados como se fossem reais . Também há coisas que você não pode replicar - a escala do sistema.

Convém testar por meio de um URL externo. Novamente, você está testando o que seus usuários verão. Além disso, o teste por meio de um URL externo usará a rede de maneira diferente do uso interno do sistema. Permissões (por exemplo) desempenharão um papel, assim como largura de banda disponível, firewalls etc. Todos os usuários terão acesso, mas você pulará se acessar o sistema diretamente.

Não vejo problemas com componentes que não exigem uma conta e senha. Se ele não precisa de uma senha, não é vital / sensível; se é sensível, por que não possui uma senha?

Acho que a melhor prática para isso é a abordagem Blue Green Deployment, criada por Jez Humble e David Farley em seu livro Continuous Delivery e descrita por Martin Fowler em seu blog Blue Blue Deployment .

A premissa é muito simples. Do post de Martin Fowler:

A abordagem de implantação azul-verde ... [garante] que você tem dois ambientes de produção, o mais idêntico possível. A qualquer momento, um deles, digamos azul, por exemplo, está ativo. Ao preparar uma nova versão do seu software, você realiza seu estágio final de teste no ambiente verde. Depois que o software estiver funcionando no ambiente verde, você alterna o roteador para que todas as solicitações recebidas passem para o ambiente verde - o azul fica ocioso.

A implantação azul esverdeado também oferece uma maneira rápida de reverter - se algo der errado, você muda o roteador de volta ao seu ambiente azul.

Essa abordagem resolveria o problema de não ter ambientes idênticos de pré-produção e produção, além de otimizar sua estratégia de implantação.

Nosso ambiente final de pré-produção é simplesmente um dos servidores ativos retirados do balanceador de carga. Implementamos nossa compilação de pré-produção (que é basicamente idêntica à compilação ao vivo, exceto as seqüências de conexão do banco de dados e algumas outras alterações de configuração) e testamos isso. Se tudo der certo, implantamos o código ativo e, finalmente, se isso for aprovado, devolvemos o servidor ao balanceador de carga e implantamos a construção de produção nos servidores restantes, um por um.

Eles devem ser o mais semelhante possível, para que você possa identificar problemas em qualquer ponto do sistema, com a possível exceção de uma incapacidade de escalar. Se possível, a única diferença entre o ambiente de produção e o ambiente de pré-produção / preparação / teste seria o tamanho - eu esperaria que um ambiente de produção consistisse em muito mais máquinas em um ambiente de larga escala. Você deve até espelhar as dedicações das máquinas que possui, como servidores de banco de dados, servidores da Web etc.

No entanto, uma replicação exata pode não ser possível no seu orçamento atual. Quanto mais próximo estiver, mais eficaz será o teste e menos prováveis ​​os problemas surgirão durante um impulso à produção.

Eu adoto uma postura diferente da do ChrisF se esse ambiente for voltado para o público. Eu digo que não deveria ser. Eu optaria por executar uma cópia dos bancos de dados reais ou, pelo menos, uma cópia de um subconjunto dos bancos de dados ativos reais e de um ambiente voltado para dentro. Dessa forma, você pode testar dados reais e realistas e não se preocupar com falhas de segurança que levem a um vazamento. Obviamente, você pode limpar os dados, mas isso pode remover alguns "dados sujos" do ambiente que podem levar à descoberta de um defeito em um sistema ativo.

Em todos os lugares em que trabalhei em bancos, telecomunicações e etc., o pré-prod foi uma cópia direta da produção, exceto que o banco de dados teria uma semana ou mais. Foi um processo massivo para manter os dados no pré-produto, mas foi considerado essencial para as empresas nas quais trabalhei e que implementaram o pré-produto.

Na seção bancária da UA, o governo multa os bancos por falhas no serviço, por exemplo, caixas eletrônicos de sites e etc, caem a cada minuto. Não é incomum ouvir uma equipe de desenvolvimento / teste demitida por um incidente. O pré-prod não é para todas as empresas ou processos de desenvolvimento, mas é essencial para alguns.