<p>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”.  </p>

<p>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. </p>

CC BY-SA 4.0
2019-02-05T23:08:30.937Z
2019-12-27T18:41:48.537Z
2019-12-27T18:41:48.537Z
simbo1905
<p>I'd say whatever works for your context.</p>

<p>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.</p>

<p>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 <em>might</em> 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.</p>

CC BY-SA 4.0
2019-02-04T13:23:04.747Z
2019-02-04T13:23:04.747Z
Dan Cornilescu
<p>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<sup>1</sup> standardized at project level to ensure a consistent development stack across the team and with the production environment?
<br></p>

<p><sup>1</sup><sub>local virtual environment, chroot, container, remote login on a compile farm, ...</sub>
<br>
<sub>Note: somewhat related to a <a href="https://devops.stackexchange.com/questions/6195/blackbox-testing-vs-openbox-testing-applications-in-a-containerized-environment">previous
question</a> </sub></p>

CC BY-SA 4.0
2019-12-28T12:05:23.690Z
it's actually a good question; I thought it could be less opiniated if "what are pros and cons of where to install developments tools.."?
Ta Mu
<virtualenv>
Should development tools be installed on the host or in an environment standardized at project level?
Sylvain Leroux
# Should development tools be installed on the host or in an environment standardized at project level?

(Asked by: username_0 on 2019-02-04)

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](https://devops.stackexchange.com/questions/6195/blackbox-testing-vs-openbox-testing-applications-in-a-containerized-environment)

**Tags:** virtualenv

> **Comments:**
> **username_1**: it's actually a good question; I thought it could be less opiniated if "what are pros and cons of where to install developments tools.."?  

---

## 2 answers

### Answer by username_2 on 2019-02-05. Score: 3

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 by username_3 on 2019-02-04. Score: 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.


---

