Hmm, I've never worked at a company where this was a requirement. In fact, I've worked at companies where the majority of the time, the developer environments never came close to the production environments.
What has mattered most is that a staging env mirror the prod env. This I have experienced and built numerous times. Also, an integration env between development and staging has also been fairly common.
Cool article, enjoy the summary of relevant knowledge that's been passed around various circles.
I do disagree with:
> Environments like staging or pre-prod are a fucking lie.
You need an environment that runs on production settings but isn't production. Setting up an environment that ideally has read-only access to production data has saved a huge number of bugs from reaching customers, at least IME.
There's just so many classes of bugs that are easily caught by some sort of pre-prod environment, including stupid things like "I marked this dependency as development-only but actually it's needed in production as well".
Development environments are frequently so incredibly far removed from production environments that some sort of intermediary between production is almost always so helpful to me that the extra work involved in maintaining that staging environment is well worth it.
It's not the same as production obviously, but it's a LOT closer than development.
It's important to ensure that the software you're developing runs as expected in the production environment. That does not mean that the development environment and the production environment need to be the same. For example, it's very likely that the development tools you're using will (or should) not be deployed. This extends to anything else about the development environment, as long as you're able to consistently deploy the software to the production environment.
This also assumes that there is only one production environment. Some software is expected to work on different architectures or OSes, some quite dissimilar to each other. For example, some software runs on Linux, macOS, and Windows. A developer (or development team), probably has (and should have) access to all of these environments for testing, but likely does development in the one they're most comfortable with.
reply