Climbing The Environment Ladder

/via http://www.commitstrip.com/en/2017/02/10/proud-or-worried/

Think about the all the different environments that your product runs in. You probably ran through some variation of the following, no?

1. 1. One Environment To Rule Them All. It was just you, all the code is on your laptop (and GitHub), and “deploy” pretty much translates to “Runs on my Laptop”. Come demo time for that sweet sweet investor money, you just spun the stuff up on AWS, and that was about it.
   This is really pretty much the default when you’re starting off.
2. 2. Environment As Coordinator. You’ve got environments deployed so that multiple teams can co-ordinate their efforts. Alice’s team deploys the latest version of Component A to the development environment on AWS, and a wee bit later Bob’s team complains that something broke. 
3. This is quite common for “Integration Testing”, but equally common when folks are starting out with micro-services and/or distributed systems. When you don’t quite have a handle on how to test/validate these, it’s just easier to have an actual environment — “dev”, “dev2”, “dev3”, etc. — against which you can throw stuff (mind you, chaos ensues, inevitably…)
4. 3. Environment as Infrastructure. Here, environments are just virtual artifacts of your deployment infrastructure. Everything runs — effectively — identically across your laptop and AWS, thanks to k8s, docker, and whatnot. Your environment happens to be the feature branch that you’re working on, and data-stores, load-balancers, etc. are abstracted away.
   This is roughly where things end up once you figure out Reliability, Reproducibility, DevOps, and so forth. Mind you, the overhead in getting here is fairly high, but you’re at the stage where you need this overhead.
5. 4. Environment as Nuance. This one is a bit of a catchall, where you are effectively running some or all of the above at different times. For example
   • You’ve got a hacked version of a component that you’re building out in your own feature branch on your laptop. It’s got nothing to do with anything else. (So, -1-)
   • It’s got some tricky co-ordination issues with stuff Alice is working on, so you spin up a “develop” environment, deploy it out there, and you/Alice do some live development/testing against that environment (So, -2-)
   • When it has reached a minimal/appropriate level of functionality, you integrate it into the build system, and make sure everything works correctly (So, -3-)

And yes, there is a definitely a bit of a cross-product that happens here, where you’re multiplying the number of abstracted items (data-stores, load-balancers, whatnot) by the number of shared environments, but hey, that’s why you have a lovingly crafted CI/CD/CT tool-chain that allows you to specify all of these in your config files, right? RIGHT?

Note: There is a version that I didn’t mention above, viz. Environment As Code. Here, the “Environment” (scare quotes intentional) is baked into the code. Think myApp -env=development configures the db accessors to hit the dev database, -env=production hits the prod database, and so on.
And yeah, this shouldn’t ever be a thing, but I keep running into it, so, seriously, WhyTF is it a thing? I mean, seriously, don’t do this. You should NEVER do this.