Fazer deploy para produção a cada mudança pode dar medo, mas não fazer deploy direto para produção é mais assustador.
Este é o processo que eu conduzia na Amazon, liderando um time que fazia deploy para centenas de milhões de clientes. Por meio da minha consultoria, já levei times de engenharia desde deploys em releases quinzenais agendadas até entregar a cada merge.
Vamos começar pela parte óbvia:
Você vai causar uma indisponibilidade. Não é uma questão de se, mas de quando.
Nenhuma quantidade de testes unitários, testes de integração, dogfooding, testes end-to-end, ou sacrifícios aos deuses do deploy vai pegar todos os bugs.
O teste que foi feito na sua feature há uma semana não foi testado com as mudanças mais recentes do seu colega de time.
Seu teste foi feito contra a versão de pré-produção do serviço do seu colega, que agora mudou e contém uma mudança incompatível com versões anteriores.
Quanto mais você espera, mais mudanças se acumulam em uma release. Se precisar fazer rollback, você terá que reverter duas semanas de mudanças em vez de 1 a 2 horas.
Se aceitarmos a premissa de que uma indisponibilidade é inevitável, faz muito menos sentido dedicar recursos massivos para fazer QA de uma release. Em vez disso, devemos focar nossos recursos em monitorar e observar a release e estar preparados para lidar com uma indisponibilidade quando ela acontecer.
Agora, vamos ver como chegar lá:
Pré-requisitos:
CI/CD
Testes importam muito menos do que você imagina. Testes não conseguem provar que sua mudança é segura em produção. Nada consegue. O que os testes fazem é tornar a falha barata. Um bug pego no CI custa minutos. Um bug pego em produção custa sua noite fazendo rollback.
Então rode a suíte completa em cada merge, ou pelo menos como parte do pipeline: testes unitários, de integração, end-to-end. Quanto mais longe o bug viaja no pipeline, mais caro é resolvê-lo.
Monitoramento/Observabilidade
O objetivo do jogo é conseguir detectar uma regressão o mais rápido possível. Para isso, você precisa ter um monitoramento excelente. Isso se traduz em:
- métricas: erros, latência, disponibilidade
- logs com IDs de correlação
- alarmes para sev-3 e sev-2 (paging) configurados com base nos dois itens acima
Ajustar os limites dos alarmes tem um pouco de arte e ciência. É um equilíbrio entre sensibilidade e velocidade de resposta em um incidente real. Sua meta de tempo para alerta em sev-2 deve ser de 5 a 10 minutos.
No começo, você provavelmente vai errar e ser sensível demais. Infelizmente, isso se aprende principalmente por tentativa e erro, então é provável que você tenha alguns chamados às 2h da manhã no início.
Feature Flags
Para qualquer mudança com risco, você deve fazer o deploy dela atrás de uma feature flag / configuração remota. Uma feature flag permite que você reverta e desative qualquer mudança em poucos minutos, em vez de precisar reverter o deployment inteiro. Além disso, se o seu serviço de feature flags permitir (e deveria), você pode fazer o rollout incremental da feature por porcentagem ou por coorte, reduzindo ainda mais o impacto de uma mudança ruim.
Isso permite desacoplar o deploy do código da ativação do código. É sutil, mas é um divisor de águas para reduzir risco.
Nota: você vai precisar de um processo para limpar essas flags. O ideal é criar um ticket de remoção para cada flag criada. Caso contrário, quando seu serviço de feature flags cair (e vai cair), você terá uma regressão significativa. Me pergunte como eu sei.
Rollback Automático (Circuit breaker no momento do deploy)
Um circuit breaker no momento do deploy é uma funcionalidade que permite reverter o deployment se você observar uma contagem ou porcentagem de erros enquanto faz o rollout pela frota. A maioria dos provedores de nuvem já oferece isso com uma simples caixa de seleção.
Mudanças Compatíveis com Versões Anteriores
Você já deveria estar fazendo isso, mas dar deploy a cada commit força a prática. Durante um rolling deployment, você terá a versão antiga e a nova rodando ao mesmo tempo. Cada mudança precisa funcionar junto com a versão anterior. Seu truque de fazer deploy à meia-noite para evitar isso não funciona mais.
Estratégias de Deployment
Agora, com tudo isso em prática, podemos passar por algumas estratégias de deployment que ajudam a reduzir o risco ao fazer o rollout das suas mudanças.
One box (canário)
Um deployment one box (canário) faz o deploy das suas mudanças em uma única instância dentro da frota maior. Isso permite reduzir o impacto de qualquer mudança ruim a apenas um host.
Você faz o deploy e deixa rodando por um período, recebendo uma pequena fração do tráfego total. Você tem seu monitoramento e alertas configurados nessa instância, que vão alertar se algo quebrar.
Rolling Deployments
Um rolling deployment permite fazer o rollout por porcentagem ao longo do tempo, de forma que, se houver um erro catastrófico, você o detecte antes que afete todas as máquinas e possa começar a revertê-las.
Rollout Regional
Conforme sua empresa cresce, você acaba tendo deployments em várias regiões. Em vez de fazer deploy em todas as regiões simultaneamente, você pode fazer deploy primeiro em uma região específica (geralmente a de menor tráfego).
Casos em que isso não se aplica
App store
Publicar um aplicativo móvel não é totalmente compatível com essas orientações. A fila de revisão da app store limita seu ritmo de deployment e exige uma estratégia diferente.
Ambientes Certificados
Dispositivos médicos, aviônicos, controle industrial, etc. Você não pode fazer deploy contínuo se precisa de um órgão regulador para certificar o build.
On-prem / Self-hosted
Você não tem controle sobre a atualização. Ainda é possível fazer deploy contínuo em tudo o que você opera, mas você precisa versionar cada mudança e é o cliente que determina quando ela é adotada.
Por Onde Começar
Não faça tudo isso de uma vez. A ordem importa:
- Deixe o CI verde e rápido. Idealmente em menos de 15 minutos
- Configure métricas e alarmes de taxa de erro, latência e disponibilidade. Esta é a parte mais importante do exercício
- Coloque qualquer mudança arriscada atrás de uma flag
- Adicione one-box + rollback automatizado
- Delete o calendário de releases
- Encontre um novo uso para todo o seu tempo extra agora que você não precisa mais agendar releases
A maioria dos times com quem trabalhei leva cerca de um trimestre para passar por tudo isso. A parte de ferramentas é fácil. O processo organizacional e quebrar a ilusão de que releases agendadas são seguras é a parte difícil.
Se o seu time está em um calendário de releases e quer sair dele, é esse o trabalho que eu faço. Me chama no direct.
