Technology

Working in pre-production environments

Give feedback about this page

From:
Technology community (web operations)

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:

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

You may also find these guides useful:

From:
Technology community (web operations)
Last updated
over 8 years ago
Last update:

Guidance first published