The Environment Maturity Problem

In software we have different maturity levels for software: Dev, Release Candidate, and Released. These maturity levels are normally represented as 3 distinct runtime environments on top of which we run software:

The Dev environment is where Dev maturity software is deployed and comprises everything that is new, untested against load or that hasn’t have true integration with other services. Depending on your development practices this environment is the most likely to have failing software and with that the possibility of one service affecting another service’s ability to determine if it is OK to promote to Staging.

Code that has been successfully integrated against other services and gone through the battery of end to end tests is considered a Release Candidate and can be promoted to Staging where it will encounter more load and more scrutiny. This environment is usually meant to be a working environment most the time so software found to not work is usually reverted.

Finally, there is Prod, the environment your your paying customers are hitting and the one that can’t go down. Usually only runs Released software.

However, from the Site Reliability perspective, all these environments are business critical.

Making infrastructure changes that break the Dev environment halts the progress of many Dev teams.

Making infrastructure changes that break the Staging environment inhibits the company from validating completed features that customers are waiting for.

And there is no need to say anything about prod.

With that in mind, there is need for an additional environment for Infra Development that is often overlook.