{"id":3515,"date":"2022-07-13T09:00:00","date_gmt":"2022-07-13T12:00:00","guid":{"rendered":"http:\/\/agilblog.locaweb.com.br\/?p=144"},"modified":"2022-07-13T10:11:05","modified_gmt":"2022-07-13T13:11:05","slug":"canary-deployment-como-funciona","status":"publish","type":"post","link":"https:\/\/www.locaweb.com.br\/blog\/temas\/codigo-aberto\/canary-deployment-como-funciona\/","title":{"rendered":"Entendendo como funciona o Canary Deployment"},"content":{"rendered":"\n

E ai pessoal, tudo bom com voc\u00eas 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\u00e1pido e confi\u00e1vel<\/a>. O processo de melhorias<\/strong> de uma aplica\u00e7\u00e3o evoluiu demais e hoje iremos falar sobre um modelo muito utilizado na ind\u00fastria de desenvolvimento para que atualiza\u00e7\u00f5es de software tenham menor impacto e falta de disponibilidade em caso de erros.<\/p>\n\n\n\n

Lembro que antigamente o processo de evolu\u00e7\u00e3o de software web<\/strong> em geral se baseava em trocar os arquivos do sistema por FTP, muitas vezes sem direito a falhas. J\u00e1 que os backups eram escassos e dif\u00edceis de fazer. <\/p>\n\n\n\n

Rollback? Ambiente de Staging? Teste A\/B? Ish, ningu\u00e9m nem sabia o que era isso na maioria das vezes. A\u00ed se no processo de FTP um arquivo errado fosse apagado \u201csem querer\u201d, o desespero tomava conta do pessoal e \u00e0s vezes o sistema ficava indispon\u00edvel durante horas ou dias. Mas que bom que hoje voc\u00eas n\u00e3o usam mais FTP manual para atualizar os sistemas, n\u00e3o usam n\u00e9? N\u00e9?<\/p>\n\n\n\n

Hoje, iremos falar de um modelo de deploy chamado Canary Deployment <\/strong>ou Canary Releases<\/strong>. Esse modelo foi criado com a ideia de que um novo deploy deve ter o menor impacto negativo poss\u00edvel quando for disponibilizado. Ou seja, esse deploy \u00e9 disponibilizado para uma parcela pequena de usu\u00e1rios.<\/p>\n\n\n\n

Obs: Em portugu\u00eas seria algo como \u201cImplanta\u00e7\u00e3o Can\u00e1rio\u201d ou \u201cLan\u00e7amentos Can\u00e1rio\u201d, mas preferi manter o nome em ingl\u00eas mesmo.<\/p>\n\n\n\n

O que \u00e9 Canary Deployment?<\/strong><\/h2>\n\n\n\n

Basicamente o canary deployment<\/strong> \u00e9 um modelo de deploy<\/a> onde os releases s\u00e3o feitos de modo parcial. Primariamente, um novo release \u00e9 disponibilizado para uma pequena parcela de usu\u00e1rios para que essas pessoas possam testar as novidades<\/strong> e dar feedbacks sobre o que mudou. E, caso essas mudan\u00e7as sejam est\u00e1veis e aceitas por essas pessoas, a atualiza\u00e7\u00e3o \u00e9 realizada para as demais pessoas que utilizam o sistema.<\/p>\n\n\n

\n
\"canary
Fluxograma B\u00e1sico de um Sistema que Realiza Canary Deployment<\/figcaption><\/figure>\n<\/div>\n\n\n

Exemplo de Canary deploy<\/strong><\/h2>\n\n\n\n

Voc\u00ea j\u00e1 deve ter percebido, por exemplo, que quando usa o Instagram<\/a>, ou o Twitter, existem funcionalidades que algumas pessoas come\u00e7am a ter e outras n\u00e3o. Por exemplo, quando lan\u00e7aram 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\u00edpio. Com o passar do tempo as funcionalidades foram liberadas para todas as pessoas. Isso \u00e9 um exemplo de Canary Deployment<\/strong>.<\/p>\n\n\n\n

Esse modelo tamb\u00e9m \u00e9 muito comum para lan\u00e7amentos de navegadores e sistemas web em geral.<\/p>\n\n\n\n

Como s\u00e3o disponibilizados os Canary Releases (os lan\u00e7amentos)?<\/strong><\/h2>\n\n\n\n

Para simplificar, vamos dizer que seu projeto est\u00e1 dispon\u00edvel em diversos servidores. A ideia inicial \u00e9 voc\u00ea eleger um ou alguns desses servidores para ser o servidor canary e realizar o deploy<\/strong> da aplica\u00e7\u00e3o nesses servidores.<\/p>\n\n\n

\n
\"canary<\/figure>\n<\/div>\n\n\n

Posteriormente, deve-se criar o fluxo<\/strong> para disponibilizar a nova vers\u00e3o para um grupo pequeno de usu\u00e1rios e entender como ser\u00e1 feita a elei\u00e7\u00e3o desse grupo de pessoas \u201cgrupo canary\u201d (as pessoas que v\u00e3o ter acesso \u00e0 nova vers\u00e3o assim que a mesma for disponibilizada).<\/p>\n\n\n\n

Em alguns casos o pr\u00f3prio load Balancer realiza a elei\u00e7\u00e3o das pessoas desse grupo. Aleatoriamente algo em torno de 90% e 95% das pessoas que acessam o sistema \u201ccair\u00e3o\u201d na vers\u00e3o antiga dele e as demais \u201ccair\u00e3o\u201d na vers\u00e3o nova. <\/p>\n\n\n\n

Em outros casos, essas pessoas s\u00e3o pr\u00e9 escolhidas. Seja por terem aceitado serem \u201cbeta-testers\u201d do sistema, ou por serem funcion\u00e1rios da empresa, ou por terem acesso pr\u00e9vio a determinadas funcionalidades de forma anterior e at\u00e9 mesmo de acordo com a regi\u00e3o onde vivem.<\/p>\n\n\n

\n
\"deploy
Acesso \u00e0 vers\u00e3o diferente do sistema de acordo com estar ou n\u00e3o no \u201cgrupo canary\u201d<\/figcaption><\/figure>\n<\/div>\n\n\n

Alguns produtos como o Facebook por exemplo, disponibiliza as releases para diversos grupos can\u00e1rios. Primeiramente para funcion\u00e1rios, depois para pessoas que se inscreveram para o beta do Facebook e posteriormente para o p\u00fablico em geral.<\/p>\n\n\n\n

Sendo assim, no m\u00ednimo 2 vers\u00f5es do sistema rodam simultaneamente quando ocorre um release utilizando o canary deployment<\/strong>. Por\u00e9m, ap\u00f3s realizar os devidos testes e ser entendido que a nova vers\u00e3o pode ser disponibilizada para as demais pessoas, se realiza o deploy da nova vers\u00e3o<\/strong> para todas as inst\u00e2ncias e a vers\u00e3o \u00e9 disponibilizada para todas as pessoas.<\/p>\n\n\n\n

Como funcionam os testes com Deploy Canary<\/strong><\/h2>\n\n\n
\n
\"canary
Depois dos testes todas as pessoas passam a acessar a nova vers\u00e3o do sistema<\/figcaption><\/figure>\n<\/div>\n\n\n

Lembrando que utilizamos o exemplo dos servidores para ficar mais f\u00e1cil o entendimento. O balanceador pode ser um load Balancer no caso de m\u00faltiplos servidores, ou at\u00e9 mesmo um servidor nginx que direciona parte das pessoas para uma pasta com uma vers\u00e3o do projeto ou para outra com outra vers\u00e3o, ou um app de celular que est\u00e1 disponibilizado neste modelo na store espec\u00edfica, ou por exemplo a pessoa \u00e9 redirecionada para um subdom\u00ednio de teste,<\/strong> como por exemplo staging.site.com ao inv\u00e9s de site.com. Isso \u00e9 de acordo com o tamanho do projeto e o tipo de gest\u00e3o de deploy<\/strong> que \u00e9 realizada.<\/p>\n\n\n\n

Benef\u00edcios do Canary Deployment<\/strong><\/h2>\n\n\n\n

F\u00e1cil Rollback<\/strong>: como o deploy \u00e9 feito em uma pequena parte da infra total em que o sistema roda como um todo, \u00e9 muito mais f\u00e1cil voltar o sistema para uma vers\u00e3o anterior est\u00e1vel.<\/p>\n\n\n\n

Zero Downtime:<\/strong> realizar o deploy dessa maneira faz com que o sistema n\u00e3o fique indispon\u00edvel durante a realiza\u00e7\u00e3o do deploy, j\u00e1 que apenas uma parte de toda a infra \u00e9 afetada.<\/p>\n\n\n\n

Teste A\/B<\/strong>: como parte das pessoas que usam o sistema ir\u00e3o acessar uma vers\u00e3o e a outra parte a outra, \u00e9 poss\u00edvel verificar at\u00e9 mesmo a adapta\u00e7\u00e3o das pessoas \u00e0 nova vers\u00e3o e validar realmente se ela faz sentido para a usabilidade da aplica\u00e7\u00e3o.<\/p>\n\n\n\n

Feedback<\/strong>: \u00e9 poss\u00edvel validar com as pessoas que usam as melhorias que a nova vers\u00e3o traz, bem como o que \u00e9 poss\u00edvel melhorar nela.<\/p>\n\n\n\n

Quando n\u00e3o usar o Canary Deployment<\/strong><\/h2>\n\n\n\n

Existem alguns momentos que o canary deployment deve ser evitado:<\/p>\n\n\n\n