none
Discussão - Qual é a melhor forma de atualizar dados entre ambientes? RRS feed

  • Pergunta

  • Olá Pessoal,

    Aqui na empresa temos 3 ambientes:

    Desenvolvimento, Homologação e Produção

    Tenho a seguinte dúvida: Qual é a melhor maneira de manter os dados de desenvolvimento atualizados com os dados de produção?Sendo que em desenvolvimento são criados novos objetos constantemente pelos desenvolvedores então não posso simplesmente restaurar um backup e desconsiderar o que tem de novo em desenvolvimento.

    Poderiam compartilhar comigo as experiências de vocês?

    Muito obrigado!


    • Editado Sergio Marchetti segunda-feira, 21 de novembro de 2016 10:38 Sugestão José Diz
    sexta-feira, 18 de novembro de 2016 13:08

Respostas

  • Deleted
    sexta-feira, 18 de novembro de 2016 13:30
  • Sergio Marchetti,

    Este é um cenário complexo (na minha opinião) principalmente considerando a sincronização Produção -> Desenvolvimento, pelo fato de você mesmo mencionar que novos objetos são criados constantemente, logo, um simples mapeamento para sincronização do ambiente de Desenvolvimento pode gerar dados inconsistentes (não refletem a realidade em Produção) ou simplesmente abortar todo processo.

    Mas de modo geral, o trabalho de cópia de dados quando exige alguma lógica, eu optaria pelo Integration Services (ou um script que seja executado através de um job), de modo que você possa invocar a execução do pacote manualmente ou se sua equipe de desenvolvimento utilizar algum recurso de Continuous Integration (TFS Build Services, Jenkins, etc.) a execução do mesmo possa ser feita via script.

    No cenário que atuo hoje em dia, normalmente restauro um backup do banco de produção no ambiente de desenvolvimento e então aplico os scripts para as mudanças de estrutura. Acho este o melhor cenário nestes casos. Até porque estes novos objetos terão que ser criados em homologação e produção posteriormente, logo, seu script também precisa ser testado.


    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, remember to "Mark as Answer".

    Se achou este post útil, por favor clique em "Votar como útil". Se por acaso respondeu sua dúvida, lembre de "Marcar como Resposta".




    sexta-feira, 18 de novembro de 2016 13:26

Todas as Respostas

  • Sergio Marchetti,

    Este é um cenário complexo (na minha opinião) principalmente considerando a sincronização Produção -> Desenvolvimento, pelo fato de você mesmo mencionar que novos objetos são criados constantemente, logo, um simples mapeamento para sincronização do ambiente de Desenvolvimento pode gerar dados inconsistentes (não refletem a realidade em Produção) ou simplesmente abortar todo processo.

    Mas de modo geral, o trabalho de cópia de dados quando exige alguma lógica, eu optaria pelo Integration Services (ou um script que seja executado através de um job), de modo que você possa invocar a execução do pacote manualmente ou se sua equipe de desenvolvimento utilizar algum recurso de Continuous Integration (TFS Build Services, Jenkins, etc.) a execução do mesmo possa ser feita via script.

    No cenário que atuo hoje em dia, normalmente restauro um backup do banco de produção no ambiente de desenvolvimento e então aplico os scripts para as mudanças de estrutura. Acho este o melhor cenário nestes casos. Até porque estes novos objetos terão que ser criados em homologação e produção posteriormente, logo, seu script também precisa ser testado.


    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, remember to "Mark as Answer".

    Se achou este post útil, por favor clique em "Votar como útil". Se por acaso respondeu sua dúvida, lembre de "Marcar como Resposta".




    sexta-feira, 18 de novembro de 2016 13:26
  • Deleted
    sexta-feira, 18 de novembro de 2016 13:30
  • Como comentado anteriormente, sobre o assunto há dois livros, gratuitos como ebook, disponíveis na biblioteca da Red Gate: 

    Verifique a parte de versionamento de banco de dados.

    Quanto a manter os dados de desenvolvimento atualizados com os de produção, não me parece uma boa prática, mesmo que não tenha ocorrido a criação ou alteração de objetos. Imagine se em um ambiente de produção o banco de dados tenha 1 TiB de dados; os bancos de dados de desenvolvimento e de homologação também deveriam ter 1 TiB? É óbvio que não.

    Para ambiente de desenvolvimento o que se necessita é de uma amostra dos dados, gerada por extratores de dados. Aliás, há ambientes de desenvolvimento em que não se trabalham com os dados reais mas sim com geradores de amostras, por questões de segurança.

    Cada caso é um caso


        José Diz     Belo Horizonte, MG - Brasil


    José,

    Concordo com as observações e indicações!!!!

    Vale ressaltar que sempre devemos realizar uma limpeza de dados em qualquer ambiente para garantir que todas as regras de negócios, testes e validações estão sendo aplicadas e realizadas da forma mais correta possível, manipular dados sujos pode interferir totalmente no resultado e execução de qualquer ambiente.


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    sábado, 19 de novembro de 2016 12:45
    Moderador
  • Deleted
    domingo, 20 de novembro de 2016 19:29
  • Olá José,

    Fiz como você recomendou, alterei o título para "Discussão", assim vamos ver se o pessoal dá mais sugestões.

    Embora eu concorde com você no aspecto segurança, já tivemos situações aqui que obtivemos resultados inesperados em DEV e HOMOLOG, por não termos os mesmos dados que em produção.

    segunda-feira, 21 de novembro de 2016 10:40