undefined | Better HN

0 pointsbhuga1y ago0 comments

> 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.

0 comments

codethief1y 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.

bhugaOP1y 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.

codethief1y 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.

j / k navigate · click thread line to collapse

0 pointsbhuga1y ago0 comments

> Isn't this a matter of not reusing old VMs after a `git pull/checkout`, though?

0 comments

codethief1y ago

bhugaOP1y ago

> I don't think those would change often

codethief1y 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.

j / k navigate · click thread line to collapse