Marcio Rodrigues
Oct 9, 2018 · 4 min read

Com uma boa arquitetura, testes A/B e chaveamento na borda

O contexto

Durante alguns anos no VivaReal, muitas pessoas trabalharam para substituir um grande legado monolítico por uma stack mais sustentável, baseada em microservices com responsabilidades mais definidas, deployments independentes, tolerância a falhas mais efetiva, etc. Enfim, uma stack moderna e pronta para mudanças e novas features.

Eu tive o prazer de acompanhar a última milha dessa longa jornada. Que foi a migração do https://www.vivareal.com.br/ para um dos últimos sistemas dessa stack a ficar pronto: o render!

Mas, antes de mais nada, eu separei artigos de outras pessoas que escreveram sobre outras partes dessa aventura:

  • O Bin fala sobre como foi a separação dos assets e templates que possibilitou a transição para o novo render ser tão tranquila e transparente para o frontend.
  • A Sabrina fala sobre o início dos testes e2e no site do VivaReal que possibilitou realizarmos muitos refactorings. Além de pegar alguns bugs bem chatos durante o desenvolvimento do novo render.
  • O Erick fala sobre o início do time de plataforma que mantém serviços vitais para o funcionamento dos sites (provavelmente o maior cluster de Kubernetes do Brasil é o nosso)!
  • E nesse outro post eu falo em como fizemos para juntar todos os dados de todos os microservices que existem aqui no Grupo Zap para o frontend e o render utilizarem!

A estratégia

Como os assets já estavam separados, nós decidimos fazer o chaveamento na borda e o novo render (feito em NodeJs) e o antigo render (um pedaço já bem pequeno do legado monolítico em Java) acessariam sempre a última versão dos assets na mesma origem.

O desafio nesse ponto foi encontrar uma maneira de fazer esses dois sistemas coexistirem servindo no mesmo domínio. Sendo que o novo render deveria ser utilizado somente quando um determinado parâmetro estivesse presente na query string, por exemplo ?__vt=ch:a , faz com que um request recebido seja servido pelo novo render e sem o parâmetro pelo antigo.

Duas origens para o mesmo domínio

Como utilizamos a Cloudflare como nosso servidor de borda, fomos logo pesquisar se havia alguma forma de fazer diretamente lá… e sim, existe uma feature muito interessante chamada Resolve Override que se encaixou exatamente nas nossas necessidades! Com ela podemos, dada uma expressão de URL, por exemplo, https://www.vivareal.com.br/venda/*__vt=ch:a* , selecionar um outro servidor como origem, aqui tem um exemplo mais concreto.

Assim conseguimos chegar em um cenário bastante favorável para a nossa migração:

Seleção de usuários para usar o novo render

Fonte

Para a seleção de usuários que seriam os nossos beta testers nós utilizamos uma ferramenta de testes A/B, o Google Optimize. Com ela conseguimos direcionar qualquer percentual dos nossos usuários para essa URL com o parâmetro na query string que era servida pelo novo render.

Como a ferramenta já era utilizada no site do Viva Real, foi realmente muito simples aproveitá-la para o nosso propósito.

Baby steps

Com a forma de chaveamento entre os backends e a seleção dos usuários definidos, nós começamos a fazer a virada para o novo render uma página por vez.

Primeiro as páginas mais simples até chegar nas mais complexas. Sempre acompanhando os erros que ocorriam e corrigindo-os rapidamente.

Também conseguimos comparar o tempo de resposta dos dois backends e fazer ajustes quando necessário.

Quando algo dava muito errado, nós simplesmente desligávamos o teste A/B ou a regra de chaveamento na borda, corrigíamos o problema e começávamos novamente.

Conclusão

Dessa forma conseguimos realizar a virada de um backend para outro com muita tranquilidade e, além de tudo, conseguimos acompanhar diversas métricas entre o antigo e novo backends. Por exemplo: conversão, bounce rate, tempo de resposta, percentual de erros e muitas outras.

Isso só foi possível por que nós delimitamos sempre as mudanças ao menor tamanho possível. Isso fez com que algumas novas funcionalidades e sistemas fossem utilizados primeiro no legado e, sim, implementamos um monte de coisas que foram jogadas fora. Mas poder fazer essa virada de forma tão sustentável e segura valeu a pena cada linha de código. Até aquelas que ficaram em produção somente algumas semanas.

Tech@Grupo ZAP

Como fazemos tecnologia nos maiores portais de imóveis do Brasil

Thanks to Caio Silva

Marcio Rodrigues

Written by

Tech@Grupo ZAP

Como fazemos tecnologia nos maiores portais de imóveis do Brasil

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade