Distribuição de Software – Staged Rollouts

A prática comum de implantação de software conhecida como Staged rollouts, rollout gradual ou distribuição de software em fases, lança uma nova versão de um aplicativo para um subconjunto de usuários ou servidores em um período de tempo limitado, antes de lançá-la para todos os usuários ou servidores ao mesmo tempo.

Particularmente, vejo que o tema é pouco abordado, mesmo em grandes empresas que trabalhei.

Esse processo permite que você teste a nova versão do aplicativo em um ambiente controlado antes de disponibilizá-la para todos os usuários ou servidores.

Dessa forma, é possível identificar e corrigir quaisquer problemas que possam surgir antes que afetem um grande número de usuários ou interfira na estabilidade do sistema como um todo.

Por que a adoção do Staged Rollouts é tão importante?

Minimiza o risco de falhas em produção

Implantar gradualmente uma nova versão de um aplicativo reduz o risco de falhas em produção, pois permite testar a nova versão em um ambiente controlado antes de disponibilizá-la para todos os usuários. Isso minimiza o impacto de problemas inesperados no sistema e ajuda a garantir que o aplicativo esteja funcionando corretamente antes de seu lançamento para todos.

No entanto, é importante ressaltar que a coleta de métricas para os critérios de sucesso de cada uma das fases de distribuição é necessária.

Identificação antecipada de problemas

O processo de implantação gradual te permite identificar e corrigir quaisquer problemas que possam surgir em pequenos grupos de usuários antes que afete a experiência ou estabilidade do software.

Isso pode economizar tempo e recursos significativos no longo prazo além de manter um boa reputação com os usuários.

Melhoria da qualidade do produto

A distribuição de software em fases para novas funcionalidades ou atualizações permite que você obtenha feedback dos usuários em tempo real e faça melhorias no produto com base neles.

Isso pode melhorar a qualidade na entrega de um aplicativo levando a uma experiência mais aprimorada do usuário.

Controle do fluxo de tráfego

Quem nunca… lançou uma nova funcionalidade e sem um teste de carga amplo e a aplicação acabou não suportando a demanda?

A implantação gradual pode ajudar a gerenciar o fluxo de tráfego no aplicativo, especialmente em casos de alto volume de usuários. A liberação gradual pode ajudar a evitar picos de tráfego e garantir que o aplicativo mantenha um desempenho estável e confiável.

Em casos de usos específico a arquitetura da aplicação precisa ser implementada também em fases e com recursos de feature flags.

Menor impacto na equipe de suporte

A distribuição de software gradual também ajuda a equipe de suporte a gerenciar melhor quaisquer problemas ou perguntas que possam surgir após uma atualização do aplicativo.

Quando alguém lança a nova versão para um pequeno grupo de usuários de cada vez, a equipe de suporte pode lidar com quaisquer problemas que surjam de forma mais eficiente e sem ser sobrecarregada com um grande número de tickets de suporte.

O Cliente deve ser o Centro ao adotar prática de distribuição de software gradual

Em todas as motivações anteriores, do porquê usar essa prática no seu produto, percebemos que o ponto central é a satisfação do cliente além de manter um crescimento sustentável do produto no mercado.

Técnicas e ferramentas para fazer Staged Rollouts no seu produto

Mais do que softwares para facilitar a distribuição de novas funcionalidades no seu produto, é importante identificar as melhores técnicas para cada cenário.

Feature Flags

As feature flags são uma técnica de desenvolvimento de software que te permite ativar ou desativar recursos específicos em um aplicativo.

Com isso, as equipes de desenvolvimento habilitem ou desabilitem recursos de forma controlada e gradual para grupos específicos de usuários. Algumas ferramentas de feature flag disponíveis no mercado, incluindo LaunchDarkly, Rollout, Unleash, e Flagsmith.

Recomendo principalmente acessar o featureflags.io que tem soluções de código aberto em várias linguagens de programação. Ou Acesse esse outro post que fiz especificamente sobre Feature Flags.

Essa abordagem representa uma solução adequada para a liberação de features em alguns clientes para homologação. No entanto, como na maioria dos cenários envolve aplicar condições no código fonte para habilitar ou não, deve ser considerada temporária.

Blue-green deployment

O blue-green deployment é uma técnica que envolve a criação de um ambiente de produção duplicado (o ambiente “green”) em paralelo com o ambiente atual (o ambiente “blue”).

Os usuários são então direcionados para o ambiente green gradualmente enquanto testa a nova versão.

Se algo der errado, a equipe pode voltar rapidamente para o ambiente blue sem afetar os usuários. Existem várias ferramentas de implantação blue-green, como o Kubernetes, o AWS CodeDeploy e o Istio.

Esta solução aumenta a segurança dos desenvolvedores e time de infraestrutura que passa a contar com uma última verificação para promover um nova versão do software em um ambiente produtivo.

Canary release

O canary release é uma técnica de implantação que envolve o lançamento de uma nova versão do aplicativo para um subconjunto de usuários para testes.

Se a nova versão for bem-sucedida com esse subconjunto, ela pode ser lançada para todos os usuários. Se houver problemas, a equipe pode reverter para a versão anterior.

Algumas ferramentas de canary release incluem o Google Cloud Deployments Manager, o AWS CodeDeploy e o Spinnaker.

Essa abordagem envolve mais requisitos de arquitetura e devOps, normalmente utilizada por empresas com alta maturidade em tecnologia.

A/B testing

O A/B testing envolve a criação de duas ou mais versões de um recurso ou design de aplicativo e testá-las com diferentes grupos de usuários para ver qual funciona melhor.

O uso de A/B testing pode ajudar a equipe de desenvolvimento a tomar decisões mais informadas sobre quais recursos incluir em uma nova versão do aplicativo.

Algumas ferramentas de A/B testing são: o Google Optimize, o Optimizely e o Adobe Target.

Quantas fases e quais subconjunto de usuários devo criar para o staged rollouts

A quantidade de fases, bem como as segmentações dos subconjunto de usuários a serem utilizados no staged rollouts vai variar de acordo com o projeto e as necessidades de validação.

Por exemplo, se você quer validar uma melhoria simples em uma feature do seu produto, mas vai atender apenas um grupo de usuários e envolve baixo acoplamento e alta cobertura de testes, talvez o lançamento em uma fase com o uso de feature flag já seja o suficiente.

Porém se deseja validar novos produtos ou alteração crítica de conceito, ou mudança considerável de usabilidade, melhorias de arquitetura do software ou de infraestrutura é importante levar a validação para o nível de devOps.

Onde você poderia iniciar, por exemplo, com fases de liberação para clientes menores, ou um subconjunto de usuários que tem um risco de churn menor, ou usuários inscritos como beta testers, até passar por fases de clientes mais críticos.

Em resumo, existem muitas abordagens para tratativa de distribuição de software automatizada em fases e você precisa avaliar a que melhor lhe atende além de sempre definir os critérios de sucesso de cada um dos lançamentos.