Ask HN: How do you provision new developer environments? | Hacker News Reader

Ask HN: How do you provision new developer environments?

2 pointschrisacky6 comments

We're hiring 5-6 new developers, and I know that setting up a development environments can be a nightmare. Trial and error, things going wrong, what solutions have you learnt over the years that makes this as pain free and easily replicable as possible?

We will be providing all hardware/equipment for the new onsite developers, but looking at having a workflow in place that helps people write new code on day one, rather than spending two days installing everything and then having to repeat it again in a weeks time for the next recruit.

View on HN

Manually and inefficiently. It helps that turnover is low.

At least now the process is documented. Two years ago it was trial and error.

All the dependencies take a while to compile, but we've done it enough times now and have the operations written down precisely enough that aside from some data indexing tasks that have to run overnight (and which aren't strictly necessary to get started developing) we can set up a new environment in about 3 hours.

Next step is probably a bash script to automate most of the process on each of our 2-3 most commonly used platforms.

docker and Makefiles as task runners. I have a git repo that is the skeleton for this idea: https://github.com/undernewmanagement/flight-deck

On mac we have homebrew to pull in all the desktop apps and cli tools. Then a simple bash script to automate all of it.

I've managed to "retrofit" this into a team of 20+ devs and product owners for a variety of services.

We are even piloting this with sales and support so that they can stay abreast of bleeding-edge development and provide valuable feedback.

There has to have been a solid solution before docker or containerization in general, what do giant companies use?

At the giant company I worked at. A central server which kept a canonical mirror of all the tools (except visual studio which was installed using whatever tool large companies use to install and update applications on windows machines) and all the dependencies for everything and then just a handful of .bat files that basically just used robocopy to make sure your build environment was up to date and correct.

Not pretty, but it worked. The big advantage was that since everybody was getting all their tools and dependencies from the same place everybody was using, not only the same version, but also exactly the same binary of everything.

Binary packages. Once you package all your software and all your software's dependencies into packages, a development environment (the one that needs deps in their compiled form and your software in its source form) is just one `apt-get build-dep' away, which is a bonus to the main point of easy production deployment.

The important thing is that, no matter what solution you go for, all build dependencies should always be pulled directly from a central server that you control. If your build process involves grabbing arbitrary stuff directly from a github account not directly under your control you will, sooner or later, end up in trouble.

Reply on news.ycombinator.com