DEV Community

Gabriel de Biasi for Trybe

Posted on

Como a Trybe corrige mais de 20 mil avaliações por semana!

Para quem não conhece a Trybe, é uma escola de desenvolvimento web que tem comprometimento genuíno com o sucesso profissional de quem estuda conosco. Com o Modelo de Sucesso Compartilhado (MSC) ofertado pela Trybe Fintech, a pessoa estudante tem a opção de pagar apenas quando já estiver trabalhando, você acredita nesse nível de confiança?

gif

E para isso precisamos ter um infraestrutura para avaliar todos os projetos enviados pelas pessoas estudantes! Hoje utilizamos GitHub Actions, entretanto, usar os executores oferecidos pelo próprio GitHub Cloud não é o suficiente, pois esgotaríamos os minutos oferecidos pelo plano rapidamente.

Simulação de uma pessoa estudante esperando pela sua avaliação

Simulação de uma pessoa estudante esperando pela sua avaliação

Logo, optamos por manter nossa própria infraestrutura de self-hosted runners, e melhor ainda, tudo orquestrado usando Kubernetes!

Veja na imagem abaixo como é o esquema de funcionamento. Após isso, temos o passo-a-passo explicando o fluxo.

Passo 1: A pessoa estudante envia seu projeto como um pull request no repositório.

Passo 1

Passo 2: De acordo com a configuração do workflow, o trigger é acionado e uma nova avaliação é inserida na fila de workflows do repositório;

Passo 2

Passo 3: Os self-hosted runners funcionam como pull-based, ou seja, eles fazem pulling no GitHub API aguardando por jobs à serem executados.

É possível que não haja runners disponíveis no momento. Então, nós temos um controller que se comunica com o GitHub API sobre a condição atual dos runners. Se não houver runners disponíveis no momento, o controler aciona o Horizontal Runner Autoscaler para escalar para cima o número de runners em nossa infraestrutura.

Passo 3

Ao mesmo tempo, nosso controler também verifica se não temos "runners demais": Se mais de 50% dos runners atuais estão em idle, isso significa que podemos diminuir o número de runners para melhorarmos nossos custos com infraestrutura. O controler aciona o Horizontal Runner Autoscaler para escalar para baixo o número de runners em nossa infraestrutura.

Passo 4: A avaliação é feita utilizando uma série de actions implementados pelo time da Trybe. Essas actions envolvem linters de arquivos, execução do cypress, testes unitários, etc.

Passo 4

Passo 5: Após executar a avaliação, a última action do workflow envia o resultado obtido para o nosso backend de avaliações, para ser armazenado em nosso banco de dados.

Passo 5

Passo 6: Como muitas pessoas estudantes enviam suas avaliações ao mesmo tempo, foi implementado uma solução utilizando Amazon MQ, para enfilieirar o processo de avaliação e também evitar um possível rate limit na API do GitHub.

Passo 6

Passo 7-8: Após processar a avaliação que estava na fila de mensageria, o backend de avaliação faz um comentário no PR da pessoa estudante, informando o resultado!

Passo 7-8

Bem simples, né? O processo parece ser complicado, mas é necessário pelo tamanho da demanda que temos em corrigir mais de 20 mil avaliações por semana. Agora veja todo o processo em apenas uma figura:

Processo Completo
Processo de correção

Gostou do que viu? Quer ajudar a Trybe a manter esta infraestrutura? Venha pois temos várias vagas abertas!!

Top comments (3)

Collapse
 
psanrosa13 profile image
Paula Santana

A solução é bem legal mas ainda não entendi alguns pontos, vocês topariam conversar para entender melhor alguns pontos?

Collapse
 
gabrielbiasi profile image
Gabriel de Biasi

gabriel.biasi [arroba] betrybe.com me manda um e-mail :)

Collapse
 
pedrobarreto profile image
Pedro Barreto • Edited

Legal demais 👏👏👏 não fazia ideia da complexidade do evaluator