O que é um rolling deployment?
Um rolling deployment atualiza um serviço substituindo suas instâncias pela nova versão em pequenos lotes de cada vez, de modo que o serviço permaneça disponível durante todo o rollout.
O rolling deployment é uma das estratégias de zero downtime mais comuns, e o padrão em muitas plataformas de orquestração. Em vez de trocar tudo de uma só vez, você atualiza as instâncias em pequenos lotes, mantendo bastante capacidade saudável atendendo o tráfego em cada etapa.
Como funciona
Um rolling deployment avança em ondas. Ele derruba um pequeno lote de instâncias antigas, sobe o mesmo número rodando a nova versão, espera que elas passem nos health checks e então passa para o próximo lote. O rollout varre toda a frota até que cada instância rode a nova versão.
Por que evita downtime
Como apenas uma fração das instâncias está sendo substituída a cada momento, as demais continuam atendendo o tráfego. Enquanto as instâncias saudáveis restantes conseguirem lidar com a carga, os usuários não experimentam nenhuma interrupção - a atualização acontece por baixo deles enquanto o serviço permanece no ar.
Ajustando o rollout
Dois controles determinam o ritmo: quantas instâncias você substitui de uma vez e quantas extras você permite temporariamente. Lotes maiores fazem deploy mais rápido mas reduzem a margem de segurança; lotes menores são mais seguros mas mais lentos. Os health checks entre os lotes garantem que uma versão quebrada interrompa o rollout antes que ele se propague.
Rolling versus blue-green
Em um rolling deployment, as versões antiga e nova rodam simultaneamente em toda a frota durante a transição. O blue-green, em vez disso, mantém dois ambientes completos e alterna tudo de uma só vez. O rolling usa menos capacidade reserva e é incremental, mas misturar versões pode ser complicado; o blue-green oferece um cutover limpo ao custo de recursos dobrados.
O momento de versões misturadas
Durante um rolling deployment, ambas as versões atendem o tráfego ao mesmo tempo, então elas precisam ser compatíveis - especialmente em torno de bancos de dados e APIs compartilhados. Essa é a principal sutileza: mudanças que não são retrocompatíveis podem quebrar enquanto a frota está pela metade da atualização, então a evolução de schema e API precisa ser tratada com cuidado.
Principais conclusões
- Um rolling deployment substitui instâncias em pequenos lotes, mantendo o serviço no ar.
- Os health checks entre os lotes impedem que uma versão quebrada se propague.
- As versões antiga e nova coexistem durante o rollout, então as mudanças devem ser retrocompatíveis.