Tilt - gerenciando o ambiente de desenvolvimento como código

• Ferramenta gratuita e open source de automação de ambiente de desenvolvimento para desenvolvimento de microsserviços baseado em Kubernetes
• Automatiza o fluxo alteração de código → monitoramento de arquivos → build de imagem → atualização de deploy, permitindo subir todo o ambiente com o comando tilt up
• É centrado em Kubernetes, mas também oferece suporte a workflows baseados em docker-compose ou comandos locais
• Foi adquirido pela Docker em 2022, mas continua sendo mantido e evoluindo como um projeto open source independente
• Tem como objetivo a gestão integrada moderna do ambiente de desenvolvimento para lidar com a complexidade dos microsserviços

---

O que é o Tilt

• Apps modernos não são um único binário, mas uma estrutura em que vários serviços, bancos de dados e servidores de frontend interagem via HTTP
• O Tilt é uma ferramenta de ambiente de desenvolvimento para microsserviços que permite entender e gerenciar todos esses componentes complexos de uma vez
• Automatiza todo o processo de alteração de arquivos, build de imagens e atualização de servidores para acelerar o desenvolvimento

Equipes que devem usar o Tilt

• É adequado para equipes que desenvolvem apps baseados em microsserviços
• É especialmente útil para equipes que gerenciam logs de servidores abrindo várias janelas de terminal ou configuram o ambiente de desenvolvimento com scripts de shell complexos
• Com apenas o comando tilt up, qualquer pessoa pode montar facilmente o mesmo ambiente de desenvolvimento

Por que ele é centrado em Kubernetes

• O Kubernetes fornece blocos padronizados de execução de servidor, como contêineres, pods e serviços
• Ao usar esse padrão também no ambiente de desenvolvimento, é possível reduzir a diferença entre o ambiente de produção e o de desenvolvimento
• Além do Kubernetes, o Tilt também oferece suporte a docker-compose e comandos locais, mas a expectativa é que, no fim, tudo convirja para um modelo centrado em Kubernetes

O desenvolvimento e o futuro do Tilt

• O Tilt era originalmente uma startup independente, mas foi adquirido pela Docker em 2022
• Ele continua open source e vem sendo aprimorado em integração com Docker Compose, Docker Desktop e outros recursos
• Novos projetos também estão em desenvolvimento, com a intenção de expandir as ideias do Tilt para um ecossistema de desenvolvedores mais amplo

O significado do nome

• "Tilt" foi inspirado na história de Dom Quixote investindo contra moinhos de vento
• O nome do app de demonstração é Servantes, em referência a Cervantes, autor de Dom Quixote

[GN⁺]

Comentários no Hacker News

• Interessante ver este tópico aqui. Uso o Tilt há alguns anos, mas parece que o ritmo de desenvolvimento diminuiu depois que foi adquirido pela Docker

  • O Tilt cria um ambiente de desenvolvimento local para que os serviços rodem da mesma forma em produção, teste e desenvolvimento
  • O código dos serviços ficou muito mais simples e a qualidade melhorou
  • Especialmente na parte de lidar com CRDs, precisa melhorar (não há como indicar que k8s_yaml depende de um CRD, então o tilt up quebra com frequência)
  • Quando começo um projeto novo, a primeira coisa que faço é fazer o tilt up funcionar
  • Entre as coisas em que usei para testes estão coletores baseados em eBPF para segurança e observabilidade, pipelines de dados, desenvolvimento de charts Helm e controladores Kubernetes
  • É muito flexível e poderoso para vários tipos de desenvolvimento

• Esse pitch me parece meio engraçado

  • Os apps modernos são compostos por serviços demais. Eles estão por toda parte e se comunicando o tempo todo
  • Então criaram uma ferramenta para facilitar a criação de ainda mais serviços

• Sempre existe um compromisso entre velocidade e precisão

  • Se você tentar manter um ambiente de integração local, ele acaba ficando lento demais e caro demais
  • O problema não é o Kubernetes em si, mas sim que, à medida que as dependências aumentam, tentar rodar uma cópia do mundo localmente fica cada vez mais lento
  • Eu gosto de um ambiente de desenvolvimento rápido e enxuto usando algo como docker-compose. Isso permite simular algumas dependências para manter a velocidade. Quando os testes locais passam, outros ambientes usam Kubernetes

• Acho que um "ambiente de desenvolvimento" realmente deveria executar os testes diretamente com as ferramentas nativas da linguagem, por exemplo cargo test, bundle exec rspec etc.

  • Se eu tiver que rodar uma VM com Kubernetes, e essa VM rodar contêineres Docker para executar testes, eu vou ficar muito irritado
  • Ainda dá muito trabalho fazer isso direito e de forma confiável. Se o objetivo for não usar Docker, pode dar ainda mais trabalho (é absolutamente necessário para rodar nativamente no macOS)
  • Parece haver muitas ferramentas nessa área. Eu preferia que não as chamassem de ferramentas para "ambiente de desenvolvimento". Isso está mais para ferramentas de "implantar o app na máquina local"

• Não dá para deixar de mencionar o nix-shell: link do nix-shell

• Se quiser ver o Tilt em ação de verdade, usamos no nosso repositório open source do Chroma para rodar uma versão distribuída do banco de dados para desenvolvimento e CI. Muito legal — é só clonar e rodar tilt up que funciona

  • link do Chroma

• Configuração de ambiente local nunca foi o problema

  • Fazer deploy em um único cluster é muito fácil
  • O problema é que os serviços que gerenciamos em produção são implantados em várias regiões (ou clusters k8s)
  • O problema é depurar aplicações distribuídas

• Como o Tilt se compara ao "skaffold dev"? Nós usamos o skaffold para esse objetivo. Usamos para desenvolver dentro do cluster

• Testei o Tilt por um tempo não muito atrás. Usei Tilt, Garden e talvez mais algumas outras coisas, e acabei ficando com o DevSpace

  • Pelo que lembro, era o que melhor se encaixava na infraestrutura de produção existente. Não precisava reescrever tudo de outra forma
  • Ou seja, funcionava bem com a configuração existente de kustomize+k8s. Adicionava port forwarding e sincronização rápida de arquivos com os contêineres em execução. Isso é realmente tudo o que eu quero. Não gosto de reconstruir a imagem a cada mudança

• Isso não é essencialmente dev containers?