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?

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.

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 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 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.

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 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 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 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!

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:

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