Beyond the Twelve-Factor App

Chapter 9. Environment Parity

The tenth of the 12 factors, dev/prod parity, instructed us to keep all of our environments as similar as possible.

While some organizations have done more evolving, many of us have likely worked in an environment like this: the shared development environment has a different scaling and reliability profile than QA, which is also different than production. The database drivers used in dev and QA are different than production. Security rules, firewalls, and other environmental configuration settings are also different. Some people have the ability to deploy to some environments, but not others. And finally, the worst part of it all, is people fear deployment, and they have little to no confidence that if the product works in one environment, it will work in another.

When discussing the design, build, release, run cycle, I brought up the notion that the “It works on my machine” scenario is a cloud-native anti-pattern. The same is true for other phrases we’ve all heard right before losing hours or days to firefighting and troubleshooting: “It works in QA” and “It works in prod.”

The purpose of applying rigor and discipline to environment parity is to give your team and your entire organization the confidence that the application will work everywhere.¹

While the opportunities for creating a gap between environments are nearly infinite, the most common culprits are usually:

• Time
• People
• Resources

Time

In many organizations, it could take weeks or months ...