0

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 environment1 standardized at project level to ensure a consistent development stack across the team and with the production environment?

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

closed as primarily opinion-based by Gaius, Bruce Becker, Tensibai Feb 7 at 12:52

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

2

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 artefacts where they cannot be overwritten. The artefacts are then deployed by any number of mechanism 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. Its 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 live that is kept as similar to the live environment as possible.

1

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.