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!!
Top comments (3)
A solução é bem legal mas ainda não entendi alguns pontos, vocês topariam conversar para entender melhor alguns pontos?
gabriel.biasi [arroba] betrybe.com me manda um e-mail :)
Legal demais 👏👏👏 não fazia ideia da complexidade do evaluator