Staging: Como implementar novas versões de um sistema já em produção

[Hélio Araújo de Oliveira]

Pessoal, queria saber de vocês, como fazem, e até a melhor forma de fazer para atualizar um sistema que já está em produção.

Porque, uma coisa é você testar localmente, daí quando você dá deploy pro servidor, ele pode não se dar muito bem como banco de dados por exemplo, ou com as configurações do servidor.

Minha dúvida passa principalmente pela questão do DB... eu poderia fazer uma cópia e testar em um beta.site por exemplo, mas e se o db tiver 1TB?

[Marlo Cezar]

vc pega só uma massa de testes, tipo 1.000 registros de cada tabela, e testa.

--
Você recebeu essa mensagem porque está inscrito no grupo quot;PHP-AL" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para php-al+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para php...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/php-al.
Para mais opções, acesse https://groups.google.com/d/optout.

--
"Enviado via Android"

[]´s
     Marlo Cezar

Twitter: @tbmarlo
http://tecnosobrevivente.blogspot.com.br/

[Hélio]

Mas como resolvo a questão do chave estrangeira? O db tá cheio disso

Hélio

[Marlo Cezar]

eu faria uma gambiarra: criava um banco vazio, com as mesmas tabelas, e mandava um script de "insert into tabela select * from tabela limit 1000"

mete o nome de cada tabela num FOR e manda ver.

[Gustavo Cunha]

Uma opção seria importar localmente o banco de produção, fazer a limpeza  nas tabelas pra um número razoavel pra aplicação sem comprometer a consistência da base e ai sim exportar pro ambiente de testes.

Gustavo Márcio

http://www.gmmcal.com.br

Bacharel em Ciência da Computação

Universidade Federal de Alagoas - UFAL

Maceió - Alagoas - Brasil

[Enderson Maia]

Eu não recomendo usar dados do banco de produção para o ambiente de
testes. Pro ambiente staging, por até ser, com algumas ressalvas.

Se você estiver restaurando o banco a partir de um snapshot (backup)
mesmo para grandes massas de dados, isso é bem rápido. Você
restauraria o último snapshot do banco em produção, e levantaria um
novo servidor/vhost apontando pro banco de dados de staging, depois
que estiver validado, vc pode apagá-lo.

Se ainda assim o tamanho do banco for o problema, sugiro vc criar uma
massa de dados para o staging, existem algumas ferramentas para isso
(Ex,: http://www.generatedata.com).

Sem mais,



--
Enderson Tadeu S. Maia

[Danillo César]

Em um servidor staging o ideal é usar um clone da estrutura de produção, se são clusters, pelo menos ter 1 servidor de cada cluster.

Claro isso depende do grau de testes que você deseja para simular um ambiente que te der segurança suficiente ao passar sua nova versão para o ambiente de produção. 

Muitas empresas não tem orçamento para isso, ou é bem baixo, fazendo com que force a equipe a usar um ambiente menos parecido com o de produção.

Em relação ao Banco de dados, o ideal é ter algo como o Enderson falou, pode ser até automatizado que de tempo em tempo, ele pega o backup do banco de dados em dump ou snapshot e envia para o servidor usado no staging, com algumas ressalvas como Enderson comentou, exemplo ter muito cuidado com alguns tipos de dados como email, para não enviar emails sem querer para usuários finais e ter cuidado com os dados sigilosos.

Agora se for uma fase de testes que dê para usuários finais usarem(a faze beta) aponta para o banco real como o facebook faz em http://beta.facebook.com

OBS: Tudo isso que falei não se referem a testes automatizados, que não devem de jeito nenhum usarem dados reais.

—

Danillo César de O. Melo

Software Engineer at FPPEDUMEDIA