Initially, many developers and DevOps engineers begin similarly building their projects. They have a project idea, create a GitHub or GitLab repository, and then they get to building. This process is perfect when you’re a beginner or working on a side project that you plan on presenting to recruiters to increase your chances of getting hired.
But this process is not good enough when you’re building for end-users and you need to deploy in production, and you get to see this the moment you get onboarded to the company’s version control system. You get to see a standard way of shipping to production, and if this is your first time seeing this, you might be wondering what’s going on.
That’s why I’m writing this article. The goal is to present a high-level explanation of how startup and organizations deploy their code to production to be used by their end-users. If you’re just starting in your career or you know how to code but haven’t worked in this sort of environment, this article is for you.
Dev, Test, Stage, Prod: What Do They Mean?
From the article topic, you might have guessed or known that dev stands for development, test for testing, stage stands for staging, and prod stands for production. So what are they? They are environments. And what is an environment in this context? An environment is a space that is built and tailored to serve a specific interest or set of interests. In this case, the interest of ensuring your code or application is built and deployed to the highest standard possible.
When building applications for thousands to millions to billions of people, each developer cannot just build on their local machine, push to GitHub, merge it (that’s if it does), and push straight to production. This is a true and tested recipe for chaos, as you can imagine. What you get from this is conflicting, unstandardized code and production environments. This inevitably leads to a terrible product, a bad reputation, and a declining customer base. That’s why no one does it.
Dev, Test, Stage, Prod: Who Uses What and Why?
One thing to keep in mind is that this setup changes from company to company. So don’t expect to see this setup everywhere you go. What you will find is that some companies use just Dev and Prod, some Test and Prod, others Dev, Stage, Prod, and others the full thing.
What is seen generally is that startups tend to favour the Dev, Stage, Prod method, where speed is prioritized over process. They get less maintenance overhead as there are fewer environments, and it works well when deployments are frequent and teams can quickly rollback if needed. Also, developers can do some testing locally or in the staging environment before deploying to production.
On the other hand, companies that are mid to large in terms of size, work in regulated industries like finance, healthcare, aerospace, or the military, and have dedicated QA teams, go for the Dev, Test, Stage, and Prod environment setup. Why? The first reason is that more layers between development and production reduce the risk of pushing untested code to production. Also, companies in these categories mostly prioritize process over speed, and they like to get it right once, no matter how long it takes.
Dev, Test, Stage, Prod: Features And Differences
Here, you’ll understand the details behind these various environments and what they entail, starting with the development environment
Development Environment
This is the initial environment where developers first check in their new code. It’s primarily for developers to see if their code changes are working on a basic level. This environment is very messy, often corrupted, and goes down a lot due to developers frequently checking in new code, and they sometimes do this without any testing or just minimal tests. Little to no testing goes on in this environment
Testing Environment
The test environment is where the code goes after some initial checks take place in Dev, and it’s the primary place for Quality Assurance and testing activities. Unlike the dev environment, it’s a more controlled environment for functional, integration, and regression testing.
This environment is usually used by dedicated QA teams within these organizations. It’s more like the quality control department of the code process, where tests like smoke tests, integration tests, regression tests, automated tests, and all manual tests are carried out. Any bug found within this project is reported back to the dev team, and the code is tagged so that defects can be traced to specific builds.
Pre-prod or Staging Environment
The staging or pre-production environment is a near-identical replica of production for final acceptance testing. By final acceptance testing, I mean this is the last checkpoint before software or a system goes live.
It generally involves a formal review process where stakeholders like business owners, product managers, or beta testers verify that the product meets the agreed requirements and specifications. In the two previous stages, the focus was mainly on the technical aspect of the product; in this stage, the focus is on ensuring it works in real-world scenarios.
The staging environment is very similar to the production environment. It uses the same size machines, same hardware specs, software versions, configurations, integrations, and sometimes even the production database, just like the production environment. You also find that load and stress tests occur in this stage to mimic live production usage. All this is done to ensure the system doesn’t fail in production.
Production Environment
This is the final environment where the code is live and accessible to the public. It is the version that your customers interact with. In terms of stability, it is the most stable environment, as any issues can have severe consequences. The code in this environment is a result of thorough checks and is constantly monitored for any issues that may come up.
In this stage, you validate if the deployment was successful, but compared to other stages, you do not run as many tests, and tests here are generally limited to non-destructive tests (like loading a page without changing data), as creating fake users or generating fake data can interfere with analytics or violate security/government controls. At this final stage, scaling, caching, and reliability are the top priorities of the organization. At this point, the deployment pipeline comes to an end.
Conclusion
I hope this article aided your understanding of what deployment looks like in the real world. If you’re like me, who was previously confused about what these stages mean, I hope this article clears up your doubt. If you need more resources, you can check out the following:
- Understanding Deployment Environments: Dev, Test, Staging & Production Explained!
- Staging vs Production: How Tech Startups Deploy
- CI/CD Workflow from Dev to Stage to Prod Environments
Thank you for reading to the end, and if you’re interested, you can read more DevOps-related content on my page.