Neste post, trataremos do que é conhecido na TI como deploy, e as técnicas para fazer o lançamento de aplicativos visando análise e testes de recursos e funcionalidades específicas. “Fazer o deploy” nada mais é do que implantar um sistema ou app, ou seja, fazê-lo funcionar de forma completa e estável.

Antes de mergulharmos nos diferentes tipos de técnicas de implantação disponíveis no mercado de nuvem atualmente, é importante mencionar o que é uma estratégia de implantação. Tratam-se de diversas técnicas usadas para fazer alterações ou atualizações em um aplicativo sem que haja tempo de inatividade no sistema (chamado downtime), ou seja, de uma forma tal que o usuário sequer note o que foi feito na hora.

A estratégia de implantação mais comum em uso atualmente é conhecida como implantação Blue-Green (do original em inglês Blue-Green Deployment), e consiste em uma técnica de gestão de lançamento de aplicativos que reduz o tempo de inatividade e também o risco de falhas no sistema, ao executar dois ambientes de produção iguais, identificados como “Blue” e “Green”. Normalmente cada um deles rodando uma versão da aplicação e o outro rodando a versão seguinte ou a anterior. 

O objetivo é fornecer testes confiáveis, upgrades contínuos sem interrupções e reversões instantâneas (não confundir com “revisões”). A qualquer momento, apenas um dos ambientes está ativo, com o ambiente ativo atendendo a todo o tráfego de produção.

No passado, pouco antes da implantação blue-green existir, havia o Rolling Deployment). A título de comparação, no Rolling Deployment o usuário possui apenas UM ambiente completo para trabalhar. Depois que um usuário começa a atualizar o ambiente, o código é implantado no subconjunto de instâncias do mesmo ambiente e passa para outro subconjunto após a conclusão. E é isso. Portanto, é fácil entender porque a implantação BlueGreen é claramente uma atualização do tipo “próximo nível” no desenvolvimento de software.

Mas não termina aqui: há também outra categoria na estratégia de implantação, que é chamada de Canary Deployment (ou Canary Release); trata-se de uma técnica de implantação de código que visa reduzir o risco associado à introdução de uma nova versão de software em produção. Para que isso aconteça, um Canary Release permite que os desenvolvedores implantem novos códigos ou recursos apenas para um subconjunto de usuários como um teste inicial, antes de implantá-los para toda a infraestrutura e disponibilizar para todos de uma vez só.

E caso você esteja se perguntando: de onde vem a palavra “canário”, o termo veio mesmo dos canários que conhecemos. Neste caso, trata-se de uma menção aos canários usados antigamente para alertar os mineiros quando gases tóxicos atingissem níveis perigosos dentro das minas de carvão. Assim como nas minas, os canários “dão o alerta” até onde tudo vai bem e é possível seguir, sem maiores problemas.

Aplicado à Engenharia de Software, um Canary Release funciona da seguinte maneira: uma nova versão do software, conhecida como Canary, é implantada para um pequeno subconjunto de usuários junto com a versão estável em execução. O tráfego é dividido entre essas duas versões de forma que uma parte das solicitações recebidas seja desviada para a versão Canary. A qualidade da versão Canary é avaliada comparando as principais métricas que descrevem o comportamento das versões antiga e nova. Se houver degradação significativa nessas métricas, a versão Canary é abortada e todo o tráfego é roteado para a versão estável em um esforço de minimizar o impacto do comportamento inesperado.

E por último, mas não menos importante, temos a estratégia de implantação de testes A/B. Esses testes consistem, sob condições específicas, do roteamento de um subconjunto de usuários para acessar um novo recurso em um software ou aplicativo. Na verdade, a técnica é usada principalmente para avaliar a eficácia de uma mudança no sistema x como o mercado reage a ela. Portanto, é mais sobre tomar decisões de negócios com base em estatísticas, do que propriamente uma estratégia de implantação, uma vez que os novos recursos a serem testados serão lançados para um conjunto selecionado de usuários.

É uma estratégia muito semelhante ao Canary Release, exceto pelo fato deste último estar movendo um novo produto ou recurso para uma determinada comunidade antes de ser totalmente implantado para TODOS os clientes. O Blue-Green é uma estratégia de implantação para testar a nova versão de um serviço (sem tirá-lo do ar ou colocá-lo em risco). Neste modelo, tanto o Blue quanto o Green estarão ativos e funcionando em algum ponto do tempo para, em seguida, mesclar perfeitamente um com o outro.

Análise Canary na Netflix com Kayenta

Kayenta é uma plataforma de última geração para análise automatizada de Canary Release (Automated Canary Analysis, sob a sigla ACA). Ela é usada por outra plataforma, a Spinnaker, de entrega contínua, para possibilitar implantações Canary automatizadas. A plataforma Kayenta é responsável por avaliar o risco de um Canary Release e verificar se há degradação significativa entre a versão estável atual e o Canary Release candidato. Hoje muito usada por equipes DevOps, o sucesso do Kayenta não veio antes de muito trabalho por parte de engenheiros da Netflix.

A análise Canary era inicialmente um processo manual para eles, o que significa que um desenvolvedor ou engenheiro de software examinaria os gráficos e registros dos servidores com a versão estável atual e compararia com a Canary candidata para ver se a precisão das métricas (códigos de status HTTP, tempos de resposta, contagens de exceção, balanceamento de carga, etc. ) coincide. Se os dados parecessem razoáveis, um julgamento manual era feito para avançar ou voltar no processo.

Desnecessário dizer que a abordagem manual, além de não ser confiável, não permite o escalonamento (expansão) do sistema como um todo. Cada Canary Release significava passar várias horas examinando gráficos e combinando logs. O que dificultava a implantação de novas compilações de código mais de uma ou duas vezes por semana. A comparação visual dos gráficos também deixava escapar diferenças sutis entre o Canary e o código de referência.

A primeira tentativa de automatizar a análise Canary por parte dos engenheiros da Netflix foi através de um script muito específico para o aplicativo que estavam monitorando. A próxima tentativa foi expandir esse processo e introduzir a primeira versão da análise automatizada de Canary Releases. Isso aconteceu há mais de 5 anos para essas equipes. Agora, o Kayenta é uma evolução desse sistema e é fruto das lições que esses engenheiros aprenderam ao longo de anos de entrega contínua, com mudanças rápidas e confiáveis em produção na plataforma de desenvolvimento da Netflix.

Feature Toggles ou Feature Flags x Testes A/B

O termo “Feature Toggle”, se traduzido para o Português, teria como significado algo como “interruptor de recurso”. Essa técnica de desenvolvimento de software também é conhecida pelo termo “Feature Flag”, o que em Português teria um significado um tanto estranho, algo como “sinalizador de recurso”. Ambas traduções literais, no entanto, ajudam a compreender a função primeira de uma feature flag.

Trata-se de uma técnica usada por equipes DevOps para ocultar, habilitar ou desabilitar um determinado recurso durante seu tempo de execução – dessa forma, podendo “alternar” de um estado para outro. Essa flexibilidade permite que as equipes modifiquem o comportamento do sistema sem alterar nenhum código, uma vez que ele pode ser “ligado” ou “desligado” remotamente sem a necessidade de implantação.

As Features Flags fornecem uma alternativa para manter várias ramificações no código-fonte, de forma que um recurso de software possa ser testado antes mesmo de estar pronto para o lançamento – um atributo caro tanto para o cliente como para as equipes DevOps.

Entre alguns de seus benefícios mais comuns, estão:

• Teste em produção

Como geralmente é impossível simular completamente o ambiente de produção em seus diversos estágios, os Feature toggles permitem que as equipes DevOps validem recursos de novos lançamentos no mundo real, minimizando riscos.

• Canary Release

O teste Canary ajuda a limitar o risco de lançar um recurso para toda a base de usuários; permite reverter rapidamente um recurso simplesmente ao ativá-lo ou desativá-lo, em vez de passar por outro ciclo de implantação.

• Ciclos de liberação mais rápidos
  

Usando Feature Toggles, uma equipe DevOps pode modificar o comportamento de um sistema sem fazer alterações de código sensíveis no código ativo. Portanto, um dos principais benefícios dos Feature toggles é a simplicidade de implantação no processo de desenvolvimento.

Teste A/B do lado do servidor

Os desenvolvedores podem implantar testes A/B, usando Feature Flags para habilitar um recurso para metade de um segmento de usuários e desabilitar o recurso para a outra metade e observar como cada um funciona para uma determinada métrica (tais como “uso do aplicativo” ou “compras”). Como o teste é implantado no backend por meio de código, não há latência.

Existem também diferentes tipos de Feature Toggles, com base no contexto em que são usados:

Release Toggles

Uma etapa do projeto de desenvolvimento foi concluída e o responsável pelo projeto aceitou tudo. As alterações são enviadas para serem aceitas pelo usuário, mas apenas parte do recurso desenvolvido é aprovada. Você deseja colocar o que foi aprovado em produção, mas a outra parte do recurso não deve ser disponibilizada. O que fazer então? Release Toggles é a resposta! Cada funcionalidade é protegida por um release toggle para que qualquer funcionalidade em tempo de execução possa ser revelada ou ocultada. Portanto, todas as alterações podem entrar em produção e apenas alguns dos release toggles estão ativados.

Ops Toggles 

Os Ops Toggles são Feature Toggles que os Ops podem usar para desativar certos recursos em momentos de vulnerabilidade ou risco no sistema. Essas flags são usadas para controlar os aspectos operacionais de comportamento do sistema. Elas podem ser usadas, por exemplo, no lançamento de um novo recurso com implicações de desempenho pouco claras para que os operadores do sistema possam desativar o recurso rapidamente antes de ser disponibilizado para todos os usuários.

Experiment Toggles

Experiment Toggles são usados para realizar diversos testes A/B. Cada usuário do sistema é separado por grupos e, a um determinado tempo de execução, um Toggle Router enviará consistentemente um determinado usuário para uma das variações do experimento, com base no grupo em que estiver inserido. Rastreando o comportamento agregado de diferentes grupos, podemos comparar o efeito de diferentes variações. Essa técnica é comumente usada para fazer otimizações baseadas em dados para coisas como o fluxo de compra de um sistema de e-commerce ou mesmo o call-to-action de um botão.

Permissioning Toggles

As flags Permissioning Toggles são usadas para alterar os recursos ou a experiência de produto que determinados usuários recebem. Por exemplo, podemos ter um conjunto de recursos “Premium” que por sua vez é ativado apenas para clientes pagantes. Ou talvez um conjunto de recursos “Alfa” que estão disponíveis apenas para usuários internos e outro conjunto de recursos “Beta” que estão disponíveis apenas para usuários internos e usuários beta.