Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tilt: dev environment as code

github.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Tilt: dev environment as code

#61

Post by campbel »

oulipo wrote: post #50
campbel wrote: post #42

I did a blog post for Linkerd showing some of the benefits of using Tilt https://linkerd.io/2024/12/02/tilt-linkerd-nginx-part-1/ . TL;DR you can run some of your infra in local-dev that provide parity with your production environment.

I'm using Pulumi for this right now (with a dev setup and a prod setup), what would be the benefit for me to use Tilt over this?

Tilt is useful for local-dev where you are going to be modifying code / k8s configs and want live reload when you make changes. That is almost the entire appeal.

Re: Tilt: dev environment as code

#62

Post by hdjrudni »

siliconc0w wrote: post #16

You're always trading off speed with fidelity. Usually, trying to maintain a local integration environment is going to become too slow and expensive. The problem isn't even necessarily Kubernetes, but as dependencies increase it just gets slower and slower to try and run a copy of the world locally. I like a fast svelte dev environment with something like docker-compose which might require some mocked out dependencie…

You can always swap out some of those services for always-running prod or dev-in-the-cloud services.

I have a big mix of setups for my projects. I like Vite+Bun (client+server) for smallish projects because the dev servers start instantly. But then I have to remind myself how to actually productionize it when it comes time for that, but it's not too hard.

Then sometimes I need to bring in a database. I don't like running those locally, undockerized because now you're locked into one specific version and it just gets messy. So sometimes if I'm lazy I just connect to my prod database server and just create a separate dev DB on it if needed. Then I don't need to start and stop anything, I just connect. Easy.

For a big complex app you can mix-and-match any of the above. Run the services that you need to iterate heavily on locally, and just farm out the rarely changing stuff to the cloud.

Re: Tilt: dev environment as code

#63

Post by hdjrudni »

sigmonsays wrote: post #4

i don't get the value of a tool like this. Do we really struggle bringing up services as containers and applying kube configs? For my development of services that run in kube, I don't dev with kube, you shouldn't have to. I also use docker-compose for most dev env services. Perhaps i'm not developing the right kind of software. Whoever finds this type of tool useful, when would you use it?

How do you make everything reproducible on the dev machines then? And manage versions of all the software?

Re: Tilt: dev environment as code

#64

Post by hdjrudni »

I briefly tried Tilt awhile back. Tilt, Garden, maybe a couple others, settled on DevSpace. IIRC, it aligned best with my existing prod infrastructure without having to rewrite everything a different way.

i.e., it worked with my existing kustomize+k8s setup. It adds portforwarding, and fast file sync into the running containers, which is all I really want. Rebuilding an image every time you make a change sucks.

Re: Tilt: dev environment as code

#65

Post by hamandcheese »

SOLAR_FIELDS wrote: post #59
hamandcheese wrote: post #37

I still think "dev environments" really ought to be running tests directly with your languages native tool. e.g. `cargo test`, `bundle exec rspec`, etc. If you make me run a VM that runs Kubernetes that runs a docker container that runs the tests, I will be very, very upset. Doing this properly and reliably can still be a lot of work, possibly more work if not relying on Docker is a design goal (which must be if you…

I actually have the exact opposite viewpoint: if you’re managing a platform with multiple teams what you are suggesting is way more of a pain than a standardized, container based workflow. You want a language agnostic test runner that runs generic commands. The reason for this is that you want to be able to quickly skill up engineers and have them able to quickly switch codebases since the interface (like tilt) is th…

> You give up a bit of snappiness, sure, but you can also keep the very small non container based tooling like linting outside of the container.

You give up way more than snappiness. Doing real development work, i.e. compiling, testing, debugging, is very cumbersome in a remote environment.

So where do you want to spend your time? Bandaids to make remote development suck less, or effort to develop locally, natively? There is no free lunch. If you choose "neither", your developer experience is gonna suck. (Most companies choose "neither" by the way, either consciously or unconsciously).

Re: Tilt: dev environment as code

#66

Post by SOLAR_FIELDS »

hamandcheese wrote: post #65
SOLAR_FIELDS wrote: post #59

Earlier quoted context omitted.

I actually have the exact opposite viewpoint: if you’re managing a platform with multiple teams what you are suggesting is way more of a pain than a standardized, container based workflow. You want a language agnostic test runner that runs generic commands. The reason for this is that you want to be able to quickly skill up engineers and have them able to quickly switch codebases since the interface (like tilt) is th…

> You give up a bit of snappiness, sure, but you can also keep the very small non container based tooling like linting outside of the container. You give up way more than snappiness. Doing real development work, i.e. compiling, testing, debugging, is very cumbersome in a remote environment. So where do you want to spend your time? Bandaids to make remote development suck less, or effort to develop locally, natively?…

> Doing real development work, i.e. compiling, testing, debugging, is very cumbersome in a remote environment.

it really isn’t? Of course it depends on the ecosystem. But for jvm for example you literally just expose your debugging port 5005 out of the container and boom step through, and other live debugging works just as well as outside of the container. And as of course you allude to, if you’re native you are facing a “works on my machine” problem unless you are all in on a hermetic and reproducible solution like bazel or nix. And chances are unless you are having that crack team of 10xers that a good hunk of your dev user base are going to struggle with the complexity and general ecosystem issues with these two solutions.

You’ve probably seen the worst world where people do containers wrong. And a lot of people do them wrong. But it’s pretty easy to learn how to do them right. Someone can study multi stage docker builds for half a day and write perfectly fast, cached first containerized builds. Proper buildkit cached local containers are extremely fast.

There’s other ways of course, each with their own tradeoffs. You can do everything in nix, and now you are spending your time fighting with nix. You can do everything in bazel and now you are spending time fighting with bazel. In the end your stuff is gonna go into a container anyway (for most people). You still need to understand the container technology because of that. so why not both reduce your toolchain sprawl and simultaneously recreate that exact environment on the local machine?

Re: Tilt: dev environment as code

#67

Post by sigmonsays »

dharmab wrote: post #30
sigmonsays wrote: post #4

i don't get the value of a tool like this. Do we really struggle bringing up services as containers and applying kube configs? For my development of services that run in kube, I don't dev with kube, you shouldn't have to. I also use docker-compose for most dev env services. Perhaps i'm not developing the right kind of software. Whoever finds this type of tool useful, when would you use it?

Our team switched from Docker Compose (without Kubernetes) to Tilt for a distributed systems development environment. (Think platform engineering work on a system that scales from zero to several hundred thousand instances). Our time to go from code change to testable, running code on our laptops went from about a minute to a couple of seconds, using some Tiltfile recipes to do automatic incremental recompilation on…

tilt might be nice but I do not develop in containers or kubernetes. Tilt to me looks like more glue on top to make updating kube fast. It might make sense for some but it seems pointless to me.

If I can run external dependencies in docker locally, I can setup my app to run entirely from my laptop. That's all docker-compose does, just runs dev deps like DBs and other services i'm not editing code of.

As far as code reloading goes, there is a million tools to do that already. Go already compiles locally much faster than seconds.

All that being said, why are people choosing to develop in containers/kubernetes?

Maybe apps that need to be more tightly integrated with kube would benefit from this?

Post reply on HN