
Ask HN: How do you provision new developer environments? - chrisacky
We&#x27;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?<p>We will be providing all hardware&#x2F;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.
======
twobyfour
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.

------
sheraz
docker and Makefiles as task runners. I have a git repo that is the skeleton
for this idea: [https://github.com/undernewmanagement/flight-
deck](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.

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

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

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

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

