Hacker News new | ask | show | jobs
by codethief 662 days ago
Maybe I'm missing something here but couldn't you just track the whole VM setup (dependencies, dev tools, telemetry and everything) in your monorepo? That is, the VM config would get pulled from master just like everything else, and then the developer would use something like nixos-shell[0] to quickly fire up a VM based on that config that they pulled.

[0]: https://github.com/Mic92/nixos-shell (not to be confused with nix-shell)
1 comments
bhuga 661 days ago
Yes, but this still "freezes" the VM when the user creates it, and I've got no tools to force the software running in it to be updated. It's important that boxes can be updated, not just reliably created.

As just one reason why, many developers need to set up complex test data. We have tools to help with that, but they take time to run and each team has their own needs, so some of them still have manual steps when creating a new dev server. These devs tend to re-use their servers until our company-wide max age. Others, to be fair, spin up a new machine for every branch, multiple times per day, and spinning up a new VM might not be burdensome for them.

link
codethief 660 days ago
Isn't this a matter of not reusing old VMs after a `git pull/checkout`, though? (So not really different from updating any other project dependencies?) Moreover, shouldn't something like nixos-shell take care of this automatically if it detects the VM configuration (Nix config) has changed?
link
bhuga 660 days ago
> Isn't this a matter of not reusing old VMs after a `git pull/checkout`, though?

Yes, but forcing people to rebase is disruptive. Master moves several times per minute for us, so we don't want people needing to upgrade as the speed of git. Some things you have to rebase for: the code you're working on. Other things are the dev environment around your code, and you don't want that to be part of the checkout as much as possible. And as per my earlier comment, setting up a fresh VM can be quite expensive in terms of developer time if test data needs to be configured.

link
codethief 659 days ago
You seem to assume you would have to rebuild the entire VM whenever any code in git changes in any way. I don't think you do: You could simply mount application code (and test data) inside the VM. In my book, the VM would merely serve to pin the most basic dependencies for running your integration / e2e tests and I don't think those would change often, so triggering a VM rebuild should produce a cache hit in 99% of the cases.
link
bhuga 658 days ago
> I don't think those would change often

I think this is where our contexts may differ, and so we end up with different tradeoffs and choices :) The services running on our dev servers are updated dozens of times per day, and they roughly correspond to the non-code parts of a VM.

link
codethief 657 days ago
Or maybe we just used terminology differently. :) Why wouldn't those services be part of the code? After all, I thought we were talking about a monorepo here.
link