Estratégias de Rollout controlado e Feature Flag no deploy contínuo

Levamos a sério a ideia de entrega de valor constante para os clientes. Isso significa que todas as equipes entregam várias features e correções em produção todos os dias. Em média “shipamos” 10 a 20 entregas por dia no RD Station Marketing.

Além de toda suíte de testes automatizados que possuímos, com uma cobertura e profundidade bem abrangente, que nos ajuda a garantir a qualidade das entregas, usamos outras duas estratégias para entregar valor rápido e ao mesmo tempo mitigar problemas, bugs e incidentes em produção.

Estratégias

Rollouts controlados

Nós utilizamos essa estratégia para controlar quais contas/usuários tem acesso as novas features que iremos liberar em produção, com isso conseguimos coletar feedbacks de clientes específicos, além de reduzir o impacto de novas funcionalidades para toda a base de clientes.

Geralmente entregas de maior impacto tem o planejamento feito utilizando várias ondas de rollouts. Como sempre fazemos aqui na RD, eat your own dog food, começamos com contas internas para que consigamos validar e dar feedbacks sobre as entregas e a partir disso trabalhamos com clientes e agências parceiras que nos ajudam na fase de avaliação de novas entregas que geralmente entram na segunda onda de rollouts.

Por fim incrementamos o rollout para as demais contas, geralmente em lotes de clientes, para conseguirmos acompanhar a evolução da performance das entregas, avanço no uso das novas features e monitorar a infra de nossa nuvem.

Feature Flag

Este projeto nos possibilita habilitar e desabilitar features, utilizando essa estratégia conseguimos de maneira rápida tirar uma feature do ar e dar rollback quando encontramos um problema em produção.

Também nos ajuda a validar o funcionamento adequado da solução e testar em um ambiente mais real: infrae e usuários.

Essa segunda estratégia não visa controlar quais usuários têm acesso, mas sim conseguir de maneira rápida mudar o comportamento da solução quando algo desvia do planejado.

Como funcionam tecnicamente?

Ao desenvolver uma nova feature é discutido com o time se será adicionado ou não uma estratégia de feature_flagger ou um controle via rollout, tendo como objetivo habilitar e desabilitar features com máxima velocidade ou fazer um teste A/B, ajudando a validar o comportamento do usuário junto a uma pequena parcela de contas, ou desativar features caso necessário.

Em caso de uma feature_flag quando uma nova feature é definida a mesma ganha uma chave de identificação para que os desenvolvedores possam ter total controle desta feature, podendo habilitar ou desabilitar quando necessário, já nos casos de Rollout, a parte da feature que está sendo desenvolvida ganha uma chave de identificação e uma data para o processo de liberação, permitindo que o time possa definir quais contas terão acesso antecipado no ato da entrega.

Tecnicamente no código fonte são definidos alguns pontos condicionais que verificam se a conta em questão possui acesso ao identificador daquele rollout ou se uma feature está desabilitada ou não, e dependendo desta condição esta a parte do código se torna acessível.

Vale lembrar que nos casos de Rollouts este tipo de processo não é feito em todas as entregas, pois ter muitos rollouts cria muitas versões em produção e também acaba atrasando o ritmo de inovação onde para inovar é preciso ter coragem, e controlar tudo com base nessa estratégia acaba demonstrando um pouco de perda de confiança no trabalho desenvolvido.

Nossa equipe também tem o compromisso e ownership em não deixar códigos para trás e buscar sempre ser “get things done” inclusive com essa estratégia.

Prós e contras

Prós

1. Maior controle em caso de incidentes ou bugs, possibilitando maior agilidade para uma equipe contornar o caso.
2. Identificação antecipada de riscos de engenharia como performance, escalabilidade e riscos de produto.

Contras

1. Pelo menos duas versões do produto estarão rodando ao mesmo tempo.
2. Um código implementado de forma errada poderá impactar em performance ou até em casos mais graves, pode criar uma abertura na segurança.
3. Necessita uma maior atenção e compromisso com a equipe para que códigos não fiquem esquecidos após a execução da estratégia.

Projeto de código aberto

Visando ajudar a comunidade a Resultados Digitais desenvolveu este projeto em código aberto e você pode contribuir com o crescimento do mesmo através do GitHub feature_flagger.

Como atualmente nossa stack principal é em Ruby, esta solução foi desenvolvida para atender esta finalidade, porém no site https://featureflags.io/ você pode achar outras que atendem outras linguagens.

Você curtiu a ideia? Queremos saber se você também utiliza essa estratégia em sua empresa, se sim, compartilhe conosco qual o modelo utilizado e ajude a comunidade compartilhando pouco mais sobre o assunto :)

Time de Engenharia da RD

Este texto foi escrito de forma colaborativa por:

Kelvin Oenning — https://www.linkedin.com/in/kelvinoenning/

Luis Fernando Guedes — https://www.linkedin.com/in/lfernandoguedes/

Leonardo Denardi — https://www.linkedin.com/in/leonardo-denardi-46b4614a/

Revisão Super Especial Saimon Nunes — https://www.linkedin.com/in/saimonnunes/