Qual é a melhor prática para implementar o banco de dados dev no sistema live?

1

Meus desenvolvedores em um projeto querem ter o servidor de desenvolvimento em servidor dev sincronizado com o live db em servidores ao vivo, o que eu acho que é uma má idéia. Apesar disso, qual é a melhor maneira de implantar um codebase + db para viver? Até agora eu uso o rsync para dados e exportação / importação simples para o banco de dados. A configuração final consiste em um servidor dev e 2 servidores Live (um nos EUA, um na Europa, para HA / LB). O MariaDB Cluster foi proposto, mas não tenho certeza se quero introduzir a replicação multimestre nessa configuração. Especialmente desde que o servidor 2 Live esteja separado tanto por distância. Além disso, eu tenho que de alguma forma conseguir fornecer a eles um db live do up2date para o servidor dev porque o desenvolvimento obviamente não pode empurrar o db para viver quando estiver antigo (então não haveria entradas no tempo entre export / import). Talvez eu não esteja vendo as árvores na floresta aqui e é bastante simples. O que vocês propõem que eu deveria fazer?

    
por pdanjou 27.11.2015 / 10:52

1 resposta

1

Desde que isso começou a se transformar em uma troca de comentários, pensei em escrever corretamente.

Em primeiro lugar, é um requisito bastante comum para (freqüentemente) sincronizar o banco de dados de produtos em desenvolvimento, de modo que o desenvolvimento esteja procedendo contra algo que se aproxime da realidade. Mas o contrário? Não tenho certeza se já vi isso, e definitivamente não faria isso.

Você está certo ao observar que, com frequência, as alterações no conteúdo do esquema ou do banco de dados exigem que as atualizações no banco de dados do produto coincidam com as alterações no código que estão sendo implementadas no desenvolvimento. Mas um processo sensato de liberação lida com isso desenvolvendo procedimentos para atualizar o esquema, fazer upload de novo conteúdo e / ou modificar o conteúdo existente e implementar esses procedimentos no momento da publicação do código.

Nos ambientes mais bem regulados em que trabalhei, as alterações são literalmente roteirizadas - um longo documento de alteração-teste-resposta é produzido por um desenvolvedor, dizendo em detalhes dolorosos o que deve ser digitado , o que será visto, como deve ser testado e quais resultados são necessários. O script é assinado por um segundo desenvolvedor, para confirmar que ele foi testado em um ambiente de teste limpo e executado por um desenvolvedor terceiro , que não trabalhou no processo. Isso garante que ninguém tente ficar esperto e sair da pista quando algo estranho acontecer. Muitas vezes, um desenvolvedor quarto assinará o roteiro, para dizer que ele confirmou tudo o que foi reivindicado para ser visto e feito.

O script também especifica um procedimento de recuo testado, e isso é executado pelo terceiro desenvolvedor se, em algum momento, as respostas não corresponderem ao que o script espera. Se todo o procedimento passar, o ambiente prod é ressincronizado nos ambientes de teste e desenvolvimento.

Não estou dizendo que todo esse processo é apropriado para o seu ambiente; só isso é para algumas pessoas. Mas você parecia querer saber como as mudanças de esquema e conteúdo são tratadas, além de sincronizar cegamente o dev em prod, então espero que isso dê alguma luz sobre isso. Se você acabar implantando sincronizando dev em prod, certifique-se de que seus backups estejam atualizados e que seus procedimentos de restauração sejam bem testados. Você vai precisar deles.

    
por 27.11.2015 / 12:29