O que você pode fazer para diminuir o número de erros de implantação de um site ativo?

Tenho certeza de que muitos de vocês tiveram esse problema. Um site ou aplicativo da web está em execução e está ativo. Você deseja fazer o upload da próxima versão, mas ainda não descobriu tudo, como definir um valor como false no arquivo de configuração, inserir outro registro no banco de dados e fazer muitas coisas menores que às vezes podem contar com 20 ou mais parâmetros.

Assim que você carrega a nova versão, tudo quebra. Agora, a solução do problema pode levar apenas 20 minutos, mas o estresse geral que você tolera e os danos financeiros e de boa vontade da empresa às vezes não são esquecíveis.

Quais são as maneiras de reduzir esses tipos de bugs que surgem da configuração inicial da implantação da nova versão?

PS: Por favor, não mencione as listas de verificação, porque já as temos. O problema das listas de verificação é que elas sempre devem ser atualizadas, mas não serão.

Duas coisas:

• Ambiente de temporariedade, semelhante ao ambiente ativo em que você testa implantações.
• Amplo teste desse ambiente após a implantação. Automatizado e não automatizado.

Há outras coisas que podem ser feitas.

Sugiro ler a série de blogs de 5 partes sobre implantação automatizada de Troy Hunt. As ferramentas que ele usa são específicas da pilha do MS, mas os conceitos são universais.

Gostaria de saber por que ninguém mencionou o controle de versão - que é uma das maneiras mais importantes de evitar problemas ao atualizar / atualizar.

Primeiro, sua implantação deve ser apenas um clone da ramificação estável em seu repositório. Tudo, incluindo arquivos de configuração, arquivos SQL, scripts de instalação / atualização DEVE ser controlado por versão.

Segundo, você precisa ter "algum tipo de" área de preparação - pode ser qualquer coisa - um servidor local, um servidor de nuvem virtual temporário que você acabou de gerar, uma configuração muito simples de host virtual ou um aplicativo personalizado completo que você mantém junto com o aplicativo principal. A diferença entre essa "área de preparação" e a sua "área de desenvolvimento" é que a primeira modela mais de perto (ou simula) seu ambiente de implementação real. Por exemplo, você pode desenvolver no PHP 5.3.x com o módulo Apache, mas como seu host é o PHP 5.2.x com FCGI, a área de preparação deve ser a mesma.

Em seguida, você primeiro escreve e testa suas atualizações em seu ambiente de desenvolvimento. Mesclar essas alterações no repositório da área de temporariedade e testar novamente. Nesse ponto, você pode fazer alterações na sua configuração para se adequar à sua implantação - já que é controlada pela versão, nada será perdido e você sempre pode reverter em caso de problemas.

Finalmente, mescle as alterações da área de preparação na sua cópia de implantação ao vivo.

A complexidade da sua área de preparação deve refletir a complexidade e o escopo do seu aplicativo. Mas, em qualquer caso, o controle de versão é indispensável.

Obviamente, se você não usar o controle de versão - nada disso se aplica -, é tão ingênuo quanto escrever um banco de dados no Logo.

Conforme sugerido, use um sistema de preparação . Isso oferece a oportunidade de testar suas alterações em um ambiente ativo.

Isso traz outro ponto: tenha testadores . Testar as coisas que escrevi para mim não encontra tantos erros como quando alguém testa meu aplicativo.

Outra coisa: automatize seu processo de implantação . Faça migrações de banco de dados com o ant migrate, implante a versão mais recente automaticamente a partir do svn via capistrano etc. Especialmente para sites que precisam de alguma configuração, as etapas manuais necessárias para a implantação são um pesadelo e a possibilidade de algo dar errado.

Para algo que absolutamente, positivamente não deve ser interrompido, considere ter um sistema A e B e use um balanceador de carga para rotear todas as solicitações para A enquanto você atualiza e testa B e, em seguida, direciona tudo para B enquanto atualiza A.

Para obter pontos de bônus, adicione C e garanta que seus sistemas estejam geograficamente separados, para que um terremoto não elimine 2 deles simultaneamente.

Para muitas aplicações, admito que isso seja um exagero.

Isso também complica qualquer gerenciamento de transações que você precise fazer, mas os problemas não são intransponíveis.

Sim, você precisa de um ambiente de teste ou armazenamento temporário em que execute todas as etapas, mas é essencial manter arquivos de configuração separados para ambientes separados.

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

Basicamente, nos meus scripts de construção e implantação, pego uma propriedade de ambiente que busca os arquivos de metadados específicos do ambiente, como arquivos XML, e os substitui no meu local de construção antes do empacotamento. Além disso, em meus scripts de implantação, procurarei todos os arquivos SQL nas atualizações do banco de dados e os executarei no banco de dados configurado para esse ambiente também.

Eu poderia fazer isso com uma tarefa de compilação personalizada, mas na verdade eu apenas uso alguns testes JUnit para fazer isso por mim. Se ocorrer alguma exceção SQL, o teste falhará e, portanto, a implantação falhará. De um modo geral, os scripts SQL possuem inteligência, se os dados necessários já existirem no ambiente, eles ignoram a inserção ou atualização.

Também tenho um diretório semelhante para scripts em lote ou shell que preciso executar para um ambiente específico.

O que diz tudo na sua pergunta é o seguinte: eles sempre devem ser atualizados, mas não serão.

Essas configurações direcionam suas compilações e implantações automatizadas; portanto, se você não as atualizar, suas compilações falharão e seu gerente será enviado por e-mail sobre isso. É tão importante para a equipe manter as configurações de compilação e implantação de uma versão específica quanto para o check-in do código que é compilado. Qualquer infração quebra a compilação.

Em suma, uma maior adoção dos princípios de integração contínua (IC) ajudará a remover a dor das liberações de produção.

1) Implante primeiro no site de teste e teste suas alterações

2) Tenha toda a configuração em um arquivo de configuração (web config ou similar). Essa configuração deve ser específica para o aplicativo e nunca substituída. Quaisquer alterações são então calibradas, em vez de esquecer de alterar algo que deve ser diferente do teste.

Além das excelentes sugestões acima, para ter um ambiente de pré-produção e usar testes automatizados:

Reduza a complexidade da base de código. Menos código, geralmente, significa menos erros e mais facilidade para encontrá-los. Essa é a filosofia por trás da refatoração, separação de preocupações e assim por diante.

Segmente a base de código . Uma abordagem comum é separá-lo em:

• algumas partes principais que mudam lentamente e são compartilhadas em todo o site
• muitas partes da folha que podem mudar mais rapidamente, mas cada uma afeta apenas uma parte menor do site

Esse entendimento da sua base de código permite que você concentre seu desenvolvimento e teste nas partes principais, pois os bugs terão o efeito mais drástico.

Uma versão bem executada é sobre planejamento e comunicação. Portanto, antes de realizar um lançamento, considere estas perguntas:

1. Quanto tempo leva para o lançamento e há riscos em permitir que as pessoas continuem a interagir com o meu produto enquanto o lançamento está em andamento? Se houver um risco para o sistema, considere colocar o sistema offline e colocar a mensagem "O sistema está em manutenção no momento".

2. Há algum cliente que você precise notificar sobre o lançamento com antecedência? Preciso contar a eles sobre uma possível interrupção do serviço ou degradação do desempenho enquanto a versão está em andamento? Pessoalmente, eu sempre errei ao exagerar na comunicação e informar a todos os clientes sobre uma próxima versão ou janela de manutenção em um blog público ou em um local semelhante.

3. Quais são meus planos de contingência caso o lançamento dê errado? Por exemplo, se a versão for ruim, devemos reverter e restaurar o sistema da maneira que era para minimizar qualquer momento em que estamos offline? E, em caso afirmativo, as etapas para reverter um release estão bem documentadas? Ou devo ter as pessoas certas de plantão ou em mãos para ajudar na solução de problemas, caso ocorram. Pessoalmente, acho que a melhor maneira de abordar o planejamento de qualquer release é assumir que algo dará errado com o release. Dessa forma, eu me forcei a pensar sobre algumas dessas questões antes do tempo.

Em seguida, quando se trata de executar um release, uma das melhores maneiras de garantir que ele funcione sem problemas é praticar, praticar, praticar e documentar tudo o que você encontrar ao longo do caminho. Portanto, muito antes da implantação do novo código na produção, pratique a implantação do código em um ambiente de teste seguro e adequadamente protegido por sandbox. Peça à pessoa que será responsável pela implantação na produção, execute a implantação do teste na preparação. Considere isso o seu ensaio geral e conduza-se como faria se isso fosse real. Documente tudo o que você faz a cada passo do caminho; documente todos os comandos que você executa, qualquer código SQL que você executa, quaisquer arquivos que você modifica e como os modificou e, para cada etapa ao longo do caminho, documenta o que você espera ver se o procedimento é executado corretamente. Se e quando você encontrar algum tipo de problema, documente o que você fez para resolvê-lo.

Em seguida, a implantação prática está concluída, examine suas anotações e veja se você pode refinar o processo para eliminar erros. Então faça tudo de novo . Continue praticando até a execução de uma liberação se tornar tão rotineira quanto seguir uma simples folha de instruções, como "faça login nesta máquina, execute este comando; depois faça login no banco de dados e execute este comando SQL; depois ..."

Listadas acima, estão as coisas que uma equipe de gerenciamento de operações ou release pode fazer para ajudar um release a funcionar sem problemas. Mas o que a engenharia pode fazer para ajudar a minimizar os riscos em uma liberação?

1. Mantenha os lançamentos pequenos. Simplificando, quanto mais complexo o conjunto de alterações de código contidas em uma versão, mais arriscado será a versão. Faça um favor à sua equipe de operações planejando ter um número maior de lançamentos pequenos, em vez de um número menor de lançamentos grandes no mesmo período de tempo.

2. Teste, teste, teste. Não apenas teste seu código em seu ambiente de controle de qualidade, use o ambiente de teste para testar seu software também. Frequentemente, existem bugs que têm pouco ou nada a ver com o código em si, mas que têm uma causa raiz que reside na configuração do próprio ambiente (ou em alguma mistura dos dois). Para encontrar esses problemas, você precisa testar seu código em um ambiente que espelha de perto a produção, também conhecido como teste.

Como última palavra, às vezes o mais importante não é o que fazemos para impedir que as coisas dêem errado, mas é como nos comportamos quando elas dão errado. Portanto, acho importante criar uma cultura em sua empresa em torno da transparência operacional. Não tente esconder problemas dos clientes, seja próximo. Use o Twitter ativamente para informar aos clientes se há problemas que sua equipe de operações esteja ciente e trabalhando para resolver (o Lighthouse é incrível nisso!). Considere publicar uma página de "status" para o seu serviço, à qual os clientes podem fazer referência, para ver se há algo errado (o TypePad oferece um ótimo exemplo disso). Resumindo, sempre erre no lado da supercomunicação. Seus clientes agradecerão por isso.

Muitas respostas aqui já explicam como implementar sua solução específica para o problema, mas, até onde eu sei, o problema real não é o de migrar / atualizar corretamente um site. Pode ser que o design / arquitetura por trás dele seja frágil.

Se isso for verdade, você terá que ajustar a arquitetura do seu sistema para que seja robusta o suficiente para continuar funcionando adequadamente, mesmo que as definições de configuração sejam alteradas ou não definidas adequadamente e que degrada normalmente se ocorrerem. Idealmente, se você adicionou uma nova funcionalidade ou alterou a funcionalidade antiga de uma maneira que exija uma nova coluna do banco de dados, seu site funcionará mesmo se a coluna estiver ausente (talvez sem a nova funcionalidade ou com uma forma degradada da funcionalidade antiga) . Seu cliente não deve estar perdendo dinheiro - na pior das hipóteses, ele pode não estar recebendo dinheiro novo das melhorias que você colocou.

Se o seu sistema for frágil o suficiente para que as definições de configuração possam causar problemas sérios, as atualizações do programa não serão as únicas fontes de problemas - e descobrir como fazer as atualizações com segurança só aumentará o dano que ocorrerá quando ocorrer uma falha. uma fonte diferente.