contas de teste e produtos em um sistema de produção

Question

Vale a pena projetar um sistema que esperar contas de teste e produtos para estar presente e ativo na produção, ou caso não haja contaminação de bases de dados de produção com entidades de teste, mesmo se a sua tripulação de transporte não sabe para enviar qualquer caixa dirigida ao " Cliente teste "?

Eu tenho implementado mensagens protocolos que têm um test = "true" atributo na especificação, e se perguntou se um esquema moderno deve incluir metadados para marcar ordens, contas, transações, etc., como entidades de teste que são processadas como qualquer outra entidade - mas um pouco abaixo do ponto onde o dinheiro é gasto. Ou seja:. Ele finge cobrando um cartão de crédito imaginário e finge o envio de um pacote

Este não é esperado para ser um substituto para um teste totalmente separados, desenvolvimento e banco de dados de QA, mas mesmo com esses, sempre tivemos o conhecido Cliente Teste SKU e Teste no sistema de produção. Inofensivo?

Answer 1

Ter contas de teste na produção é algo que eu normalmente desaprovam porque abre um potencial falha de segurança. Um devem se esforçar para duplicar tanto do ambiente de produção em testar quanto possível, mas obviamente há casos em que não é possível. Expensive produção só hardware é um excelente exemplo. Eu diria como uma prática geral, deve ser desencorajado, mas como com todas as coisas, se você pode fornecer uma razão que faz sentido para você, então você pode ignorar uma regra dura e rápida.

Answer 2

Eu imagino que o Melhor Polícia Prática iria indicar o mantra "nunca teste em prod" e talvez até mesmo jogar em "desenvolvedores não devem ter acesso a prod".

No entanto, eu trabalho em um sistema baseado em mainframe, onde há enormes diferenças entre a produção e teste / QA / QC; quanto maior for o sistema, o tal situação a mais provável é. Além disso, os vários grupos que têm interesse na aplicação, o mais provável é este.

Eu preciso de mais do que duas mãos para contar quantas vezes nós só poderia duplicar um problema no ambiente de produção. A opção torna-se então a criação de tabelas de teste / usuários / dados ou usando dados do cliente ao vivo.

Às vezes nós também criar registros de teste na produção tabelas, como alguns usuários / clientes gostam de ter algo que eles podem procurar / Recuperar que está sempre lá.

Portanto, meu conselho é que é OK para colocar teste contas / produtos em produção, se ele vai ajudar a solucionar problemas após o go-live.

Answer 3

Se o seu banco de dados é criado a partir de scripts em uma forma automatizada, então isso se torna uma não-questão.

No meu ambiente usamos controle de cruzeiro para compilações contínua. Os scripts SQL para gerar o banco de dados são verificados no CVS com tudo o resto, eo banco de dados é reconstruído a partir desses roteiros em uma base diária.

Os nossos dados de teste é um segundo conjunto de scripts SQL, que são executados no banco de dados de teste e não são executados para o banco de dados de produção.

Dada a nossa dados de teste ambiente nunca toca o banco de dados de produção.

Esta solução realmente funciona muito bem para nós.

Answer 4

Eu não colocaria todos os dados de teste em um sistema de produção nem eu gostaria de ter acesso a este sistema como um desenvolvedor.

Eu estou trabalhando em uma indústria com informação médica e financeira muito sensível e ter essa informação tornaria impossível distinguir produtiva a partir de dados para fora do sistema de teste.

IMHO a melhor prática é separar completamente estes dois mundos e investir na criação de um procedimento para preparar um ambiente de teste abrangente.

Answer 5

Na fora os sistemas ERP (internamente acessível apenas) temos dados de teste para que, quando nos movemos mudanças de teste para ambientes de produção que pode testar todo o processo. Eu vejo que os dados como um mal necessário, uma vez que as diferenças de configuração sutis entre sistemas podem causar resultados catastróficos, então quando uma mudança está em teste, a produção é totalmente antes de "liberação" para os usuários.

Como eu disse, porém, estes são aplicativos internos apenas, portanto, os riscos de segurança são diminuídas pouco -. Isso é uma preocupação muito válida

Answer 6

Nunca teste em prod, apesar de que é onde toda a receita é gerada / estatísticas são recolhidas / mágica acontece ...?

Sempre tem um plano de teste de produção. Não vão haver problemas que acontecem na prod, ou, se você é azarado, única acontece na prod. Se você não tem nada no lugar, pela primeira vez, você precisa de teste em prod (que geralmente são casos de alta tensão), vai ficar até o córrego sem uma pá.

Não é inofensiva para ter dados de teste em prod, você precisa ter cuidado.