Em desenvolvimento de software, sabemos da verdade máxima de que realizar deployment às sextas-feiras não é uma boa ideia. Mas aqui quero falar algo mais: sobre deployment e release como etapas distintas em suas entregas no ambiente de produção.
Antes de mais nada, vamos definir alguns conceitos. Quando falamos de deployment, estamos nos referindo a mover uma versão de software de um ambiente para outro. Já release é quando disponibilizamos para os usuários essa nova versão.
Trabalhando com desenvolvimento ágil, é comum estarmos diariamente em contato com pipelines de CI/CD. Estas pipelines visam permitir que façamos entregas com mais agilidade e também segurança. Essa separação entre deployment e release é fundamental para o sucesso das nossas empreitadas. Vamos discutir um pouco sobre isso nos próximos parágrafos.
Sobre releases
Dentro do assunto release, podemos conversar sobre algumas técnicas que são utilizadas em diversas fases das entregas em produção:
Canary release: nessa modalidade, entregamos para parte reduzida dos usuários a nova versão do software, para antecipar qualquer problema antes de liberar para uma quantidade mais significativa de pessoas. O critério para essa liberação pode ser tão simples quanto um percentual de requests ou tipo de device. Espera-se que essa release seja de curta duração, apenas para validar a versão no ambiente produtivo antes de seguir com o rollout gradual até o rollout completo.
Soft launching: nesse tipo de release, antecipamos para uma parcela dos usuários uma nova feature, sem muito alvoroço e divulgação. A intenção é avaliar métricas e o comportamento das aplicações no mundo real, com objetivo de realizar eventuais ajustes finos. Podemos também tornar a feature mais madura para o lançamento para toda a base. Os critérios para essa liberação podem ser simples ou mais elaborados, como usuários com tendência a realizar compras acima de R$ 100 e que vivem na região de Pindamonhangaba. Um rollout gradual ou uma versão Beta de uma app são exemplos de soft launching.
Hard launching: essa release é a liberação da nova versão para toda a base de usuários. Se por um lado ela possa ser vantajosa por já trazer de imediato o potencial de aumento em receita, por exemplo, ela traz um risco maior se algo der errado. Na maioria das vezes as empresas optam por realizar soft launchings com acompanhamento de métricas exatamente para mitigar esse tipo de risco e permitir rollbacks com impacto reduzido.
Rollout gradual
Sobre rollouts graduais, em que vamos liberando a nova versão para uma parcela cada vez maior da base de usuários, gostaria de comentar um pouco sobre estratégias em backend, que é a área em que mais tive contato ultimamente. Uma das estratégias mais comuns é utilizar feature flags, permitindo ligar ou desligar features sem a necessidade de novos deployments. Dessa forma, os times podem ir realizando deployments em produção a todo momento, com as features desligadas. O rollout gradual pode ser realizado em momento distinto, e com controle para realização de rollback se necessário.
Essa solução por feature flags pode utilizar uma aplicação customizada desenvolvida por sua empresa, alguma ferramenta open-source disponível, como o Togglz ou mesmo um serviço terceiro.
Pela minha experiência, recomendo fortemente que discuta com seus times a implementação de rollouts graduais. Para tanto, particularmente vejo este caminho a ser traçado:
- Desenvolvimento de uma cultura voltada para qualidade;
- Configuração de pipeline de CI/CD;
- Escrita de testes automatizados;
- Configuração de ferramenta de feature flags.
No momento em que seus times estiverem refinando e planejando atividades, faz sentido já assumirem nas estimativas de esforço o trabalho para permitir o rollout gradual da nova feature que será desenvolvida.
Por hoje é isso, pessoal! Obrigado por ler até aqui. Fiquem à vontade para usar os comentários abaixo caso tenham sentido falta de algum ponto ou queiram falar um pouco sobre a experiência de vocês nesse tema.
Be First to Comment