DEV Community

Cover image for Difference Between Development, Stage, And Production
Milecia
Milecia

Posted on • Updated on

Production Environment Difference Between Development, Stage, And Production

There are three different environments that you'll probably deal with at some point. Each environment has its own properties and uses and it's important to use them accordingly. Once you know what the environments are used for it'll make since why we have so many of them.

The main three environments are: development, stage, and production.

Development

This is the environment that's on your computer. Here is where you'll do all of your code updates. It's where all of your commits and branches live along with those of your co-workers. The development environment is usually configured differently from the environment that users work in.

It'll be connected to some local database or a dummy database so that you can write your code without messing up the real data. Since there will be multiple people working in the development environment, you'll also handle any branch merging.

Nothing you do in the development environment affects what users currently see when they pull up the website. This is just for you and the other web devs to see how new features will work and to try out improvements.

A lot of preliminary testing will happen in this environment. You don't want to release your code before you make sure it works locally at least. Go through your code as thoroughly as you can so that you limit the bugs that squeak through to the next environment.

Stage

The stage environment is as similar to the production environment as it can be. You'll have all of the code on a server this time instead of a local machine. It'll connect to as many services as it can without touching the production environment.

All of the hard core testing happens here. Any database migrations will be tested here and so will any configuration changes. When you have to do major version updates, the stage environment helps you find and fix any issues that come up too.

If you have a client, this is when you would be able to give them a demo of how things work and look. They will be able to see how things will work when they make it live and they will be able to give you any feedback you need. Think of the stage environment as the place you do the last checks and you polish things up.

Production

Every time you talk about making your project live, this is the environment you are talking about. The production environment is where users access the final code after all of the updates and testing. Of all the environments, this one is the most important.

This is where companies make their money so you can't have any crippling mistakes here. That's why you have to go through the other two environments with all of the testing first. Once you're in production, any bugs or errors that remain will be found by a user and you can only hope it's something minor.

Some people like to do roll-outs to the production environment. That means they release changes to a few users and gradually roll them out the everyone. Not all of your updates have to be released into the production environment at the same time.

In some cases, you might roll out your changes on a schedule to handle load issues or to make sure that there aren't any major issues sneaking through. You can release changes to the production environment without going through the stage environment if there's an emergency although it's not something you want to do regularly.

Different organizations will deal with these environments in their own ways. Some of them have different names or there may be more environments than these. Regardless, you know what you need to in order to make the best use of each of them.

As a side note, I know the stage environment can be a pain sometimes. It takes so much work to set up this fake production environment and write all of the tests for it. Although it is worth the time. It's better to go ahead and get this step over with because it'll save your butt more than you'll ever know.


Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding

Top comments (16)

Collapse
 
gualtierofr profile image
Gualtiero Frigerio • Edited

We use docker so for us is really easy to replicate an environment on our PCs and Mac.
And we usually have 4 of them:

  • development is what you have on your local machine
  • stage: not stable, built with the last contributions from git
  • QA: same data as production
  • production

QA is really important, as we usually clone the filesystem and database of production and use this environment to test what will happen when we build the backend with a Git tag. We can update QA with the tag, run tests, have some people log in to check if everything is ok then we can rebuild the container for production.
I know some companies name the environments differently, so Stage is similar to production and QA is the unstable env. Some others use names like "pre production" or "acceptance" for the last env before production.

It is however important to have at least 3 environments not counting the dev one

Collapse
 
joshualine profile image
Joshua Chinwendu

thanks for sharing.

Collapse
 
thejerrylee profile image
Jaroslav Suchý • Edited

Thanks for this article, I found there the environment names that I often read about in various articles.
In our team we have

  • dev
  • feature
  • hotfix
  • release
  • production

Where production is clear, release is a version for clients and testers like a copy of production with new things, hotfix is to test some fast fix in case we find something on production, that needs to be fixed fast, feature is to be able to publish for test some special feature, that needs to be tested on the server or by product manager before it goest to release (used rarely only if needed) and dev is for the developers, where they can try various things - from testing speed of the server, trying the migrations and so on. Or just as another host to publish work (for project manager) if all other hosts are already occupied.
So the names conventions are different, but the idea is similar. I was interested what the "stage" or "staging" means.. As I understand it is like the "release" of ours ;)

Collapse
 
joshualine profile image
Joshua Chinwendu

thanks for sharing

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
priteshusadadiya profile image
Pritesh Usadadiya

let me throw a another one here "QA Environment"

Basically, everything related to testing will happen here including Feature Testing, Exploration Testing, Build Testing, Regression testing etc..

Once we are sure about the release build, we move it to Stage.

My Team has Stage environment but we treat it as a Locked environment and is houses same configurations and code as Production Environment. We use it as copy of current released build and to compare behavior of various user stories of QA.

Test data on this environment should be also as close as actual production so that end users (clients) can have proper demos / training on this one before actually doing anything on production.

Once release build moves to this environment, Every tests must pass here, with 0 Bug count.

Collapse
 
nickitaliano profile image
nicholas italiano

Perfect article for a Python data noob going into production (after staging these past 2-3 weeks)... "DevOps" FTW!👍

Collapse
 
deeaarbee profile image
Balaji D R • Edited

Hey this post is great. I also need another clarification. What's the difference between a local and development env? Are they same or has a difference?

Collapse
 
thejerrylee profile image
Jaroslav Suchý

In our team local and dev are not so much the same, because dev is to test the server environment - such as speed/performance of the server. Ofcourse also in case the local and server configuration is different - which is a thing that now disappears if you use Docker, but mainly it is about to test the real performance of the server or the process of upgrading production with new version... But what local and dev have the same is that it is a playground for the developer(s).

Collapse
 
charlene32 profile image
charlene

This is your workshop. Here, developers bring the rollercoaster idea to life. They write the code, design the features, and test basic functionality like if the carts roll properly (on a smaller scale).
Think of it as building the rollercoaster frame in the back room. There might be bumps and adjustments, but it's not ready for the public.

Once the basic structure is built, it's time to take it to the testing grounds. This is the staging environment.
Here, the rollercoaster gets a thorough inspection. Testers ride it, checking for smoothness, safety, and ensuring it can handle the expected weight (number of users).
You might even invite a small group (beta testers) to try it and give feedback.
Basketball Stars Unblocked is the perfect game for quick bursts of basketball fun, anytime, anywhere.

Collapse
 
nove1398 profile image
nove1398

Nice share

Collapse
 
hvaandres profile image
Andres Haro

If you have two different environments with the same information. How you can confirm that we have the same amount of elements in between two of these environments?

Collapse
 
mdjonestwo profile image
mdjonestwo

This article has been very beneficial. It feels like all of the conversations I had in the past about building, testing, and deploying apps make sense now.

Thanks for sharing!

Collapse
 
peterwitham profile image
Peter Witham

I think this is a great explanation for those that might not be familar with the 3 stage setup.

My teams use the same approach, we also use Git branches for each environment to keep things simple.

Collapse
 
fatimatariq25 profile image
Fatima Tariq

Very well written article! Thanks for sharing it with the community.

Collapse
 
pavanbelagatti profile image
Pavan Belagatti

Clear and easily understandable.