Development vs Staging vs Production: What's the Difference?

The lines between development, staging, and production environments are often blurred. The distinctions may vary depending on many factors, including: 

• the scale of the organization,
• the codebase, or 
• whether you're viewing the environment from a product, unit testing, or security standpoint.

In this post, I use interviews with fellow developers to understand each environment's purpose and how it's distinct from the others. It's particularly challenging to differentiate between the development and staging environments, and some organizations forgo the staging environment altogether. 

Let’s get to it. 

What Is a Development Environment?

Generally, the development environment is the first environment developers use to check if all code changes work well with each other. It's known as a “sandbox” for developers to work in. Examples of commonly used integrated development environments (IDEs) are Visual Studio Code and Atom. You should note that historically the development environment is usually on a developer's laptop—a local machine, but with the emergence of cloud, on-demand computing and ephemeral environments, those environments are now being deployed in the cloud. 

In my experience as a developer, the IDE is where developers’ workflow with code reloading and debugging aids are enabled. Also, this environment is where developers can make necessary code changes. In the IDE, approved code can merge with code from other developers working on the same project. 

Developers commonly use this space to experiment and receive feedback on what improvements they can make to their work. Consequently, this environment is the most unstable. It's also the most susceptible to bugs and potentially broken code. But, on the upside, in allowing mistakes to happen, this is the most conducive environment to learn collaboratively and create a standardized process.  

Furthermore, there are three environments within the development environment, according to the Indeed Editorial Team. Besides the most commonly known local machine, there are virtual and cloud-based development environments. The reason for the virtual and cloud-based environments mainly depends on whether multiple platforms and machines are used. 

Development environments historically would only include a small subset of the entire application and many times would lack elements like security, 3rd party APIs and cloud native services. Those would typically be introduced later in the development process and tested in staging. The results, however, would be frequent rollbacks and bottlenecks in staging. To enable better code quality in development and more frequent release cycles, companies like Releasehub came up with ephemeral environments, a production-like replica that allows developers to properly test their code (i.e shift-left) and isolate bugs to a single branch, while ensuring a smooth merge to staging and production. 

What Is a Staging Environment?

According to Releasehub, “A staging environment is the environment where your code is 'staged' prior to being run in front of users so you can ensure it works as designed.” 

The staging environment should mirror production as much as possible. It reflects a production environment not yet exposed to clients, customers, and the general public. 

This environment is primarily used for system integration testing (SIT) and in-depth manual testing conducted before the client receives code changes. According to Unitrends, other tests developers perform in this environment are quality assurance (QA), security testing, chaos testing, alpha testing, beta testing, and end-to-end (E2E) testing. 

Additionally, user acceptance testing (UAT) often happens before production. In UAT, users can test changes they requested before the new code goes to a production environment. 

How you carry out testing in the staging environment can depend on what programming language you're using. For example, Ruby on Rails doesn't have a mode for staging. Rails developers switch modes to a test environment that they use to run testing tools and debug failures. Technically, the Rails Guide delves into how to customize configurations and initialization on applications. 

Development vs. Staging Environments 

So, now that you know what development and staging environments are, you're probably wondering if you should need both. Truth be told, the answer depends on the size of your organization. 

Sometimes smaller companies start out with fewer environments. One developer I interviewed shared, “You just end up with multiple environments as the organization scales up.”  

There are cases in which organizations with fewer users don't have staging environments. As another developer I interviewed elaborated at length, 

“Instead, we can deploy as such that 1% of the traffic will go to each one branch and main branch. Then, we can check the monitoring to see if there are differences between the two. When we are certain that at the most we will affect 1% of traffic and everything is fine, we will then proceed with merging the two branches. I think it would be ideal if the continuous integration (CI) and continuous deployment (CD) process were to set up that 1%, then we could verify the results. This is the same as I have seen for verifying front-end changes in continuous integration.” 

Is a Staging Environment Necessary? 

It's better to merge and deploy code quickly rather than have a staging environment where untested code might linger. Using CI/CD in testing can have many benefits that may prevent problems. Tommy McClung, the former CTO of Truecar discussed his experience with staging environments here, . 

One benefit is that it balances out real input: you risk a bad result for only a small amount of your live traffic while you're able to get the most accurate test results. 

Developers say they like to see how real traffic works through the codebase and compare this technique to feature flagging. This may eliminate the need for a beta environment. This results in the concept of "staging" not being a distinct environment. 

However, developers agree that it's useful to have a separate beta domain to make significant changes. According to Atlassian CI/CD, feature flagging allows developers to turn functionality on and off during runtime. That way, you don't need to deploy code at every update. 

What Is a Production Environment?

The production environment is the live site complete with performance optimizations. The codebase must be secure, performant, stable, and able to sustain heavy traffic as the client, customers, and public use it.  

Therefore, you must treat it with great care. You should restrict who updates the production code. Ideally, you won't be building new versions of the codebase for the production environment; it's better to deploy the same builds to the staging environment. 

At this point of the software development lifecycle, the code shouldn't have any bugs or require fixes. To avoid a poor user experience, you should consider it the final product. 

However, you can make urgent fixes in the production environment if needed. In doing so, you can consistently improve upon quality control for product releases, making it easier to keep tabs on new product updates. 

Conclusion

Although the development, staging, and production environments converge, they have their own significance in the larger software development lifecycle. The significance of each environment depends on the organization running the system. 

The way a company treats and leverages these environments today differs wildly depending on the organization and its DevOps practices and policies. Sometimes teams within the same organization use these environments in different ways and have different philosophies of what they mean. 

From my conversations with many individuals that play different roles in the tech industry, I can say the overall development culture is shifting progressively toward promoting new code to all these environments as soon as possible. One developer expressed, "The idea is that even the smallest code change gets released to production in a matter of minutes, not months." 

With that in mind, the common goal is that the folks responsible for the software development life cycle want more efficient environments for producing the highest quality codebases. These people continuously strive to find new methods to make that process easier. 

For a better understanding of what environments are and to be inspired about optimizing them, read more about staging environments, ephemeral environments, and UAT with release ephemeral environments.