4 ms·
It's been pretty smooth the two places I've worked. Both have used a virtual machine setup with config that's partly shared with production, so there's incentiv
by egonschiele 6y ago
It's been pretty smooth the two places I've worked. Both have used a virtual machine setup with config that's partly shared with production, so there's incentive to make sure things are up to date.
- stephenr 6y agoA VM/container setup is the way to go, with as much as possible shared from prod setup processes. Specifically, it should be very automated and repeatable to bring up an environment, either from the last working state (i.e. to boot the vm) but also to bring up a fresh environment - potentially following a teardown/destroy. I quite like Vagrant for this - it's multi platform, works across multiple providers (i.e. you might use HyperV on Windows, Joe might use VBox on Mac, Bob might use VMWare on Linux, Sally might use LXC on Linux) and has quite a healthy range of plugins to extend functionality.
- konha 6y agoThere is no better boost to productivity when starting at a new place than having a working dev environment in VMs or containers. Bonus points if it comes with sensible config defaults and can be started with a single command. This is one of those things that immediately pays dividends as soon as more than one person works on a codebase. No need for everyone to rediscover independently how to get a complex app running locally.
- yourabstraction 6y agoDo you find that working in VMs or containers hampers developer productivity once you're up and running?
- konha 6y agoNot if you can provide a good developer experience with live reloading, a debugger, a way to run the test suite etc.