Se tem uma coisa que ninguém quer é um deployment que cause impacto negativo no negócio. Escolher a estratégia certa de deployment não é apenas uma decisão técnica, mas uma necessidade para garantir disponibilidade, estabilidade e experiência do usuário.
Cada mudança no seu sistema pode trazer riscos. Um erro no deploy pode causar downtime, afetar usuários e, pior, gerar perdas financeiras. Para minimizar o “blast radius” – ou seja, o impacto negativo de um erro –, é essencial contar com uma estratégia de deploy bem planejada e que atenda a suas necessidades.
Além disso, é claro que ter uma estratégia robusta de testes é fundamental, pois sem testes a estratégia de deployment somente irá mudar o tempo que você implementa em um erro no seu ambiente (Ex. vai colocando uma carga de 10% para nova versão sem saber se ela esta funcionando como esperado, ai é demais né ?! – sim, é raro mas acontece muito 👀) .
Conforme novas versões vão sendo liberadas, é crucial monitorar as métricas de negócio (podendo ser métricas como os golden signals ou de negócio como taxa de abandono de checkout) dos componentes. Dessa forma, se algo der errado, o deploy pode ser pausado ou revertido rapidamente.
Bom, vamos explorar algumas estratégias de deployment e entender como elas funcionam:
➡️ All at Once / Big Bang
🛠 Como funciona?
- A nova versão é implantada para todos os usuários de uma vez.
- Não há divisão de tráfego entre versões.
✅ Vantagens:
- Simples de implementar.
- Rápido, já que a nova versão é liberada imediatamente.
⚠ Desvantagens:
- Se algo der errado, todos os usuários são afetados.
- Reversão pode ser difícil e demorada.
💡 Exemplo:
Imagine que um e-commerce lança uma nova funcionalidade de checkout. Se houver um erro na implementação, todos os usuários serão impactados ao mesmo tempo, podendo levar a quedas nas vendas.
➡️ Blue/Green Deployment
🛠 Como funciona?
- Duas versões do sistema (Blue e Green) rodam simultaneamente.
- O tráfego de produção sempre aponta apenas para blue OU green
- A atualização é sempre feita na cor sem carga, quando está pronta e testada, o tráfego é alterado para cor com a nova versão
✅ Vantagens:
- Possibilita rollback imediato, bastando redirecionar o tráfego para a versão antiga.
- Reduz downtime.
⚠ Desvantagens:
- Custo operacional maior (duas versões rodando ao mesmo tempo).
- Exige um bom balanceador de carga.
💡 Exemplo:
Se um banco online quiser atualizar sua interface de login, ele pode manter a versão antiga ativa enquanto testa a nova para um grupo seleto de usuários. Se não houver problemas, toda a base de usuários é migrada.
➡️ Canary Deployment (Gradual Deployment)
🛠 Como funciona?
- A nova versão é liberada gradualmente para uma pequena porcentagem dos usuários. (Ex. 5 ondas de 20%, ou 10 ondas de 10%)
- Se tudo estiver funcionando bem, o tráfego vai sendo aumentado até que todos estejam na nova versão.
✅ Vantagens:
- Permite testar a nova versão em produção com menor blast radius
- Impacto reduzido em caso de falhas.
⚠ Desvantagens:
- Necessidade de observabilidade avançada para monitorar métricas da nova versão.
- Dependendo das funcionalidades da aplicação, pode gerar inconsistência pois requisições serão distribuidas para a versão N e N-1
- rollout geralmente leva mais tempo
💡 Exemplo:
Uma empresa SaaS precisa atualizar sua API crítica. Em vez de substituir todas as instâncias de uma vez, ela inicia o deployment em apenas 5% dos servidores. Se os logs e métricas indicarem que a nova versão está estável, o rollout é expandido progressivamente até alcançar 100% da base.
➡️ Shadow Deployment
🛠 Como funciona?
- Toda requisição gerada é duplicada, uma vai para a versão em produção e a outra para um ambiente “shadow / nova versão”
- A nova versão recebe uma copia do tráfego real, mas as respostas não são servidas aos usuários finais.
- Isso permite avaliar o comportamento da nova versão sem afetar a produção.
✅ Vantagens:
- Identifica problemas antes que a nova versão chegue aos usuários.
- Ideal para testar carga e performance em ambiente real.
⚠ Desvantagens:
- Custo elevado, pois duas versões estão processando requisições ao mesmo tempo.
- Difícil capturar todos os cenários possíveis sem um conjunto amplo de testes.
💡 Exemplo:
Uma fintech quer testar um novo motor de processamento de transações. Ele pode rodar em Shadow Mode para validar se está pronto antes de assumir o processamento real dos pagamentos.
Note: Tem uma vertente aqui que é o shadow traffic, praticamente mesma coisa, porém não são 100% das requisições que são duplicadas, apenas uma amostragem é enviada para nova versão.
🔥 Feature Flag 🔥
Feature Flags não são exatamente uma estratégia de deployment, mas sim uma técnica poderosa para ativar ou desativar funcionalidades em tempo real sem precisar de um novo deploy. A ideia é fazer o deploy de uma versão segura do código onde a nova funcionalidade já está presente, mas desativada por padrão. Quando for o momento certo, basta ativá-la remotamente sem necessidade de uma nova implantação.
Feature flag é muito usado por empresas grandes e softwares críticos, exige uma maturidade alta porém os benéficos são grandes. Você consegue realizar uma estratégia de deploy canary simples e depois ativar/desativar uma funcionalidade em segundos. Isso trás muitos beneficios e reduz consideravelmente os impactos .
💡 Exemplo:
Imagine que um banco digital quer lançar um novo fluxo de autenticação para seus clientes. Em vez de liberar a funcionalidade para todos de uma vez, ele faz o deploy da nova versão com o código já preparado, mas desativado via Feature Flag. Assim, ele pode ativar a funcionalidade apenas para um pequeno grupo de usuários internos, coletar feedback, corrigir eventuais problemas e, só então, expandir a ativação para toda a base de clientes de forma segura e controlada.
🚀 Conclusão
Não existe uma única estratégia certa. A escolha depende do seu contexto, do risco aceitável e da maturidade do seu processo de deployment. O importante é sempre minimizar impacto e garantir uma experiência fluida para os usuários.
E aí, qual dessas estratégias você já utilizou? Tem alguma preferida? Conta pra gente!
Se curtiu esse conteúdo e quer aprender mais sobre arquitetura de software e um nível bem mais aprofundado, venha fazer parte da
Comunidade de Arquitetura Descomplicada (CaD)! Saiba mais em https://mugnos-it.com/cad/ 🚀
Até a próxima!
Abraços,
Douglas Mugnos
MUGNOS-IT
