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

21–30 of 67 posts

Re: Tilt: dev environment as code

#21

Post by cirego »

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…

I think that's a fair point -- you're making a tradeoff. And the best part is that you don't need to choose one or the other.

In my case, I find that I prefer having higher fidelity and simpler service code by using Tilt to avoid mocks. It's also nice for frontend development because, using a Kubernetes ingress, you can avoid the need for things like frontend proxies, CORS and other development-only setup.

Re: Tilt: dev environment as code

#22

Post by cirego »

turtlebits wrote: post #18
patwoz wrote: post #17

How does Tilt compare to “skaffold dev“? We use skaffold exactly for that purpose. To develop within a the cluster.

Skaffold works but its DX is pretty poor. Too many knobs via yaml- tilt has just enough magic that it doesn't feel like a chore to setup local dev.

I've always appreciated that Tilt chose Starlark instead of YAML. Makes things so much cleaner!

Re: Tilt: dev environment as code

#23

Post by cirego »

philip1209 wrote: post #19

If you want to see Tilt in action, our Chroma open-source repo uses it to run the distributed version of the database for development and ci. It's pretty cool - just clone then run `tilt up` and it's working: https://github.com/chroma-core/chroma

Thank you for sharing this! I think your Tiltfile just showed me how to solve something that's been bugging me for a while!

I see that you also have docker-compose files -- are those for different tasks or for developer preference?

I'm also curious to understand why you have different build scripts for CI (`buildx`) vs local (regular docker build)? In our team, we use the same build processes for both.

Re: Tilt: dev environment as code

#24

Post by tomjakubowski »

cirego wrote: post #22
turtlebits wrote: post #18

Earlier quoted context omitted.

Skaffold works but its DX is pretty poor. Too many knobs via yaml- tilt has just enough magic that it doesn't feel like a chore to setup local dev.

I've always appreciated that Tilt chose Starlark instead of YAML. Makes things so much cleaner!

Well, now you've really got me interested. Almost every case of a YAML eDSL would be better served by Starlark instead, in my Bazel-brained opinion.

Re: Tilt: dev environment as code

#26

Post by eats_indigo »

patwoz wrote: post #17

How does Tilt compare to “skaffold dev“? We use skaffold exactly for that purpose. To develop within a the cluster.

Migrated from Skaffold to Tilt at my last co, found it was much more easier to configure granular rebuild rules, which lead to faster dev loop cycles

Re: Tilt: dev environment as code

#27

Post by eats_indigo »

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?

I think if you ever have highly dynamic infrastructure requirements -- think along the lines of a control plane that's spinning up additional workers -- it's really helpful to be able to run your infra provisioning logic locally. There's nothing worse than having to wait on cloud builds to test your iterations.

Re: Tilt: dev environment as code

#28

Post by cirego »

tomjakubowski wrote: post #24
cirego wrote: post #22

Earlier quoted context omitted.

I've always appreciated that Tilt chose Starlark instead of YAML. Makes things so much cleaner!

Well, now you've really got me interested. Almost every case of a YAML eDSL would be better served by Starlark instead, in my Bazel-brained opinion.

I think Tilt Extensions highlights the combined power and composability that using Starlarks brings to Tilt: https://docs.tilt.dev/extensions.html.

Want to create a Kubernetes secret? It's as simple as:

    load('ext://secret', 'secret_yaml_generic')
    k8s_yaml(secret_yaml_generic(...))
Want to create that secret from Vault instead?

    load('ext://vault_client', 'vault_read_secret', 'vault_set_env_vars')
    vault_set_env_vars('https://localhost:8200','mytoken')
    my_foo = vault_read_secret('path/myfoo', 'value')
    my_bar = vault_read_secret('path/mybar', 'foobar')

Re: Tilt: dev environment as code

#30

Post by dharmab »

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 our host laptops as we edit source files, and live-reload the new artifacts into running Kubernetes containers. The reload happens so fast that we configured our environment to compile+deploy+run on save, and the new code is already running by the time you reach for the "run tests" button.

I think if you told our team to go back to Docker Compose they'd revolt on the spot haha

Post reply on HN