Working in pre-production environments
Pre-production environments are where your team builds and tests software for the digital service.
Your pre-production environments will most likely include:
- one or more development environments where your developers can build and experiment with new software
- an integration environment where you can combine all the code from your development environments and see if it works as intended
- a staging environment where you can do most of your testing in an environment that closely mimics the live site (or ‘production environment’)
Development environments
Set up your development environment so that your developers can:
- experiment quickly with new approaches
- develop software rapidly and iteratively in a production-like architecture
- write automated tests for their code (these will run when the code is committed to the integration environment)
Shared environments
Every member of a service team must have access to a shared environment (integration or staging) where they can see the current state of the entire service and check development progress.
The staging environment
Before you deploy any software to a live environment, you must test it thoroughly in a staging environment that replicates the production environment as closely as possible.
This is where you can do:
- quality assurance testing
- exploratory testing
- vulnerability and penetration testing
- testing on your service’s performance
Example: GOV.UK pre-production environments
The team working on GOV.UK uses:
- the Vagrant tool to provide all developers with a development environment that’s similar to the production environment
- an integration environment that’s updated by a continuous integration system to automatically include any code changes or updates
- a staging environment where the team can review specific changes before they go to the production environment
Why GOV.UK does it this way
GOV.UK sets up its environments like this because:
- everyone on the team should be able to see the latest developments to the system they’re working on
- every team member should be able to understand their work in the context of how it fits into the entire service
- the team should be confident that the service as a whole works before making it available to the public
Related guides
You may also find these guides useful:
- Last update:
-
Guidance first published