Consistent Environments

Environments should have homogeneous application configuration, software, operating system, infrastructure and data (where appropriate).

Rationale

Consistency between environments reduces the time wasted investigating issues due to discrepancies, which improves the speed of delivery for the business. This consistency also helps increase our confidence in what we build and its safe delivery to our customers and end users.

Implications

  • Configuration will need to be enshrined in version-controlled code.
  • Software packages that are not amenable to being consistently configured will be less desirable.
  • Software that is free, or provides cheaper licenses for development and testing, will be preferable.
  • We can perform push-button deployments of any version of the software to any environment on demand.
  • A single trunk-based CI build at the beginning of the pipeline is strongly recommended.
  • WWe will need to invest heavily in making data available and consistent across environments. Note: As of late November 2020, there is a lively debate going on regarding consistency of data across multiple services in non-production environments. There is not yet a consensus, and this implication slipped through the recent review of these principles. It should be considered “under review”.
  • Creating (and destroying) new environments, including appropriate data sets, will need to be as simple and as fast as possible and will rely heavily on the principle of Automate by Default.
  • Particularly where an “environment” is required to include a large set of (distributed) applications in order to facilitate end-to-end testing, the creation and maintenance of an environment can be very expensive. Reducing/limiting the number of environments may act as an enabling constraint – the fewer environments we have, the easier and cheaper it will be to keep them consistent.
  • We will require consistent configuration of infrastructure (including networks, firewalls and servers).