A Superhuman reduziu o tempo de build de 22 para 8 minutos com o Semaphore

  • ⛔️️ Ferramentas diferentes gerenciando o processo de CI
  • ⛔️ Feedback lento e caro
  • ✅ Apenas uma ferramenta para gerenciar todos os processos
  • ✅ Um ciclo de feedback mais rápido e barato

Experimente o Semaphore

O desafio

A Superhuman se orgulha de ser o cliente de email mais rápido do mundo e quer aplicar esse valor de velocidade em todas as suas ferramentas internas. Antes do Semaphore, rodar testes e fazer deploy era muito lento. A equipe usava o Wercker para o backend (adquirido pela Oracle alguns anos atrás). O serviço de CI do frontend seguia o “modelo antigo” de cobrança por paralelismo máximo, e eles ainda usavam outro serviço de CI para os builds do cliente desktop.

A Superhuman precisava de um serviço que:

  1. Fosse construído do zero para ser rápido.
  2. Suportasse a assinatura de código no macOS.
  3. Realizasse a cobrança pelo tempo real de uso, não pelo paralelismo máximo.
  4. Tivesse um alto nível de paralelismo máximo.
  5. Respondesse quando fizessem contato.

A solução

O backend da Superhuman é escrito em Go. Quando o código é enviado para qualquer branch, o Semaphore compila e executa os testes. Quando os testes passam na branch ‘master’ ou ‘staging’, o Semaphore constrói as imagens Docker, as carrega no Google Container Registry e, em seguida, as implementa gradualmente no cluster do Google Container Engine.

O frontend é escrito em JavaScript. Quando o código é enviado para qualquer branch, o Semaphore executa o Zen (um executor de testes criado por um dos engenheiros) para rodar todos os testes. O Zen compila o código, o carrega no S3 e inicia 600 instâncias do AWS Lambda para rodar os testes em paralelo (o worker do Semaphore coordena isso). Quando os testes passam nas branches ‘staging’ ou ‘production’, o Semaphore automaticamente cria um pacote e o carrega no Google Cloud Storage.

our solution

Os resultados

O Semaphore tem um desempenho significativamente melhor, as máquinas não estão sobrecarregadas e você pode rodar muitos builds em paralelo. Além disso, é muito mais barato do que o modelo antigo, que reservava capacidade e recursos para 10 jobs paralelos (o que é um desperdício 80% do tempo e insuficiente 10% do tempo).

  • ✔️ Melhor desempenho
  • ✔️ As máquinas não estão sobrecarregadas
  • ✔️ Executar muitos builds em paralelo
  • ✔️ Mais barato que o modelo antigo
Setor

Busca de emprego e recrutamento

Stack Tecnológico

Go

Javascript

Docker

GKE

Aws Lambda

Star us on GitHub