Ajudo em um grande site de jogos na Austrália. Realizamos competições das 7h da manhã ao horário local, no dia seguinte, todos os dias da semana. Não pulamos um dia desde que o site foi lançado. Naturalmente, isso torna a manutenção extremamente difícil de executar e descobrimos que nosso servidor de armazenamento temporário está com até 50 confirmações à frente de nosso ramo de produção. Normalmente, o desenvolvedor principal precisa acordar extremamente cedo para mesclar ramificações e garantir que tudo esteja funcionando corretamente.
Estamos tentando tornar nosso site de preparação o mais semelhante possível ao site de produção, mas só podemos torná-lo semelhante.
Nosso site é baseado no Laravel com um servidor Node.JS em tempo real. Estamos usando o Laravel Forge.
Alguém tem alguma sugestão de como poderíamos enviar atualizações com mais frequência? Estamos abertos a tudo.
fonte
Respostas:
Você pode fazer várias coisas para melhorar seu processo de implantação. Alguns deles são:
Verifique se seu código está bem testado.
Idealmente, você deve ter 100% de cobertura de teste de unidade, bem como testes de integração para todos os cenários possíveis.
Se você não conseguiu, provavelmente deve largar tudo e cuidar disso.
Examine o desenvolvimento orientado pelo comportamento.
Ter um conjunto de testes completo permitirá que você ...
Execute a integração contínua.
Sempre que alguém comete uma alteração, o CI pode executar automaticamente o conjunto de testes nele. Se o conjunto de testes for aprovado, ele poderá implantar imediatamente (ou agendar uma implantação). Para alterações que não exigem nenhuma alteração significativa em seus bancos de dados, isso economiza muito tempo e dor de cabeça.
No caso de um problema, o IC também pode oferecer uma reversão com um clique.
O IC é muito menos útil se o seu conjunto de testes não estiver completo e correto, pois toda a premissa depende de poder validar seu código de forma automatizada.
Faça atualizações atômicas.
Idealmente, você não deve apenas copiar novos arquivos pelos antigos no servidor de produção. Em vez disso, use uma ferramenta como o capistrano, que copia todos os arquivos para um novo local e, em seguida, usa um link simbólico para apontar para a implantação desejada. A reversão é instantânea, pois envolve simplesmente alterar o link simbólico para apontar para a implantação anterior. (Embora isso não abranja necessariamente a migração do banco de dados.)
Verifique também se os contêineres como o Docker podem ajudá-lo.
Faça alterações menores e mais frequentes.
Se você tem testes, IC ou nada, isso por si só pode ajudá-lo significativamente. Toda mudança deve ter sua própria ramificação git, e uma implantação deve ter o mínimo de alterações possível. Como as alterações são menores, há menos chances de dar errado durante uma implantação.
Nessa nota, faça as alterações mais isoladas sempre que possível. Se você fez uma alteração no jogo Omaha e não afeta o Texas Hold'em, o 5 card stud ou qualquer outra coisa, esse é o único jogo que precisa ser suspenso para manutenção.
Analise qualquer coisa de longa duração.
Você mencionou que algumas partes de suas implantações demoram muito tempo. Provavelmente, isso é alterações no esquema do banco de dados. Vale a pena examinar o DBA no seu banco de dados, juntamente com cada alteração de esquema, para ver o que pode ter um desempenho melhor.
Peça a um especialista no assunto para examinar qualquer outra parte de uma implantação que considere grandes blocos de tempo.
Trabalhe em horários estranhos.
Você já pode estar fazendo isso, mas vale a pena mencionar. Os desenvolvedores (e administradores de sistemas!) Não devem trabalhar mais "9 para 5", especialmente para uma operação 24x7. Se alguém espera passar a noite cuidando de uma implantação, resolvendo problemas e mantendo um horário diurno, suas expectativas são irrealistas e você está configurando essa pessoa para o esgotamento.
fonte
Parece que você diz que tem uma janela de manutenção de 1h às 7h todos os dias que o problema não é hora, mas conveniência. Isso é normal e muitas pessoas lidam com isso como parte dos negócios.
Você pode ter dois sistemas (ou mais de back-end) com um front end que direciona o tráfego para o que estiver ativo no momento. Quando estiver satisfeito com o lançamento de uma versão, você avisa o front end para mudar para o novo sistema. deve ser fácil criar um script e demorar um pouco.
Agora você tem a opção de deixar o sistema antigo como está, para que possa voltar atrás ou atualizá-lo para que possa ser usado como sobressalente do sistema ativo até a hora de criar / testar as próximas atualizações.
fonte
Alterando as outras respostas: Você deve seguir o modelo de implantação azul esverdeado . Quando você deseja liberar uma nova versão, implanta-a em um site de preparo interno. Em seguida, você pode executar testes automatizados no site de produção da próxima versão. Quando os testes passam, você aponta o balanceador de carga para usar o novo site.
Isso ajuda da seguinte maneira:
Todos os outros problemas mencionados por você e outras pessoas tornam-se menos graves quando você pode implantar a qualquer momento, sem estresse. O modelo de implantação azul esverdeado é uma solução bastante completa para problemas de implantação.
fonte
O que você fará se o seu data center principal sofrer uma interrupção, o que acontece em todos os data centers de tempos em tempos? Você pode aceitar o tempo de inatividade, o failover para outro data center, o modo ativo / ativo em vários data centers o tempo todo ou pode ter algum outro plano. Seja qual for, faça-o quando fizer lançamentos e, em seguida, você poderá desativar o seu datacenter principal durante um lançamento. Se você estiver preparado para ter um tempo de inatividade quando o data center tiver uma interrupção, estará preparado para ter um tempo de inatividade, para que não seja um problema durante uma liberação.
fonte
Para adicionar às respostas anteriores:
Use uma estratégia de implantação que permita reversões e comutação instantânea, o Capistrano ou praticamente qualquer outro sistema de implantação ajudará nisso. Você pode usar coisas como instantâneos de banco de dados e links simbólicos de código para poder reverter rapidamente para um estado anterior.
Use o gerenciamento completo da configuração, não deixe nada gerenciado manualmente. Sistemas como SaltStack, Ansible e Puppet são exemplos. Eles também podem ser aplicados às configurações de contêiner do Docker e às caixas vagrantes.
Use HA para garantir que você possa enviar solicitações ao atualizar um nó. Se a atualização falhar, basta descer o nó e, quando for revertida, traga-a de volta e sua solução de HA notará e enviará solicitações para o nó novamente. HAProxy é um exemplo, mas o nginx também funciona bem.
Verifique se o aplicativo pode lidar com instâncias simultâneas, usadas repositórios de dados com versão central para dados que não são de código que precisam ser armazenados em disco, como cache. Dessa forma, você nunca terá um aplicativo atualizado executado em cache para arquivos de uma versão diferente. Isso seria feito além de limpar caches e fazer aquecimento de cache, é claro. (A coisa do cache é apenas um exemplo)
Normalmente, eu configuro fluxos de trabalho em que os gerentes de equipe podem aprovar solicitações de mesclagem para uma ramificação especial que faz todo o material normal de IC, mas, como uma última etapa adicional, também começa a avançar para os nós de produção. Basicamente, o que você faz é executar uma implantação manual do IC em uma instância de produção. Se essa instância não gerar respostas inválidas, interromper ou fazer coisas estranhas nos seus dados, você fará upgrade em massa de todos os nós usando a solução de CI de sua escolha. Dessa forma, se uma implantação funcionar, todas as implantações funcionarão para uma tag / confirmação específica.
No momento, parece que você está executando um aplicativo de produção em um único nó, com um processo de implantação, uma origem e um destino. Isso praticamente significa que cada etapa desse fluxo de trabalho é um ponto de falha que, por si só, pode quebrar o site. Garantir que isso não possa acontecer é a base de todos os processos de IC, HA e failover. Não execute apenas um nó, não execute apenas um processo de alta disponibilidade, não execute apenas um endereço IP, não execute apenas uma CDN etc. Pode parecer caro, mas colocando uma duplicata do que você já possui em um rack em um servidor com sua própria conexão geralmente custa menos de uma hora de inatividade em um site comercial.
fonte
Concordo globalmente com Michael em todos os seus pontos ( /server//a/739449/309477 ).
Na minha opinião, a primeira melhoria que você deve fazer é usar uma ferramenta de implantação (Capistrano).
Isso permitirá que você implante de forma pacífica e mude para a versão mais recente instantaneamente. Se algo der errado, você poderá voltar para a versão de trabalho instantaneamente, simplesmente alterando o link simbólico atual para uma versão de trabalho.
E o Capistrano é muito rápido para lidar primeiro (comparado a começar a usar testes e IC, que será um investimento de tempo maior).
Em segundo lugar, se o dinheiro não é seu principal problema, você deve ter um servidor de desenvolvimento iso-prod para testar seu aplicativo antes de implantá-lo na produção. Use uma solução industrial (Ansible, Chef, Puppet) para gerenciar instâncias do VPS.
fonte