Tilt - Gestionar el entorno de desarrollo como código

• Herramienta gratuita y de código abierto para la automatización de entornos de desarrollo para desarrollo de microservicios basado en Kubernetes
• Automatiza el flujo de cambio de código → monitoreo de archivos → construcción de imágenes → actualización del despliegue, por lo que es posible levantar todo el entorno con el comando tilt up
• Aunque se centra en Kubernetes, también soporta flujos de trabajo basados en docker-compose y comandos locales
• Fue adquirida por Docker en 2022, pero sigue manteniéndose y evolucionando como un proyecto independiente de código abierto
• Su objetivo es la gestión integrada moderna del entorno de desarrollo para manejar la complejidad de los microservicios

---

Qué es Tilt

• Las apps modernas no son un binario único, sino una estructura en la que múltiples servicios, bases de datos y servidores frontend interactúan por HTTP
• Tilt es una herramienta de entorno de desarrollo para microservicios que permite entender y gestionar todos estos componentes complejos de una sola vez
• Automatiza por completo el proceso de modificar archivos, construir imágenes y actualizar servidores para acelerar el desarrollo

Equipos que deberían usar Tilt

• Es ideal para equipos que desarrollan apps basadas en microservicios
• Resulta especialmente útil para equipos que abren muchas ventanas de terminal para gestionar logs de servidores o configuran el entorno de desarrollo con scripts de shell complejos
• Con un solo comando, tilt up, cualquiera puede levantar fácilmente el mismo entorno de desarrollo

Por qué se centra en Kubernetes

• Kubernetes proporciona bloques estandarizados para ejecutar servidores, como contenedores, pods y servicios
• Si se usa este estándar también en el entorno de desarrollo, se puede reducir la diferencia entre el entorno de producción y el de desarrollo
• Además de Kubernetes, Tilt soporta docker-compose y comandos locales, pero se espera que a largo plazo converja hacia un enfoque centrado en Kubernetes

El desarrollo y futuro de Tilt

• Tilt fue originalmente una startup independiente, pero fue adquirida por Docker en 2022
• Actualmente sigue siendo de código abierto y continúa mejorando en integración con Docker Compose y Docker Desktop
• También se están desarrollando nuevos proyectos, con la intención de expandir las ideas de Tilt a un ecosistema de desarrolladores más amplio

El significado del nombre

• "Tilt" se inspira en la historia de Don Quijote arremetiendo contra los molinos de viento
• El nombre de la app de demostración es Servantes, en referencia a Cervantes, autor de Don Quijote

[GN⁺]

Comentarios en Hacker News

• Me parece interesante ver este tema aquí. He usado Tilt durante varios años, pero siento que el ritmo de desarrollo se ralentizó después de que Docker lo adquirió

  • Tilt crea un entorno de desarrollo local para que los servicios se ejecuten igual en producción, pruebas y desarrollo
  • El código de los servicios se ha simplificado mucho y la calidad ha mejorado
  • En especial, hace falta mejorar la parte que maneja los CRD (no hay forma de indicar que k8s_yaml depende de un CRD, así que la invocación de tilt up se rompe con frecuencia)
  • Lo primero que hago al empezar un proyecto nuevo es hacer que funcione tilt up
  • Entre las cosas con las que lo he probado están recolectores basados en eBPF para seguridad y observabilidad, pipelines de datos, desarrollo de charts de Helm y controladores de Kubernetes
  • Es muy flexible y potente para muchos tipos de desarrollo

• Este pitch me da un poco de risa

  • Las apps modernas están compuestas por demasiados servicios. Están por todas partes y comunicándose constantemente
  • Así que hicimos una herramienta para que sea más fácil crear todavía más servicios

• Siempre hay una compensación entre velocidad y precisión

  • Si intentas mantener un entorno de integración local, termina siendo demasiado lento y costoso
  • El problema no es Kubernetes en sí, sino que a medida que aumentan las dependencias, intentar ejecutar una copia del mundo en local se vuelve cada vez más lento
  • Me gustan los entornos de desarrollo rápidos y concisos usando algo como docker-compose. Eso permite simular algunas dependencias para mantener la velocidad. Si las pruebas locales pasan, entonces en otros entornos se usa Kubernetes

• Creo que un "entorno de desarrollo" realmente debería ejecutar las pruebas directamente con las herramientas nativas del lenguaje, por ejemplo cargo test, bundle exec rspec, etc.

  • Si tuviera que ejecutar una VM que corre Kubernetes, y esa VM a su vez ejecuta contenedores Docker para correr las pruebas, me molestaría muchísimo
  • Hacer esto bien y de forma confiable todavía requiere mucho trabajo. Si el objetivo es no usar Docker, puede requerir aún más trabajo (es indispensable para ejecutar de forma nativa en macOS)
  • Parece que hay muchas herramientas en este espacio. Ojalá no las llamaran herramientas para "entornos de desarrollo". Se parecen más a herramientas para "desplegar una app en tu máquina local"

• No puedo dejar de mencionar nix-shell: enlace de nix-shell

• Si quieres ver Tilt en uso real, en nuestro repositorio open source de Chroma lo usamos para ejecutar una versión distribuida de la base de datos para desarrollo y CI. Está muy bueno: haces clone y luego ejecutas tilt up y funciona

  • enlace de Chroma

• Nunca ha sido un problema configurar el entorno local

  • Un despliegue de clúster único es muy fácil
  • El problema es que los servicios que administramos en producción están desplegados en varias regiones (o clústeres de k8s)
  • El problema es depurar aplicaciones distribuidas

• ¿Cómo se compara Tilt con "skaffold dev"? Nosotros usamos skaffold para ese propósito. Lo usamos para desarrollar dentro del clúster

• Hace poco probé Tilt por un rato. También probé Tilt, Garden y quizá algunas otras, y terminé quedándome con DevSpace

  • Si mal no recuerdo, era lo que mejor encajaba con la infraestructura de producción que ya teníamos. No hacía falta reescribir todo de otra manera
  • Es decir, encajaba bien con la configuración existente de kustomize+k8s. Añade port forwarding y sincronización rápida de archivos hacia los contenedores en ejecución. Eso es realmente todo lo que quiero. No me gusta tener que reconstruir imágenes cada vez que hago un cambio

• ¿Esto no es esencialmente dev containers?