desenv-web-rp.com

É ruim desenvolver dados de produção?

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

Mas, por um longo tempo, trabalhei diretamente com dados de produção com dores de cabeça mínimas, exceto, talvez, 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?

10
plntxt

Se durante o desenvolvimento você estiver executando comandos SQL que incluem INSERT ou UPDATE em tabelas de banco de dados existentes, você corre um risco na medida em que essas tabelas de banco de dados sejam 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 ter apenas um banco de dados, poderia prefixar suas tabelas de banco de dados de desenvolvimento com 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.

17
artlung

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 seu banco de dados e não a confirmar imediatamente, ou se a transação demorar um pouco, 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.

11
Ben Hoffman

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.

7
Echo

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.

3
devmake

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

3
MrChrister