É ruim desenvolver dados de produção?

10

Eu sempre ouvi dizer que é uma prática ruim desenvolver dados de produção e atualmente estou no processo de mudar para um modelo de Dev> Stage> Production , principalmente porque tenho um novo funcionário com habilidades mínimas e prefiro não tê-lo trabalhe diretamente com os dados de produção ainda.

Mas, por um longo tempo, trabalhei diretamente com dados de produção com um mínimo de dores de cabeça, exceto por alguns erros que aparecem aqui ou ali, como problemas de ortografia, texto alternativo incorreto, links apontando para o local errado. Isso parece ser devido à falta de revisão por pares da minha parte, não por trabalhar com dados ao vivo.

Então, por que o desenvolvimento no site ao vivo é tão ruim?

plntxt
fonte
Você pode apenas duplicar os dados que possui no servidor de produção no servidor de desenvolvimento.
21710 HoLyVieR
11
mmmm ... como eu voto essa pergunta sem parecer apoiar sua maneira de fazer as coisas diretamente com os dados de produção? : S
vmarquez 14/07
2
@ vmarquez Uma pergunta sobre uma prática ruim é necessariamente uma pergunta ruim?
plntxt
Não não é. Eu estava prestes a votar porque tinha a sensação de que esse tipo de pergunta é uma ótima forma de educar sobre as melhores práticas e, de alguma forma, tive a ideia de que a votação poderia ser tomada como uma aprovação tácita na má prática, provocando assim exatamente o efeito oposto. Agora, acho que a votação pode ser enganosa ... pelo menos em alguns casos.
vmarquez
11
As pessoas votam nas coisas por todos os tipos de razões diferentes. Não votei em nada além de "essa pessoa tirou algo dessa questão".
Artlung

Respostas:

17

Se durante o desenvolvimento você estiver executando comandos SQL que incluem INSERTou UPDATEem tabelas de banco de dados existentes, você corre um risco na medida em que essas tabelas de banco de dados são essenciais.

Alguns locais sincronizam os dados de produção no banco de dados de desenvolvimento em algum intervalo, digamos, uma vez por semana ou a pedido do desenvolvedor, para que você tenha novos dados para desenvolver.

Mas se seus dados de produção não correm risco com o que você está fazendo, por exemplo, se você estivesse simplesmente desenvolvendo uma visualização de alguns dados, geralmente não é um grande problema. Agora, se você estiver executando relatórios que fazem varreduras de tabela, você tem o potencial de bloquear uma tabela, e seus usuários existentes são afetados.

Eu recomendaria ao meu administrador de banco de dados em casos como este, se não houver um DBA "oficial", seria um erro por precaução. É simples o suficiente para criar um banco de dados de desenvolvimento, mesmo para mim. Em uma equipe, é vital. Caso contrário, se você insistisse em manter apenas um banco de dados, poderia prefixar suas tabelas de banco de dados de desenvolvimento DEV_e se sentir um pouco melhor. Sim, isso requer algumas alterações de código, mas no desenvolvimento, adicionar algumas variáveis ​​durante o desenvolvimento $debug = true, etc, geralmente vale a pena.

Muitas maneiras de abordar isso. É muito dependente da sua situação.

artlung
fonte
+1 no processo de sincronização. Fazemos isso sob demanda aqui para o nosso desenvolvimento. Também temos um controle de qualidade, que é uma área sincronizada com mais frequência para a revisão final das alterações antes que elas atinjam a produção. Mas, às vezes, executamos consultas nos dados de produção, apenas porque o problema está relacionado aos dados e é muito difícil de replicar.
Milner
O +1 e a sincronização podem ser complicados. Em muitos casos, você vai querer fazer coisas como parte do impulso produ-> Test como endereços de e-mail matagal e nomes, etc para evitar que acidentalmente e-mail "Caro rico bastardo"
JasonBirch
11

Você NÃO deseja desenvolver dados de produção no servidor de produção. Há algumas razões imensas.

  1. O desenvolvimento diminui a velocidade da sua caixa de produção e cria vulnerabilidades. O que acontece se você deixar o computador desbloqueado e se afastar?
  2. Se você cometer um erro, as pessoas que visitarem o site poderão vê-lo.
  3. Se você fizer algum tipo de atualização de dados dentro de uma Transação no banco de dados e não a confirmar imediatamente, ou se a transação demorar um pouco para terminar, você bloqueará todas as tabelas envolvidas e poderá causar um tempo limite .
  4. Alguns sistemas de banco de dados, especificamente o SQL Server, fazem bloqueios de tabela às vezes apenas nas instruções SELECT! O que significa que você pode inadvertidamente dar tempo limite às pessoas ou páginas de erro no seu site.

Eu nunca faria trabalho de desenvolvimento em uma caixa viva, se possível. Sua melhor aposta é fazer um backup do banco de dados e das páginas, trabalhar com a cópia e enviar suas atualizações. Uma ferramenta que me ajudou muito é o SyncToy da Msft.

Ben Hoffman
fonte
7

Bem, você pode realmente atrapalhar os dados. Imagine deixar de fora uma cláusula where. Mesmo se você tiver backups de hora em hora, isso seria difícil de corrigir.

Echo diz Restabelecer Monica
fonte
3

Se você não dirige sem cinto de segurança, não desenvolva dados de produção. Apenas uma questão de segurança.

MrChrister
fonte
3

Se você tiver dados de produção disponíveis, é razoável usá-los para teste, mas use um banco de dados de teste separado com uma cópia desses dados. Caso contrário, muitas coisas funcionarão para seus poucos registros de teste "blabla", mas não para um cenário real.

E para desenvolver dados de produção ao vivo - lembre-se das leis de Murphy "Tudo o que pode dar errado vai dar errado". E é tão fácil cometer um pequeno erro com grandes conseqüências ruins.

devmake
fonte