É 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 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?

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.

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.

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.

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

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.