This 12-factor principle aims to minimize differences between environments.

Enterprise applications traditionally have quite some differences between the environments of the development process. There are development environments, maybe several of them, such as local workstations or dedicated server environments and finally there is the production environment. These environments differ in regard of time when software artifacts in certain versions and configuration are deployed during the development process. The longer the time span of simultaneously having different versions in the set of environments the greater this difference becomes.

There is also a difference in teams and people. Traditionally software developers maintain their own development environment while an operations team takes care of production. This introduces potential gaps in communication, processes, and used technology.

The technical difference between environments contains the biggest risk. Development or test environments that use different tools, technology, external services and configuration than production introduce the risk that these differences will lead to errors. Software is tested automatically on these environments before going to production. Every difference from production that is not tested can and eventually will introduce bugs that could have been prevented. The same is true for exchanging tools, backend services, or used stacks for lightweight alternatives in development or local environments.

It is therefore advisable to keep the environments as similar as possible. Especially, container technologies and orchestration frameworks highly support this approach. As we saw previously, differences in configuration, services, and technology are minimized or at least explicitly defined via the environment. Ideally, software landscapes are identical on development, test environments, staging, and production. If that is not possible, service abstractions as well as environment-managed configuration support to manage the differences.

The difference in time and people is tackled by usage of Continuous Delivery, not just from a technical but also organizational point of view. The overall time to production should be as small as possible, enabling fast delivery of features and bug fixes. Implementing Continuous Delivery naturally moves teams and responsibilities together. The DevOps movement describes how all engineers are responsible for the overall software. This leads to a culture where all teams closely work together or merge into single teams of software engineers.