Tipos de deploy e como isso impacta a vida de uma aplicação
Tags: devops, braziliandevs, beginners, programming
Published: 2021-10-14 23:09:59

Na squad onde estava alocada, por ser a minha primeira aplicação em produção, resolvi acompanhar e aprender mais sobre esse universo chamado **devops**, infra, enfim... toda a parte que não está envolvida com o código em si, mas com a estrutura de como isso vai rodar para o usuário.

Nesse meio tempo de trabalho e estudos, conheci o **CharlesCD** que trabalha com o conceito de deploy em círculos, bom... aqui começa a minha jornada de aprendizado sobre deploy, começa que existem tipos de deploy e eu sequer sabia disso, a seguir um compilado de artigo que encontrei sobre o tema.

##Primeiramente, o que é um tipo deploy ou estratégia de deploy?

Em algumas literaturas e empresas, chamamos de tipo de deploy ou estratégia de deploy a forma na qual a aplicação será colocada a disposição do usuário final.

> Uma estratégia de deploy é uma forma de alterar ou atualização uma aplicação. O objetivo é fazer a mudança sem afetar a aplicação de forma que o usuário mal note as mudanças

Fonte: [OpenShift - RedHat](https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/deployment_strategies.html), tradução livre

##Alguns tipos de deploys utilizados

###Canary

O deploy do tipo **Canary** visa reduzir o risco de disponibilizar uma atualização de uma única vez para todos os usuários, dessa forma, a atualização é disponibiliza para apenas um grupo seleto de usuários antes de ir para o público geral.

> Em Canary, o ambiente antigo segue ativo simultaneamente ao novo ambiente. Por isso, pode-se liberar uma parcela dos usuários para acessar o novo ambiente e ver como ele se comporta com usuários reais. Assim é possível identificar se vão existir problemas no dia a dia.

Fonte: [Locaweb](https://blog.locaweb.com.br/temas/codigo-aberto/conheca-os-principais-tipos-de-deploy-e-quando-usar-cada-um/)

Entretanto, essa estratégia não propõe [nenhuma estratégia de escolha de usuários para a expansão](https://docs.charlescd.io/v/v1.0.x-pt/faq/deploy-em-circulos-e-outros-deploys). Por esse motivo, torna-se mais difícil gerenciar as versões existentes do sistema, o que contribui para que não haja tanto versionamento.

###Blue-Green

O tipo **blue-green** trabalha com o conceito de espelhamento, ou seja, a instância da versão antiga e a instância da versão mais recente rodam em paralelo em produção e o **SRE** utiliza um **load balancer** para ir direcionando o tráfego da versão antiga para a versão mais recente.

O principal benefício desta técnica é que o downtime é zero, trazendo mais segurança para a transição. Apesar disso, [o custo para o blue-green deployment é bastante elevado](https://docs.charlescd.io/v/v1.0.x-pt/faq/deploy-em-circulos-e-outros-deploys), já que demanda o dobro de infraestrutura para ser executado.

###Círculos

A ideia consiste que se crie círculos de implementação, e disponibilize para cada circulo a versão de software que melhor convém para o usuário e para a regra de negócio.

> Círculos são grupos de usuários criados a partir de características específicas dentro de um mesmo ambiente. Dessa forma, o desenvolvedor pode segmentar os usuários de acordo com as regras que mais fizerem sentido para testar aquela release.

Fonte: [CharlesCD - ZupInnovation](https://docs.charlescd.io/v/v1.0.x-pt/principais-conceitos)

Por exemplo, é possível criar um círculo de engenheiros da região Norte do Brasil, outro de engenheiros do sudeste e um terceiro contendo todos os engenheiros brasileiros. Baseado nessa segmentação de clientes, pode-se elaborar diversas lógicas de deploy.

##Conclusão de uma desenvolvedora

Claramente que não há a melhor estratégia aqui, tudo vai depender da necessidade da empresa/instituição que vai implementar a aplicação e nível de conhecimento do SRE, por exemplo, para escolher qual será utilizada.

Na minha concepção, tendo a vivência de atuar na área comercial e de negócios e agora atuando como desenvolvedora, faz muito sentido utilizar o deploy em círculo para testar hipóteses desde de alterações na UX para o cliente (será que ele prefere um botão aqui ou ali? Isso aqui está mais legível para ele ou não? Esse pop-up é mais inclusivo para a terceira idade ou não?) até implementação de novas regras de negócio (precisamos aumentar a conversão de clientes nessa área do e-commerce, será que se expormos a oferta dessa forma funcionará? temos esse bug na rotina, mas será que é bug mesmo? Nosso público-alvo são os estudantes do sudeste, será que eles são os maiores usuários da nossa ferramenta?).

Por experiência minha, eu sofria demais com as demandas que clientes me passavam de mudanças que eles gostariam, mas nunca acontecia ou então demorava meses para "subir", com a ideia de deploy em círculos esse cenário muda drasticamente.

E você, o que acha desses conceitos? Algum faz mais sentido para você, assim como o deploy em círculos faz mais sentido para mim?

Compartilha aqui comigo!