The case for fewer environments

At Webera, we strive to build the underlying technology which supports innovation. Our team provides what we call DevOps as a Service, a small group of two DevOps/SRE Engineers, a DevOps Architect, and a Scrum Master. 

A DevOps team's objective is to help the developers get their code to the end-users as fast, safe, and stable as possible. We use automation, infrastructure as code, testing tools, vulnerability assessment, lots of monitoring software, pipelines, ticketing systems, office hours, and many other tools to perform this task.

The place where the developer's code and the work we do meets depends on each company's workflow. We try to influence the process in many ways but always keep a keen eye on DevOps' best practices and the value added by each step and lead time. 

So in a way, the DevOps' body of knowledge already provides significant pressure to push back extra work, which might have a questionable added value when we analyze the requirements for a reduced number of environments to test an application before it goes to production.

In this article, I want to focus on an argument that I picked up from the book The Scrum Fieldbook that shows, in chapter 3, how much a project can be impacted by what to some might be an insignificant problem: indecision.

Mr. Sutherland uses the CHAOS Report to provide insight into what causes many projects to fail. When the data of tens of thousands of projects are analyzed, there seems to be a profound correlation between project failure and extended decision-making intervals. It is astonishing since I would think that most of the issues would live in the old triangle of cost, time, quality.

Let's go back to the environments now. Most of the projects usually have three environments: development, staging, and production. But in reality, it varies. Probably at the very beginning of the project, you might have just one, and as the project matures and more external integrations or testers requirements are added, it might grow to several. Here is the problem, and I shouldn't criticize this because our business supports these environments. Still, based on the evidence that delay in a decision is the main culprit for project failures, each new environment added to production flow further delays delivering the project. Some might argue that they need more testing or that integration with the new application. Well, you know the arguments, I don't need to make them.

Based on the evidence, each new environment will always cause an additional delay in the decision-making process, which might cause the project to fail, and ultimately, our customers and our own business to struggle.

Our recommendation is to automate as many parts of the testing process as possible and reduce the deployments' batch size to avoid feature competition for testing resources, which inevitably will push the creation of new environments and force the developers and operations teams to support additional unnecessary work.

Let me know what you think!