I couldn't understand why we had these environments separated when I first joined my first software development team; it seemed logical to me that if everything worked well, we could move from the Development environment to the Production environment, but understanding why these environments are set in place quickly changed my mind.
So let's take a look at the different environments, their uses, and why it is important to use them. It will become clear why we have these environments once you understand what they are intended for.
Development Environment
On your local PC, This is where you will
- Carry out all of your code updates using a number of productivity tools that may or may not be deployed to production alongside your code.
- Create new commits and branches, as well as see a copy of your teammates' commits and branches.
The developer keeps this environment up to date and contains the most recent version of the application. It'll be linked to a local database and (or) a data source via an API, allowing you to write code without affecting the real data. Because numerous employees will be working in the development environment on separate machines, you'll most likely be in charge of branch merging.
It's important to note that nothing you do in the development environment affects what users see when they visit the application.
Test or QA (Quality Assurance) Environment
This environment gives software testers access to the most recent version of the application from development, allowing them to completely test it. Following that, testers are given the responsibility of
- Raising Bug awareness (if any are found)
- Checking out developers' most recent bug fixes.
- Submit a report on a common revision so that developers are aware of the issues discovered and whether specific concerns raised by testers have been addressed in the development code previously.
Staging Environment
To imitate the production environment, fresh versions of the application are constructed, tested, and reviewed in the staging environment before going live. Hardware and servers that are similar to those used in the production environment are commonly evaluated during the staging phase of the software lifecycle. In contrast to the development site, the staging site serves as a final Product Testing zone separate from the development and production environments.
When doing significant updates, the staging environment helps you to discover and resolve any issues that may surface. All data migrations and configuration changes will also be tested here.
This is when you can also show a client how things work and look if you have one. They'll be able to see how everything will operate once it's online, and they'll be able to provide you with any input you require.
Production Environment
This is the most recent version of the application that is available to end-users. Except for scheduled updates, this version should not be changed.
Users use this environment, and organisations make money in this environment, so any errors at this stage must be avoided at all costs. That's why you need to finish all of the tests in the other two environments first.
It's worth noting that most small software teams (and startups) have only three environments (dev, stage, and production), whereas large corporations have a testing or quality assurance (QA) environment between development and staging.
If you found this post useful, please like and share it, and leave your thoughts and questions in the comments section below.
Top comments (0)