In the IT world, there are many different development environments that are used, and each of them serve their own purpose. What are they? Why are they needed? Find out more about them in this article.
What Are Development Environments?
A development environment is an area that includes hardware and software that allows an application, or group of applications, to run together. It’s called an environment because there are many components that are used, such as:
- Servers
- Software code
- Configuration settings
- Databases
- Interfaces to other systems
Why Do We Need Them?
The reason we need development environments is to reduce the risk to the company when implementing changes to software. I wrote about this in my recent software release management post, but basically it means that the work we do needs to be separate from the live, operational systems until it’s completely ready.
When you develop your own code, you may have different versions of your code and different setups. One setup, or environment, may be for your live or working code, and another may be for your testing or in development code. This is so if you mess something up, you can undo your changes and there is minimal impact.
The concept is the same for development environments in the IT workplace. All environments have a certain distance from the production, which represents how much they are different from the live systems. Production is the live system, and as you work back from there into other environments, the code gets more and more different and the testing around them is less and less strict.
Not all companies have all of these environments, and they may be known as something else, but the functions are similar. Let’s have a look at some of these.
What Is The Development or Sandbox Environment?
The development environment, which is sometimes called the sandbox or the “dev” environment, is the environment that is furthest away from production. It is the one that the developers work on initially, to write code and make changes where there is no impact to production.
It’s usually a mess of code, as it’s not meant to represent an exact copy of the live system. It’s meant to be pretty close, but it’s changing constantly as developers do their work, so there is no guarantee that things will work.
The testing on this is almost non existent, and it’s usually pretty easy to get access to dev environments. They are often on a different server and have different configurations to other systems. However, if you have issues with a dev environment, there is usually a lower level of support, as it doesn’t have the same impact as a production system.
What Is The Testing Environment?
After a certain piece of code or set of code has been developed, it then moves on to a testing environment. This is after it has gone through the unit testing process, or some kind of testing done by the developer. By this point, the code should:
- Compile successfully
- Run from start to finish with minimal issues
- Need to be tested further with better tests and better data
This is where the testing is performed by other team members, usually the testing team. The code that the developer wrote on the dev environment would be compiled on this environment, and handed over to the testers to perform their work.
Like the dev environment, this is an internal environment. It means that no users are usually able to access this environment.
If a defect is found by the tester, the developer can go and make changes here, or take it back to the dev environment if significant work is needed.
What Is The UAT Environment?
Once the testing has been done and passed, it’s time to hand it over to the users for testing. The timing of this would depend on your organisation and the project you’re working on, as sometimes these are all loaded in batches, and other times they are loaded when they are ready.
The purpose of the UAT (User Acceptance Testing) environment is to have an environment ready for end-users, or people who know the business process and aim of the software, to perform tests on it. This environment should mimic the production environment and have sensible data (where other environments up to this point may have dummy data).
By this point, the code should:
- Be free (or almost free) of technical defects
- Be able to interface with other systems
- Allow the user interfaces to display correctly
The tests that the users run are different to those run by the testing team. These tests involve matching against the requirements and the behaviour (e.g. does it do what I asked it to do, does it look appropriate).
After the users get to use this environment, and approve the changes, it then gets promoted to a pre-prod environment.
What Is The Pre-Production Environment?
The pre-prod environment, or pre-production environment, is mainly used as a waiting area before code is deployed to the live production systems.
Some companies don’t have this environment, and they just skip from UAT to Production, so you might not have seen this one before.
By this point in the process, the code should:
- Meet the requirements of the original request or issue
- Be free of defects (or have defects which are OK to deploy with)
- Have the approval from the project team and business representatives that it is OK to deploy
The code is then deployed in here to prepare for a release. Sometimes a release into production involves copying from this environment, and sometimes it involves a separate compilation, depending on the project and their setup.
What Is The Production Environment?
Finally, after all of those environments and all of that work, we reach the production environment. Production, or “prod”, is the live system, that is in use at the moment. This is the live website, the CRM that is being used, the database that logs transactions that are occurring, or any other system in use.
Code is added to this environment as part of the release management process and once it passes all of the checkpoints earlier. It also usually gets compiled at a scheduled time by a group of people.
If the code makes it to this environment, then the code is completed and is being used. It’s the hardest system to get back-end or developer access to, and also the hardest to make changes to, but with good reason.