← Back to context

Comment by hamandcheese

2 days ago

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 want to run natively on macOS).

There seem to be a lot of tools in this space. I wish they wouldn't call themselves tools for "dev environments" when they are really more like tools for "deploying an app to your local machine", which is rather different.

6 comments

hamandcheese

Reply
SOLAR_FIELDS  1 day ago

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 the same across all of them.

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.

OptionOfT  2 days ago

Not to mention the developer experience is usually sub-par.

I firmly believe that the primary way of interacting with my tests should be the ability to run them one by one from the IDE, and running the code should be run / attach with breakpoints.

  • michaelmior  2 days ago

    It takes some work, but it's entirely possible to both use Docker and run individual tests with breakpoints (in a Docker container) in your IDE. For example, you can attach VS Code to a running container.

    • elktown  1 day ago

      Yes, but it creates a restrictive and fragile happy-path when the aim imo should be closer to a lab/woodshop where you can take it apart however you like and need for the moment.

  • jbverschoor  1 day ago

    Shell containers under code are unbearably laggy and crappy.

    I simple have a container for each project using my own container-shell

    I run my bundles / whatever. Have all the tooling and can use VSCode to attach via ssh (I use orbstack, so I get project hostnames for free)

    It’s the best workflow for me. I really wanted to like containers but again, it’s too heavy, buggy, bulky.

    http://github.com/jrz/container-shell