Pitch: Ergomake - Previews de pull-requests full-stack [brasileiros na YC S23]
Fala turma! Me chamo Lucas e sou um dos founders da Ergomake. Somos uma empresa brasileira e estamos no batch S23 da Y Combinator!
Sempre que você abrir um pull-request, a gente faz o deploy da sua aplicação inteira e te dá um link de preview pra você e seu time testarem.
Nesse post eu vou explicar um pouquinho sobre por quê ambientes de previews são úteis e como tudo funciona do nosso lado, tecnicamente falando.
Por que eu usaria um "preview"?
Deixa eu te contar uma coisa: código quebrado não é somente aquele que não funciona; é todo código que seu product manager não quer em produção.
Hoje em dia é raramente vejo software sem testes, mas frequentemente vejo empresas em que os times de produto e design não participam do processo de revisão de código. Isso é tão problemático quanto código sem testes.
O primeiro problema gerado por essa má prática, é que seu time jamais vai conseguir praticar "continuous delivery", afinal, desenvolvedores vão inevitavelmente aceitar pull-requests com código indesejado. Ainda que o código funcione, uma mudança indesejada impede que o projeto seja deployado à qualquer momento, logo, viola os princípios necessários para entrega contínua.
Pra evitar esse problema, você já deve ter visto times que mantém um ambiente de "staging" ou "homologação". Infelizmente, esses ambientes não resolvem nada. Eles apenas tornam mais evidente a necessidade de trazer revisões de produto e design pra mais cedo no ciclo de desenvolvimento.
Além dos problemas e custos associados com a manutenção desses ambientes, eles tendem à se tornar um gargalo para o time. Uma vez que código só pode ir pra produção após um deploy em "staging", cria-se uma "fila" para usá-lo. Inclusive, quando "staging" quebra, ninguém pode fazer deploys.
"Mas feature flags não resolvem esse problema?"
Elas ajudam, mas não são suficientes. Feature flags sempre podem ser usadas pra novas funcionalidades, mas embutir feature flags em toda decisão de design ou produto tende à criar uma grande bagunça e um estado difícil de gerenciar.
E como a Ergomake resolve isso?
Uma vez que você instala a Ergomake no seu repositório do GitHub, nós geramos um link de "preview" sempre que você abrir um pull-request com mudanças ou fizer um push para um PR existente — tudo automaticamente.
Assim, basta seu time de produto ou design clicar no link e dar feedback. Nada de ficar rodando scripts ou seguindo longos manuais de instruções.
Além disso, como o review de produto acontece antes do merge, você evita ter código quebrado no main.
Atualmente, temos clientes usando até pra QA ou para coletar feedback de clientes antes de subir alterações.
Mas meu preview não precisa ser igualzinho à produção?
Vou te contar um segredo: é impossível replicar produção!
Se você tem estado na sua aplicação, é impossível replicar produção. Mesmo que você espelhe todo tráfego de produção para um "staging" você ainda teria uma aplicação com um estado diferente dado que algumas pessoas usam apenas staging. Além disso, mesmo que você espelhasse "staging" para produção, ainda haveria possibilidade de ações ocorrerem em sequências diferentes.
Interessante! Posso saber como funciona?
Claro! Já que a grande maioria do pessoal por aqui é dev, vou dar um overview técnico de como implementamos o sistema do nosso lado.
Quando você instala o Ergomake no seu repositório, o GitHub vai registrar que agora o Ergomake tem permissões para ler o docker-compose.yml da pasta .ergomake. É esse arquivo que vamos usar pra subir a sua infra de preview do nosso lado.
Além disso, o próprio GitHub vai começar à nos enviar WebHooks sempre que você abrir um pull-request nos repositórios no qual o app está instalado. Ao receber esses WebHooks, nós pedimos ao GitHub um token para ler seu seu docker-compose.yml. Depois, transformamos o compose em manifests no Kubernetes e aplicamos no cluster falando com o api-server do Kubernetes.
Uma vez que tudo estiver aplicado, o usuário vai acessar os serviços rodando do nosso lado através de um ingress para aquela URL de preview. De dentro do cluster, os serviços falam usando o nome um do outro, assim como acontece no docker-compose.yml — ou seja, você pode usar o hostname postgres para falar com sua instância do Postgres, por exemplo.
Já as builds, se você tiver um Dockerfile, são feitas usando um projeto chamado Kaniko, para que possamos rodar docker-in-docker.
E como eu faço pra usar?
Basta fazer login em app.ergomake.dev e instalar o aplicativo no seu repositório do GitHub. Uma vez que você tiver feito isso, vamos começar à gerar previews assim que você comittar um docker-compose.yml na pasta .ergomake do seu repositório.
Quanto custa?
O Ergomake é de graça para até 3 links de preview disponíveis.
No plano pago, de 200 dólares ao mês, você terá acesso à infinitos links disponíveis, além de outras features só disponíveis no plano pago.
Desconto do TabNews
Pra agradecer você por ter chegado até aqui, o cupom TAB50 vai te dar 50% de desconto durante 6 meses no plano Standard.
O cupom é válido só até dia 30 de junho e apenas 10 deles estão disponíveis.
Se você quer trocar uma idéia ou precisa de ajuda com alguma coisa, fique à vontade pra mandar uma pergunta aqui na thread ou marcar uma call comigo nesse link. Vou adorar te ajudar à configurar tudo :)
Fonte: https://ergomake.dev