Usamos uma série de máquinas virtuais, pelo menos uma para cada servidor cliente ao vivo, que é mantida em sincronia com as máquinas ao vivo (além de alguns dos dados serem copiados, por isso não estamos trabalhando com informações pessoais ou confidenciais ).
Qualquer série de alterações que devem ir a uma máquina de produção é reunida em um patch que consiste em quaisquer arquivos / scripts necessários e um script (um script de shell geralmente para um ambiente Unix-a-like, um arquivo em lote ou script vbs ou script powershell no Windows) que aplica esses arquivos / scripts adequadamente. Em seguida, pegamos a VM relevante, atualizamos seu (s) banco (s) de dados a partir de uma cópia da produção se a cópia da VM estiver muito desatualizada (lembrando-se de executar novamente os scripts SQL relevantes para limpar ou randomizar dados confidenciais) e instantâneo do mesmo nesse estado (os snapshots são suportados pelo VirtualBox e pela maioria dos produtos VMware, incluindo o "servidor vmware" gratuito e, provavelmente, a maioria das outras soluções de virtualização também). Em seguida, aplicamos o patch como faríamos ao servidor de produção executando o script de controle principal. Se houver erros ao aplicar as alterações, a VM será retrocedida para o instantâneo (o que leva, no máximo, algumas dezenas de segundos) para que o patch possa ser atualizado e testado novamente. Isso se repete conforme necessário até que o patch seja aplicado corretamente. Uma vez feito isso, alguns testadores são solicitados a tentar garantir que o novo material esteja funcionando e que outras coisas antigas não tenham sido quebradas (quanto tempo você gasta depende do escopo e da gravidade das mudanças e do seu nível de paranóia). Se forem encontrados problemas, o ciclo de retrocesso, edição e reaplicação será repetido até que tudo pareça bem. Uma vez que tudo parece bem, supondo que o tempo permita, um último ciclo de reversão-correção-teste é executado just-in-case. Uma vez feito isso, esperamos que você tenha um patch que possa ser aplicado ao ambiente de produção executando um único script com parâmetros apropriados (por exemplo, senhas relevantes, como credenciais de autenticação nas VMs de teste devem diferir daquelas nas máquinas de produção) e você pode ter certeza de que ela será aplicada de forma limpa e terá o efeito desejado sem (ou o menos possível) os indesejáveis.
Sempre faça backups novos antes de aplicar qualquer coisa significativa a um sistema de produção, independentemente de quanto tempo você tenha gasto testando a atualização, e sempre planeje pelo menos um pouco de tempo de inatividade durante o qual você pode manter a outra Os usuários saem e dão ao (s) sistema (s) atualizado (s) resultante (s) mais um teste de paranoia (e os revertem para o backup mais recente se algo der errado - se o ambiente de produção for virtualizado, o recurso de captura instantânea também pode ser útil aqui).
Como um processo geral, isso pode funcionar em qualquer ambiente.