Eu trabalho em uma pequena equipe de programação apoiando uma organização maior. Este ano, nosso gerente decidiu que usaremos as tecnologias Oracle Apex para lidar com a grande maioria dos dados de nossa empresa.

Isso seria bom, exceto que temos apenas um servidor Apex. Nosso gerente decretou que tudo acontece nessa única instância. Nossa equipe está desenvolvendo aplicativos, enquanto nossa demonstração de gerente os utiliza e nossos clientes internos os usam, o que por razões óbvias já está causando problemas!

Só posso esperar que isso piore à medida que investimos mais no Apex, os aplicativos ficam mais complexos e o número de usuários cresce. Ouvi dizer que a melhor prática é ter ambientes separados de desenvolvimento, teste e produção, mas por que esse é o caso?

A pergunta: por que devemos ter ambientes separados de desenvolvimento, teste e produção?

Por que devemos ter ambientes separados de desenvolvimento, teste e produção?

Você tem várias atividades acontecendo simultaneamente:

• development - onde os desenvolvedores cometem código, cometem erros, experimentam, etc ...
• testes - onde os testes são executados, manualmente ou automatizados e devido à complexidade, podem consumir muitos recursos.
• produção - onde o valor é criado para clientes e / ou negócios

Deseja que tudo isso aconteça no mesmo ambiente? Deseja que os negócios parem porque um novo teste levou seus servidores a trocar de discos rígidos e estão consumindo todos os núcleos do processador? Deseja que seus testes sejam interrompidos porque um desenvolvedor fez uma bomba complicada com um experimento de dimensionamento? Deseja que o código que você pensou funcionou por causa do cordão e fita adesiva de um desenvolvedor nos testes seja executado na produção? Deseja que os desenvolvedores trabalhem com dados de produção potencialmente sensíveis (sei que isso não é uma preocupação em todas as empresas, mas em muitas delas)?

O que impede que esses problemas aconteçam?

Ambientes separados.

Então, o que você precisa?

Você precisa de ambientes separados.

Para colocar formalmente

Você precisa de ambientes separados pelos seguintes motivos:

• para reduzir os riscos de bloquear negócios e desenvolvimento de software.
• reduzir os riscos de colocar o código em produção que passou nos testes devido ao aparelhamento ad-hoc dos desenvolvedores.
• reduzir os riscos de os dados de produção chegarem às mãos erradas (muito importante quando as organizações lidam com dados confidenciais, como números de identificação e informações financeiras e de saúde) ou se misturarem aos dados de teste ou serem destruídos.

Para o seu contexto, uma nova plataforma tecnológica

Talvez isso ainda não seja realmente uma produção (já que é uma plataforma relativamente nova), mas você terá seus ambientes separados quando a empresa começar a confiar nela e eles são espertos o suficiente para prever o risco ou percebê-lo aprendendo muito caminho.

Ouvi dizer que a melhor prática é ter ambientes separados de desenvolvimento, teste e produção, mas por que esse é o caso?

Não é tão claro hoje em dia.

Muitos locais não fazem mais testes manuais, portanto, não possuem dados de teste propriamente ditos. Muitos outros locais têm tal escala, que não conseguem reproduzir seu ambiente de produção devido ao custo. E, especialmente, com o crescimento explosivo dos microsserviços, torna-se desafiador manter os ambientes em rápida mudança sincronizados o suficiente para garantir que os testes em um ambiente de controle de qualidade reproduzam as coisas com precisão para detectar bugs que apareceriam na produção.

Por que devemos ter ambientes separados de desenvolvimento, teste e produção?

• Se a exibição dos dados de teste pelos usuários for muito ruim.
• Se a exibição dos dados do seu produto por desenvolvedores / testadores for muito ruim.
• Se você não pode confiar em seus desenvolvedores para não quebrar muito as coisas, e você não pode resolver essa situação rapidamente.
• Se você possui um IC automatizado, de forma que a promoção do código seja rápida e fácil.

Essencialmente, se o custo de ter os ambientes for menor que o custo de não ter os ambientes .

O principal (e mais aparente) motivo é que você nunca deseja misturar dados de teste e produção. Isso pode ficar incrivelmente confuso rapidamente, tanto para os usuários do sistema quanto para os desenvolvedores. Ao administrar garantia de qualidade e testes de unidade (o que você deve fazer), é necessário garantir que eles estejam em um ambiente totalmente segregado. Se algo explodir em seu ambiente de desenvolvimento ou no controle de qualidade, isso afetaria adversamente a produção e, assim, usuários vivos e seus dados importantes! Você absolutamente não quer que isso efetue a produção!

Isso se estende aos serviços normais que você deve usar no seu trabalho diário, como o controle de versão. Você não pode utilizar o controle de versão corretamente se o código que você está controlando estiver em um ambiente ativo! Seus usuários ficarão loucos - e se você precisar reverter ou reverter? E se você cometer um erro drástico, quinze cometerá profundamente? Como você vai lidar com a ramificação?

No mínimo, você deve separar seu ambiente em várias instâncias virtuais, mas realmente precisa fazer exatamente o que disse e ter instâncias completamente separadas para cada ambiente; idealmente desenvolvimento, controle de qualidade, preparação e produção.

Em última análise, tudo isso representa um enorme prejuízo, não apenas para o aplicativo de frente (e, portanto, para a reputação dos usuários), mas também para a eficiência da equipe.

Ter apenas uma instância do Oracle disponível não significa o mesmo que "nenhuma separação entre os ambientes de desenvolvimento, teste e produção"!

Você escreveu em um comentário

Atualmente, usamos esquemas diferentes para projetos diferentes

Ok, então, ao dedicar alguns projetos apenas ao desenvolvimento e outros ao teste, você pode separar seus ambientes até certo ponto, usando esquemas diferentes. Acho que você já fez isso, já que essa é a única abordagem sensata que conheço quando nenhuma separação de instância está planejada. Não posso imaginar que seu gerente seja tão insano que ele deseja que você misture dados de desenvolvimento, dados de teste e dados de clientes em um esquema de maneiras arbitrárias. Ele provavelmente só quer economizar dinheiro não comprando um segundo servidor ou investir dinheiro na licença para uma segunda instância.

Portanto, a verdadeira pergunta que você precisa fazer é:

Precisamos usar diferentes instâncias e / ou servidores para separar ambientes de desenvolvimento, teste e produção, ou a separação de esquema é suficiente?

Isso torna a resposta não tão clara como nas outras respostas aqui. Esquemas diferentes permitem direitos de acesso diferentes, para que você possa pelo menos obter um certo grau de isolamento em uma instância do Oracle. No entanto, seus desenvolvedores provavelmente precisarão de alguns direitos administrativos dentro do esquema "deles", portanto, será mais difícil garantir que eles não tenham acesso aos dados de produção se você usar apenas uma instância.

Além disso, uma instância / um servidor também significará recursos compartilhados entre desenvolvimento, teste e produção - administração de usuário / esquema compartilhada, espaço em disco compartilhado, CPUs compartilhadas, CPUs compartilhadas, largura de banda de rede compartilhada. Combine isso com a "lei das abstrações com vazamento" e ficará claro que o uso de apenas uma instância terá um certo risco de obter efeitos colaterais indesejados entre o ambiente de desenvolvimento, teste e produção.

No final, você deve decidir por si mesmo: você pode trabalhar efetivamente com os inconvenientes da abordagem? Seu aplicativo não é tão intenso em recursos e seus dados de produção não são tão "secretos" que é tolerável ter um nível reduzido de separação entre desenvolvimento, teste e produção do que o nível que você obteria de "três instâncias / três servidores" abordagem? Se você não puder trabalhar dessa maneira efetivamente, ou não, sem um alto risco de interferir na produção de uma maneira que comece a perder clientes, você terá todos os argumentos necessários para convencer seu gerente a comprar pelo menos um segundo servidor.

Você precisa de vários tipos de ambiente e talvez até vários servidores em cada ambiente.

Os desenvolvedores podem atualizar o código no desenvolvimento. O código pode nem funcionar - talvez o aplicativo nem seja iniciado.

Isso não afeta o controle de qualidade que está testando a versão estável mais recente em seu próprio ambiente.

Como o desenvolvimento e o controle de qualidade estão atualizando seus ambientes, a produção está na versão mais recente de seis meses atrás e não é afetada pelas mudanças em outros ambientes.

Essas alterações sendo implementadas em vários ambientes podem ser código ou dados. Talvez o controle de qualidade precise testar um script de banco de dados projetado para corrigir alguns dados incorretos na produção. Talvez o script agrave o problema - restaure um backup do banco de dados e tente novamente. Se isso acontecesse na produção, você poderia ter um problema financeiro muito sério.

O que acontece se você tiver vários lançamentos? Talvez você esteja desenvolvendo a versão 2.0, mas ainda precise de lançamentos de correção de bugs no ramo de manutenção 1.0. Agora você precisa de vários ambientes de desenvolvimento e controle de qualidade para garantir que você sempre possa desenvolver e testar qualquer ramificação quando um bug crítico for descoberto e precisar ser corrigido ontem.

Você já percebeu os problemas que não possuem ambientes separados. Bem ali, você tem a razão fundamental para ambientes separados: eliminar os problemas causados ​​pelos conflitos que inevitavelmente surgem ao tentar realizar operações de desenvolvimento, teste e produção em um único ambiente. O mesmo raciocínio se aplica a dar aos desenvolvedores caixas de proteção individuais para trabalhar, ele mantém os erros de um desenvolvedor ou mesmo apenas alterações incompatíveis de prejudicar toda a equipe de desenvolvimento.

Esse também é o melhor argumento que você pode apresentar à gerência para se afastar do ambiente único: apontar para os problemas que um único ambiente já está causando, mostrando a linha de tendência e argumentando que, mais cedo ou mais tarde, se as coisas continuarem como estão, haverá uma problema que custará muito mais para limpar (tanto no esforço direto quanto na perda da confiança do cliente na capacidade da sua empresa de fornecer serviços) do que reconfigurar itens para ambientes separados.

Existem muitas forças e dinâmicas opostas. Existe o custo de ter muitos servidores e o custo de ter apenas um. Eu acho que essa pergunta pode ser mais relevante do que apenas banco de dados? Posso estar entendendo mal, mas está relacionado a um mal-entendido sistêmico que existe por aí, custos de tangíveis versus abstratos

Normalmente, os custos óbvios são fáceis de entender.

Os custos abstratos são mais difíceis de quantificar e, portanto, mais difíceis de entender. Dívida técnica, custo de erros, custo de estresse, ônus para os desenvolvedores, efeitos de mudança, teste de regressão, impacto do tempo de inatividade e assim por diante são mais difíceis de explicar.

ambientes diferentes Os ambientes geralmente são separados por dados e / ou finalidade. Cada ambiente tem uma função diferente. A taxa de mudança em um sistema, ie. com que frequência será atualizada, que tipo de mudanças e efeitos da mudança são considerados.

Usamos ambientes diferentes para banalizar as mudanças.

Utilizamos ambientes diferentes, por isso oferecemos robustez e certeza do ambiente que não mudou.

Usamos ambientes para considerar os efeitos de uma mudança.

Utilizamos ambientes para reduzir os custos envolvidos com as mudanças.

custa muito testar e estabilizar um sistema Você cria ambientes para proteger o investimento que foi feito no ambiente estável.

Você nunca é uma equipe pequena demais para aderir a padrões de processo pragmáticos, com economia de custos, diligentes e comprovados.

Usar um ambiente para tudo é como armazenar todas as suas fotos em um disco rígido, você pode fazê-lo, mas vai se arrepender.

algumas pessoas precisam de provas de que estive em muitas situações lidando com clientes ou outros que não apreciam os custos de garantir robustez e seguir as melhores práticas. Eu sugiro que você junte alguns exemplos de casos reais em que os custos estão claramente definidos.