Should development tools be installed on the host or in an environment standardized at project level? [closed]

Question

On a development host, do you consider it still worth installing the development tools (compiler, interpreter, package manager, testing tools, ...) on the host? Or are the developers supposed to interact with those tools through an environment¹ standardized at project level to ensure a consistent development stack across the team and with the production environment?

¹_{local virtual environment, chroot, container, remote login on a compile farm, ...
Note: somewhat related to a previous question}

Answer 1

At many companies (eg banks) the provenance of the code that gets out to live needs to be known and traceable. This is typically done by having a controlled build farm that builds from source. Release builds upload the binary artefacts to a location where they cannot be overwritten. The artefacts are then deployed by any number of mechanisms that are traceable to an individual and an approved change request. This model is generally just referred to as a ”pipeline”.

Under such a model a ”dev host” or ”dev environment” can have anything and everything that developers want on it. It can use newer versions of software than are available in production. It's entirely down to the context whether that is going to cause problems with code failing testing in a live-like environment. It's typical to put release build code through at least one test environment before pushing it to live. That environment is kept as similar to the live environment as possible.

Answer 2

I'd say whatever works for your context.

It's not always possible to have a standardized environment (as in container/VM solutions) at the project level which can be used effectively regardless of the host type/state. For example we had some massive builds for which we used finely tuned bare-metal machines for performance reasons - ~40% faster builds than with the most performant environment the ops teams could offer). So we used hosts in this case.

But nothing stops you from having host configurations standardized at the project level (which is what we had). Or, better yet, standardized environments running on standard-configured hosts - which might allow you to achieve higher optimisation levels by using existing host resources instead of building them from scratch in each environment - if that's what you're really after.