Very early in my IT career, I learned that, as a matter of general best practice, companies almost always have at least two environments for critical systems and usually three for application development and management. Some companies, depending on their complexity and needs, have more than that. This is to enable the technology teams that support the company’s systems to develop and/or test new software without jeopardizing the operations of the business that are run in the Production environment.
Otherwise, IT people would be making changes and testing in Production– the thought of which will make any operational or management folk’s eyes wide with fear. The optimum scenario is that these different environments, and their respective components, resemble one another as closely as possible. Yet each is completely separate from the others, serving a purpose in the process of maintaining and enhancing system functionality for the organization. Before we get into specifics about each, let’s establish a working definition of an IT environment.
An IT environment is the collection of hardware, software, and network resources that are used to run and support the systems that people use to run an organization. They run applications, store and process data, and provide access to these to the company’s users. They can be of almost any size and can be hosted on-premise, in data centers, or the cloud. The naming and use-case specifics can vary, but the three most common environment types in an enterprise are Development (sometimes referred to in shorthand as “dev” or as a “sandbox” environment), Test (sometimes called QA for “quality assurance”, or “staging” or “pre-production”), and Production (the ever creative “prod”).
Let’s start with the most intuitive of these, Production. This is the “live” environment; the one that every active system end-user in the company will know and have access to. It is where people log in to do their jobs. It isn’t practice; it’s the game. As such, stability and reliability are paramount, and it is resourced accordingly. If it has problems, the business has problems. If something results in users being unable to access the resources required to do their jobs, it leads to lost time and resources for the company and consternation amongst employees. If an impact is significant, it can derail deliverables and affect the bottom line. For this reason, it is kept under strict change control. All IT functions such as development and testing are (ideally) kept completely out of the production environment. Changes are not migrated until thoroughly vetted and approved via an established process (which we’ll get to in a moment). Production is the baby that everyone rocks.
Taking one step back in the hierarchy, we have the Test environment: or Staging environment, or Pre-production. Companies call it different things, but the general idea is that this is the environment that is a) always in sync with the production environment in terms of software versions, data content, and configurations (except right before a new deployment to prod) and b) the last stop before changes get moved into Production. Because it is (ideally) a copy of the production environment, this is where IT delivery teams can perform a dry run of a change to verify the functionality being implemented and ensure that it won’t negatively impact the Production environment. It is also where the Production rollout plan can be tested and amended accordingly if unforeseen problems or forgotten steps reveal themselves. Stress or load testing that simulates Production-like levels of activity and throughput in Test can provide a reasonable level of assurance that IT is not introducing something that will break or degrade Production performance. Having an intermediary environment between where changes are made and their movement into Production takes a huge amount of uncertainty out of these tasks and helps protect critical business functionality.
Finally, we have the Development environment. As the name implies, this is where application development, configuration changes, new data model extensions, patches, and many other activities can be conducted away from Production. It gives IT a safe place to figure out what works, and more importantly, what doesn’t. This is where experiments can be run, and if something goes wrong it’s no harm, no foul (notwithstanding interfering with someone else’s work in the environment). For practical reasons, even though it’s where the new stuff happens, Development is sometimes allowed to languish, especially after a large initiative wraps up. This is unfortunate, but understandable, as much of what takes place there on a routine basis is mundane, minor change or break/fix development activity, and time and resources are diverted to more exigent needs. That reality aside, it is no less important to keep the Development environment attuned to its counterparts because testing new features, debugging new code, and trying out new configurations are all ultimately of the highest value in an environment that most closely resembles Production. Some things can be dispensed with, like parity of data where this is very large and costly, but generally, all the same rules apply. The value of it lies partly in how close a facsimile it is to the Production environment.
In summation, this model of having three environments, while far from being universal, is broadly used and does comport with the straightforward “code-test-deploy” development lifecycle. Development allows for experimentation and creation without impacting operations, Test allows for a Production-like dry run of deployments, and Production is where the real show happens. There are reasons that companies may have other environments such as a need for one dedicated to user training, disaster recovery, or supporting different development workstreams. Again, it all depends on that organization’s requirements and their cost-benefit analysis of the expense of these environments versus the benefits they offer. There are costs for these just like other assets, but at a minimum, it behooves any organization to have a non-production environment to avoid the risks inherent in changing the tires on a moving vehicle.
