Fazer deploy em produção a cada alteração pode assustar, mas não fazer deploy direto para produção é ainda mais assustador.
Este é o processo que executei na Amazon, liderando uma equipe que fazia deploy para centenas de milhões de clientes. Por meio da minha consultoria, já liderei equipes de engenharia que passaram de deploys agendados quinzenalmente para entregas a cada merge.
Vamos começar pela parte óbvia:
Você vai causar uma interrupção. Não é uma questão de "se", mas de "quando".
Nenhuma quantidade de testes unitários, testes de integração, dogfooding, testes ponta a ponta, ou sacrifícios aos deuses do deploy vai capturar todos os bugs.
O teste que foi feito na sua funcionalidade há uma semana não foi testado com as alterações mais recentes do seu colega.
Seus testes foram feitos contra a versão de pré-produção do serviço do seu colega, que agora mudou e contém uma alteração incompatível com versões anteriores.
Quanto mais você espera, mais alterações se acumulam em um release. Se você precisar fazer rollback, agora terá que reverter duas semanas de alterações em vez de 1 a 2 horas de trabalho.
Se aceitarmos a premissa de que uma interrupção é inevitável, faz muito menos sentido dedicar recursos massivos ao QA de um release e, em vez disso, focar nossos recursos em monitorar e observar um release e estar preparado para lidar com uma interrupção quando ela acontecer.
Agora, vamos ver como chegamos lá:
Pré-requisitos:
CI/CD
Testes importam muito menos do que você imagina. Testes não conseguem provar que sua alteração é 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 a cada merge, ou pelo menos como parte do pipeline: testes unitários, de integração e ponta a ponta. Quanto mais longe o bug viaja no pipeline, mais caro é resolvê-lo.
Monitoramento/Observabilidade
O nome 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) conectados aos dois itens acima
Há uma arte e uma ciência em ajustar seus limites de alarme. É um equilíbrio entre sensibilidade e a rapidez com que você responde a um incidente real. Seu alvo de tempo para alerta sev-2 deve ser de 5 a 10 minutos.
Inicialmente, você provavelmente vai errar e provavelmente será sensível demais. Infelizmente, isso se aprende principalmente por tentativa e erro, então você provavelmente vai ter alguns despertares às 2h da manhã no começo.
Feature Flags
Para qualquer alteração com risco, você deve enviá-la atrás de uma feature flag / configuração remota. Uma feature flag permite que você faça rollback e desative qualquer alteração em poucos minutos, em vez de precisar reverter todo o deployment. Além disso, se o seu serviço de feature flags permitir (e deveria), você pode liberar a funcionalidade gradualmente por porcentagem ou por coorte, reduzindo ainda mais o impacto de uma alteração ruim.
Isso nos permite desacoplar o deploy do código da ativação do código. É sutil, mas é um divisor de águas na redução de risco.
Nota: você vai precisar de um processo para limpar essas flags. Idealmente, você cria um ticket de remoção para cada flag criada. Caso contrário, quando o seu serviço de feature flags cair (e vai cair), você terá uma regressão significativa. Pergunte-me como eu sei.
Rollback Automático (Circuit breaker de deploy)
Um circuit breaker de deploy é uma funcionalidade que permite reverter o deployment se você vir uma contagem ou porcentagem de erros enquanto o libera pela frota. A maioria dos provedores de nuvem já tem isso com uma simples caixa de seleção.
Alterações Compatíveis com Versões Anteriores
Você já deveria estar fazendo isso, mas fazer deploy a cada commit força essa prática. Durante um rolling deployment, você terá a versão antiga e a nova rodando ao mesmo tempo. Toda alteração precisa funcionar ao lado da 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 analisar algumas estratégias de deployment diferentes que ajudam a reduzir o risco ao liberar suas alterações.
One box (canário)
Um deployment one box faz o deploy das suas alterações em uma única máquina da frota maior. Isso permite reduzir o impacto de qualquer alteração ruim a apenas um host.
Você faz o deploy e deixa por um período, recebendo uma pequena fração do tráfego maior. Você tem seu monitoramento e alertas configurados nessa máquina que vão te alertar se algo quebrar.
Rolling Deployments
Um rolling deployment permite liberar por porcentagem ao longo do tempo, de modo que, se houver um erro catastrófico, você o detecte antes que afete todas as máquinas e possa então começar a revertê-las.
Lançamento Regional
À medida que sua empresa cresce, você acaba tendo deploys em várias regiões. Em vez de fazer deploy em todas essas 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 esta orientação. A fila de revisão da app store limita seu ritmo de deploy 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 precisar de um órgão regulador para certificar a compilação.
On-prem / Self-hosted
Você não controla a atualização. Você ainda pode fazer deploy contínuo em tudo o que opera; no entanto, você ainda precisa versionar cada alteração e o seu cliente determina quando ela é adotada.
Por onde começar
Não faça tudo de uma vez. A ordem importa:
- Deixe o CI verde e rápido. Idealmente abaixo de 15 minutos
- Adicione métricas e alarmes de taxa de erro, latência e disponibilidade. Esta é a parte mais importante do exercício
- Coloque qualquer alteração 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 está mais agendando releases
A maioria das equipes com as quais trabalhei leva cerca de um trimestre para passar por isso. As ferramentas são a parte fácil. O processo organizacional e quebrar a ilusão de que releases agendados são seguros é a parte difícil.
Se a sua equipe está num calendário de releases e quer sair dele, é esse o trabalho que eu faço. Me mande um DM.
