E ai pessoal, tudo bom com vocês hoje? Em um artigo anterior falamos um pouco sobre como processos de CI e CD podem tornar o seu processo de desenvolvimento de software mais rápido e confiável. O processo de melhorias de uma aplicação evoluiu demais e hoje iremos falar sobre um modelo muito utilizado na indústria de desenvolvimento para que atualizações de software tenham menor impacto e falta de disponibilidade em caso de erros.

Lembro que antigamente o processo de evolução de software web em geral se baseava em trocar os arquivos do sistema por FTP, muitas vezes sem direito a falhas. Já que os backups eram escassos e difíceis de fazer.

Rollback? Ambiente de Staging? Teste A/B? Ish, ninguém nem sabia o que era isso na maioria das vezes. Aí se no processo de FTP um arquivo errado fosse apagado “sem querer”, o desespero tomava conta do pessoal e às vezes o sistema ficava indisponível durante horas ou dias. Mas que bom que hoje vocês não usam mais FTP manual para atualizar os sistemas, não usam né? Né?

Hoje, iremos falar de um modelo de deploy chamado Canary Deployment ou Canary Releases. Esse modelo foi criado com a ideia de que um novo deploy deve ter o menor impacto negativo possível quando for disponibilizado. Ou seja, esse deploy é disponibilizado para uma parcela pequena de usuários.

Obs: Em português seria algo como “Implantação Canário” ou “Lançamentos Canário”, mas preferi manter o nome em inglês mesmo.

Navegue pelo índice

    O que é Canary Deployment?

    Basicamente o canary deployment é um modelo de deploy onde os releases são feitos de modo parcial. Primariamente, um novo release é disponibilizado para uma pequena parcela de usuários para que essas pessoas possam testar as novidades e dar feedbacks sobre o que mudou. E, caso essas mudanças sejam estáveis e aceitas por essas pessoas, a atualização é realizada para as demais pessoas que utilizam o sistema.

    canary deploy
    Fluxograma Básico de um Sistema que Realiza Canary Deployment

    Exemplo de Canary deploy

    Você já deve ter percebido, por exemplo, que quando usa o Instagram, ou o Twitter, existem funcionalidades que algumas pessoas começam a ter e outras não. Por exemplo, quando lançaram os stories, depois as caixinhas de perguntas e depois a possibilidade de colocar links nos stories, poucas pessoas tinham essas funcionalidades quando foram disponibilizadas a princípio. Com o passar do tempo as funcionalidades foram liberadas para todas as pessoas. Isso é um exemplo de Canary Deployment.

    Esse modelo também é muito comum para lançamentos de navegadores e sistemas web em geral.

    Como são disponibilizados os Canary Releases (os lançamentos)?

    Para simplificar, vamos dizer que seu projeto está disponível em diversos servidores. A ideia inicial é você eleger um ou alguns desses servidores para ser o servidor canary e realizar o deploy da aplicação nesses servidores.

    canary deploy

    Posteriormente, deve-se criar o fluxo para disponibilizar a nova versão para um grupo pequeno de usuários e entender como será feita a eleição desse grupo de pessoas “grupo canary” (as pessoas que vão ter acesso à nova versão assim que a mesma for disponibilizada).

    Em alguns casos o próprio load Balancer realiza a eleição das pessoas desse grupo. Aleatoriamente algo em torno de 90% e 95% das pessoas que acessam o sistema “cairão” na versão antiga dele e as demais “cairão” na versão nova.

    Em outros casos, essas pessoas são pré escolhidas. Seja por terem aceitado serem “beta-testers” do sistema, ou por serem funcionários da empresa, ou por terem acesso prévio a determinadas funcionalidades de forma anterior e até mesmo de acordo com a região onde vivem.

    deploy canary
    Acesso à versão diferente do sistema de acordo com estar ou não no “grupo canary”

    Alguns produtos como o Facebook por exemplo, disponibiliza as releases para diversos grupos canários. Primeiramente para funcionários, depois para pessoas que se inscreveram para o beta do Facebook e posteriormente para o público em geral.

    Sendo assim, no mínimo 2 versões do sistema rodam simultaneamente quando ocorre um release utilizando o canary deployment. Porém, após realizar os devidos testes e ser entendido que a nova versão pode ser disponibilizada para as demais pessoas, se realiza o deploy da nova versão para todas as instâncias e a versão é disponibilizada para todas as pessoas.

    Como funcionam os testes com Deploy Canary

    canary deployment
    Depois dos testes todas as pessoas passam a acessar a nova versão do sistema

    Lembrando que utilizamos o exemplo dos servidores para ficar mais fácil o entendimento. O balanceador pode ser um load Balancer no caso de múltiplos servidores, ou até mesmo um servidor nginx que direciona parte das pessoas para uma pasta com uma versão do projeto ou para outra com outra versão, ou um app de celular que está disponibilizado neste modelo na store específica, ou por exemplo a pessoa é redirecionada para um subdomínio de teste, como por exemplo staging.site.com ao invés de site.com. Isso é de acordo com o tamanho do projeto e o tipo de gestão de deploy que é realizada.

    Benefícios do Canary Deployment

    Fácil Rollback: como o deploy é feito em uma pequena parte da infra total em que o sistema roda como um todo, é muito mais fácil voltar o sistema para uma versão anterior estável.

    Zero Downtime: realizar o deploy dessa maneira faz com que o sistema não fique indisponível durante a realização do deploy, já que apenas uma parte de toda a infra é afetada.

    Teste A/B: como parte das pessoas que usam o sistema irão acessar uma versão e a outra parte a outra, é possível verificar até mesmo a adaptação das pessoas à nova versão e validar realmente se ela faz sentido para a usabilidade da aplicação.

    Feedback: é possível validar com as pessoas que usam as melhorias que a nova versão traz, bem como o que é possível melhorar nela.

    Quando não usar o Canary Deployment

    Existem alguns momentos que o canary deployment deve ser evitado:

    • Quando por exemplo vocês só tiverem uma instância de banco de dados e a mudança no sistema exigir que o modelo do banco de dados mude (por exemplo ao adicionar uma coluna que não aceita valores nulos em uma tabela);
    • Quando o sistema for instalado na máquina do usuário e não tiver como por exemplo fazer a instalação de maneira remota ou automatizada;
    • Quando não for possível realizar CI/CD no sistema por quaisquer motivos.

    Bem galera, desejo que você tenha curtido conhecer um pouco mais sobre esse tipo de deploy. Quaisquer dúvidas e comentários você pode colocar aqui nos comentários ou me mandar uma mensagem no meu twitter ou na minha live. Um grande abraço e até a próxima!

    Somente um servidor de alta performance pode garantir que o deploy canary seja bem executado

    SAIBA MAIS