Most of my professional life was spent working with banking, insurance, telco and media. Clients with mature processes in place that yield predictable results. In these industries, "safety is king". They are "control freaks"! And Cloud solutions are only "a dream" on most cases. On premises is still how they live. So, with this mindset you can expect (lots) of bureaucracy in place when staging software. The focus is not on "rapid continuous delivery" but rather more complex release processes spread through wider release cycles. They privilege stability over "the latest and greatest" that comes out of whatever software provider. This isn't a problem "per se". It's methodologies they've been maturing for decades to fit their business goals. Now, having said all this, you can expect the complexity illustrated below for a typical staging scenario in these types of clients:
(click to enlarge)
Again, keep in mind this scenario is all using on premises.
So, how does your code get to production? Send a Zip file? Well, it's not that simple. Safety first right? Risk aversion! You might have noticed that I separated environments by team types: Development Teams versus Operational Teams. Project is rolling and it's time to got to production. Until QA, it's up to the development teams to promote software in a repeatable process that can be easily replicated. The jump to QA typically implies filling a rather complex form (normally using Change Management tools) with lots of info, namely, "why is this going to production", "impact analysis", "risk analysis", "who authorized", "who's the business group that requested the features", "who are the business users that will validate things... and on and on.
(click to enlarge)
It also implies instructions to operational teams on how to deploy, rollback, etc. This is very important because, from QA onward, the deploy in the environments will be in charge of operational teams that might not have the slightest context about what is going to production and what changes it implies. After some time, if QA is "ok" and property validated... there's another request to pre-production, identifying issues that appeared in QA, etc etc. To production! Even more complex because if it's an upgrade to an existing system with an agreed operation time of 24/7, then no downtime. You have to clearly state how is that "no downtime" guaranteed and a special authorization might be required. Ok, this is a 24/7 scenario but there are apps that can have agreed times to upgrade production.
Does all this sound like fun? No. But, again, safety first. Where does all this fit this post? Well, in a recent project we had to create a new system, from scratch. No environments setup yet, no processes in place. Just a blank sheet of paper and a white board for us to do our best.
We started with only a development environment. That spawned to QA and, afterwards, production. Then... you see where this is going right? Well, not quite. Dev, QA and production are "olympic minimums". But more than that? Would you buy all the complexity from these industries? Maybe not. Maybe you value the "rapid continuous delivery". Maybe you just want some parts, the ones that do fit your use case. Processes? YES! Excess bureaucracy? Maybe not. Maybe not. We’re currently evolving our system to fit our needs. We recently created the concept of "trains" because it made sense in our context.
Summing up: The complex processes that are typically found in banking, insurance, telco and media are good learning points, but you'll probably want to create your own. Their processes were matured throughout decades to fit their needs. I've learned to appreciate them. I do prefer other approaches, but I recognize the value of all this for these clients.
If, like me, you have the privilege to define the future of your organization and build something from scratch: It's really amazing! Learn from good examples. Then build your own good example.