When maintaining large software systems, you will likely have multiple environments with names like Prod, Staging, Dev, Eval, UAT, Daily, Nightly, or some remix of these names. To distinguish this type of environment from the dozen other things in software development that we give that same name, these are often formally referred to as Deployment Environments.
One question I’ve never been asked directly is: “What is an Environment?” This is surprising; because not understanding what Deployment Environments actually are is one of the most common pitfalls I see in my day-to-day work.
What is a Deployment Environment
A Deployment Environment is a consistently connected set of
- processes
- datastores, and
- any ecosystem around them (e.g., cron jobs, analytics, etc.)
making up a fully functioning software system.
This definition is quite intuitive, but the devil is in the details. In this case, that detail is the phrase “consistently connected”.
A Note
- In most architectures, processes are also known as services. In this context, any server-side program interacting with the rest of your system (e.g., an API endpoint, a Service that makes or receives RPCs, a long-running process that writes to and reads from a database, etc.) is a process that makes up an environment.
- Datastores are often databases, but can also include any storage or service that persists data long-term (e.g., writing data to disk or an S3 Bucket).
- The ecosystem around these can include a lot of other infrastructure, like pubsub channels, offline cron jobs that process data, and others.
What consistently connected entails
Ideally, environments should be perfectly isolated; no data or RPC should leak between processes and data stores across environments during normal operation.
A Case Study
