Hello,
I have a likely all too familiar problem for engineers. Whenever you checkout a repo for the first time or go back to a repo after not working on it for a while, it almost always takes hours to get a local dev environment setup so that you can build/test/run again. Even the best README is usually flawed.
Our company has grown large enough that I'd like to fix this problem once and for all with automation. I have a ton of ideas how to do this, but I don't want to reinvent the wheel. I've found surprisingly little information on the current state of the art in this area so thought I'd ask the community.
Some things to steer the conversation:
- I am not interested in VMs. IMO they're too clunky and slow and a VM per repo is just not reasonable.
- I am not interested in containers. I primarily work with mobile and desktop apps, which don't lend themselves well to dev via containers. I do believe it would be possible to manage this through containers, but there'd be a lot of fiddling that I think would be hefty to maintain.
- Re the above two points, I personally think tools are mature enough to support dev on bare metal, e.g. things like nvm, pyenv, direnv and more all facilitate "sandbox like" development.
- As an example of what I'd like to happen. I envisage checking out a repo and then simply running `make dev` in that repo and you're done
- I'd like to ensure we avoid drift between local dev and CI setup. Whilst CI can sometimes have a few differences with local dev, usually I find 95%+ of things are shared. So a solution that lends itself to code once, work on both would be preferable.
- I'd like things to be reusable, e.g. if someone needs to setup node development in one repo then it should be easy to reuse that code to setup node dev in another repo.
- I'd prefer low overhead, e.g. just some python scripts. I don't want engineers to have to understand lots of tools just to setup their repo. For example, I'm sure a tool like ansible could be used for this. Ansible is not super difficult to understand, but it's a barrier to entry for engineers who haven't used it and don't deal with those concepts regularly. Put another way, I'd like a minimal set of tools that "most" engineers will be familiar enough with.
- No shell solutions please! 😬 I'm fine with make, but would prefer it calls out to something higer level.
Phew! Over to you guys.
submitted by /u/HormyAJP
[link] [comments]
from Software Development – methodologies, techniques, and tools. Covering Agile, RUP, Waterfall + more! https://ift.tt/uXe8d0V