Pra quem quer trabalhar entregando aplicações com alta disponibilidade, é fundamental saber as maneiras mais eficientes de deploy. Assim, você garante que sempre que você precisar atualizar seu software, o usuário não vai comprometer a experiência do usuário.
As estratégias de deploy descritas a seguir são:
- Recreate deploy
- Ramped deploy
- Blue Green deploy
- Canary deploy
- Teste A/B
- Shadow deploy
===================================================================================================
A estratégia Recreate Deploy consiste em interromper completamente a versão atual da aplicação antes de implantar a nova versão. Nesse modelo, todos os serviços existentes são encerrados e substituídos pelos novos de forma sequencial.
Parar a versão atual: Todos os pods, containers ou instâncias da versão antiga são encerrados. Implantar a nova versão: A nova versão da aplicação é iniciada a partir do zero.
Simplicidade: Fácil de implementar e gerenciar, pois não há coexistência de múltiplas versões.
Downtime inevitável: Durante o intervalo entre a interrupção da versão antiga e a inicialização da nova, a aplicação estará indisponível.
Sem rollback imediato: Em caso de falha, é necessário reimplantar manualmente a versão anterior.
Essa estratégia é mais apropriada para ambientes que podem tolerar interrupções temporárias e em situações onde a implantação precisa ser simples e direta.
A estratégia Ramped Deploy (ou Rolling Deploy) consiste em atualizar a aplicação gradualmente, substituindo a versão antiga pela nova de forma incremental.
Atualização em pequenos lotes: Um conjunto de instâncias (pods, containers, servidores) é substituído pela nova versão enquanto o restante continua funcionando com a versão antiga.
Progresso controlado: A atualização prossegue em lotes até que todas as instâncias estejam rodando a nova versão.
Disponibilidade contínua: A aplicação permanece acessível durante o processo de deploy.
Risco reduzido: Caso algo dê errado, é possível interromper o processo antes que toda a aplicação seja afetada.
Rollback mais simples: Reverter para a versão anterior é mais fácil, pois apenas as instâncias atualizadas precisam ser restauradas.
Essa estratégia é ideal para sistemas que exigem alta disponibilidade e não podem sofrer interrupções significativas durante a implantação.
A estratégia de Blue-Green Deploy consiste em manter duas versões do ambiente de produção: uma ativa (Blue) e outra inativa (Green), permitindo alternar entre elas para realizar a implantação de forma segura.
Preparação do ambiente Green: A nova versão da aplicação é implantada no ambiente Green, que é configurado e testado sem afetar os usuários do ambiente Blue.
Switch de tráfego: Após os testes, o tráfego dos usuários é redirecionado do ambiente Blue para o Green.
Ambiente Blue como backup: O ambiente Blue permanece disponível como backup, facilitando um rollback imediato em caso de problemas.
Zero downtime: Não há interrupção no serviço durante a transição.
Rollback instantâneo: Caso a nova versão apresente falhas, é fácil redirecionar o tráfego de volta para o ambiente Blue.
Maior custo: Exige recursos adicionais para manter dois ambientes completos.
Essa estratégia é ideal para sistemas críticos que exigem alta confiabilidade e permitem custos adicionais para garantir maior segurança nas implantações.
A estratégia de Canary Deploy consiste em liberar uma nova versão da aplicação para um pequeno subconjunto de usuários inicialmente, monitorando o desempenho antes de expandir gradualmente para toda a base de usuários.
Implantação parcial: A nova versão é implantada para uma pequena porcentagem de servidores ou usuários (os "canários").
Monitoramento e validação: O comportamento da nova versão é observado em produção para detectar problemas ou falhas.
Expansão gradual: Caso os testes sejam bem-sucedidos, a nova versão é implantada para um número maior de usuários até atingir toda a base.
Risco reduzido: Problemas na nova versão afetam apenas uma pequena parte dos usuários inicialmente.
Rollback fácil: Caso ocorra uma falha, é possível interromper a implantação e manter a maior parte dos usuários na versão antiga.
Controle granular: Permite ajustar a porcentagem de tráfego direcionada à nova versão conforme a confiança aumenta.
Essa estratégia é ideal para sistemas com uma grande base de usuários e que precisam testar alterações de forma controlada em produção.
A estratégia de Teste A/B é usada para comparar duas ou mais versões de um sistema ou funcionalidade, apresentando cada versão a diferentes grupos de usuários e analisando o desempenho com base em métricas específicas.
Criação de versões: Duas ou mais variações de uma funcionalidade (A e B) são implementadas.
Divisão de usuários: O tráfego é dividido entre os grupos de teste. Por exemplo, metade dos usuários acessa a versão A e a outra metade a versão B.
Coleta de métricas: Dados de interação, como taxas de conversão, engajamento ou vendas, são monitorados.
Análise e decisão: Com base nos resultados, a versão que apresenta melhor desempenho é escolhida.
Foco em resultados: Avalia diretamente qual versão é mais eficaz para os usuários.
Experimentação controlada: Reduz o risco, permitindo mudanças baseadas em dados reais.
Demanda por tráfego significativo: Para obter resultados confiáveis, é necessário um volume significativo de usuários.
Essa estratégia é amplamente usada em marketing digital e otimização de interfaces, ajudando a tomar decisões baseadas em dados concretos e não em suposições.
A estratégia de Shadow Deploy consiste em implantar uma nova versão da aplicação em paralelo à versão atual, mas sem expor a nova versão aos usuários finais. O tráfego real é "espelhado" para a nova versão apenas para testes.
Deploy paralelo: A nova versão da aplicação é implantada em um ambiente separado.
Espelhamento de tráfego: O tráfego dos usuários é duplicado (copiado) e enviado para a nova versão, enquanto a versão antiga continua atendendo os usuários.
Monitoramento e validação: A nova versão é monitorada para validar seu comportamento e desempenho com base no tráfego real.
Sem impacto no usuário: As respostas da nova versão não afetam os usuários, servindo apenas para testes internos.
Sem risco para os usuários: Como a nova versão não é exposta, possíveis falhas não afetam a experiência do usuário.
Teste realista: Permite validar o comportamento da aplicação com tráfego real, garantindo maior confiabilidade.
Custo adicional: Exige recursos extras para manter a nova versão rodando em paralelo.
Essa estratégia é ideal para testar aplicações críticas em cenários realistas antes de uma implantação completa.