How to create a Staging Environment for WordPress

Pete Withers-Jones

on 05-08-21

What is a Staging Environment?

A Staging Environment is a non-production environment on which code can be run before it is deployed to the production environment. To be more specific, a staging environment is the final environment in the deployment pipeline before production.

Staging environments are often referred to as Pre-Production or Sandbox environments, and are not to be confused with any Quality Control (QC) and User Acceptance Testing (UAT) environments, which may exist earlier in the pipeline and are often more volatile and less aligned to production.

Talk to one of our digital experts

Tom Houdmont

Head of Business Solutions

Do you have an idea or a project you need support with?

Tom leads Box UK’s Business Solutions team and has over 15 years experience in the web industry.  Tom is passionate about creating impactful solutions that solve real problems and deliver the outcomes our clients need.

Or call us on 020 8098 2093

Why have a staging environment?

The primary motivation for having a staging environment is to increase confidence in the product. By running and testing your code on a live-like environment you increase your confidence that your code will function as expected on the production environment. Once the code is on the staging environment it can be tested either manually or automatically.

Manual testing

Manual tests usually involve a human tester carrying out a holistic smoke test of the site, where they will perform a number of operations on the environment, looking for defects and unhandled edge-cases. This can be time-consuming, and is often not as thorough as automated testing.

Automated testing

Automated tests can utilise tools such as Robot Framework which programmatically navigate through the site, inspect the markup and make assertions to identify areas of the system which are not behaving as expected.

Visual regression testing using tools such as BackstopJS is a similar concept, leveraging the speed and accuracy of automated scripts to perform your regression tests, but they work slightly differently. Visual regression test frameworks interact with the site, and save screen captures at various predefined stages, storing the images as references. Then, at a later point the suite can be re-run and the visual regression framework will programmatically compare the new screenshots with those of the previous run – highlighting any differences in a generated report.

Being able to perform regression tests such as these on a site which is very similar to production is a major benefit, and can dramatically improve confidence in a product if used appropriately.

What are the drawbacks of having a staging environment?

There are some drawbacks to introducing a staging environment into the workflow. Firstly, there are associated costs which are inherent with staging environments. These include the costs of hosting the environments and maintaining the additional servers, including tasks such as applying upgrades. Secondly, adding an extra step to your deployment process also adds to the time it takes for new code to make it to production, which can make you slower to react to urgent production defects.

Another drawback is the false sense of security they can create. Overly relying on a staging environment for quality should be avoided; confidence in the product should stem from other more thorough mechanisms such as automated testing (unit tests, integration tests, E2E tests, etc.) and code reviews. One justification for this statement is that staging environments can often fall out of sync with production environments. If both environments are not configured identically, bugs can arise on production which did not appear on staging. For this reason, a poorly-maintained staging environment can often be worse than having no staging environment at all.

Considerations when setting up your staging environment

There are a few things to consider when building a staging environment for WordPress:

Align staging and production

For maximum confidence, the staging environment should be as close to production as possible. This helps avoid the scenario where bugs which weren’t present on staging make it to production. To keep the environments aligned it’s advisable to keep the following aspects consistent in both the staging and production environments:

  • System architecture: try to use the same configuration for the servers, load balancers, databases etc. where possible. Of course, to save on costs you can use scaled down versions of the architecture, but the infrastructures should be aligned as much as possible.
  • Build pipeline: it’s advisable to use the exact same code on the staging and production environments. If you have a build pipeline for example, which packages the code before deploying it to the production environment, try to build the package before it’s deployed to the staging environment, and deploy that same package to both staging and production. This helps avoid discrepancies between the actual code which ends up on production and the code which is run on staging.

Avoid pointing Staging to any Production services

For example, if you are integrating with an API, ensure your staging environment either points to a sandbox API, or an appropriately mocked version of the API. This will help avoid the scenario where non-production code modifies production data. It also ensures that if there is any Personal Identifiable Information (PII) on the production system that it doesn’t end up in your staging environment…

Do not use production data on staging environments, if it contains personal data

Granted, this can be tempting at times as it’s a straightforward way to align the staging environment with production. However, this comes with many risks / issues. Firstly, it breaks the principle of least privilege rule – not all users of the staging environment should have access to the production environment, but if staging environments contain the same data as production environments, everyone with admin access to staging environments has access to the dataset that exists on production.

If you absolutely must copy production data into a staging environment, at the very least you should look into obfuscating the personal data so that it can in no way be linked back to the original users. A word of warning though – ensuring data is truly obfuscated securely is a lot more difficult than it first appears, especially if in order to do so those details need to be exposed to a middleware system. A much cleaner solution is to use synthetic data on all non-production environments, and a nice approach to this is to use a data fixtures library such as nlemoine/wp-cli-fixtures.

Avoid making staging environments publicly accessible

You should also ensure appropriate disallow rules are in place to prevent SEO crawlers from indexing your site. Otherwise your staging environment could start showing up in search engine results. There are a few ways to restrict access to staging environments such as IP restriction, password restriction and maintenance mode.

Avoid blocking deployments due to issues found on the staging environment

To paint a picture, imagine you have been working on a feature, and it looks great. You merge it into the master branch. It passes the initial quality control checks and your team is happy with the feature. Meanwhile, a critical defect is raised with the product which is already in production. It is decided that a fix for this takes priority over all other work.

Your colleague writes a fix for this and merges it into the master branch. It passes quality control checks and needs to get out as soon as possible. You deploy the master branch to the staging environment and run some automated tests. The automated tests detect an issue with the new feature – the issue is caused by the use of the caching layer which is only present in the staging and production environments, so it wasn’t caught until this stage.

Now, you are blocked from releasing the fix for the critical issue until you fix the issue with the new feature, or remove the new feature altogether. This will involve further code changes and will need to be pushed back through the deployment workflow.

Now consider Feature Flags. Feature Flags can be used to prevent new code from being run on production until they are enabled. Thus it’s possible to deploy code, without actually releasing it. (You can read more about feature flagging in our Coding with Feature Flags blog post.) In the scenario described above, if the developers had used Feature Flags, the incomplete feature would not have blocked a production deployment. The code could be deployed to production, the Feature Flag for the critical feature could be enabled, and the Feature Flag for the incomplete feature could be disabled.

Want a staging environment without the hassle of building / maintaining it?

There are alternatives to building your own staging environment. If you use a PaaS/SaaS to host your WordPress site such as WordPress VIP or WP Engine, they tend to provide a free staging environment, and will help you with setting this up.

N.B. There are plugins for cloning your production site into a subfolder on the same host, such as the WP Staging plugin. However, we don’t recommend these as they don’t offer a way to deploy code to the cloned site separately to production – they are designed mainly for testing plugin installation / upgrades.

Do I need one?

Whether or not you require a staging environment for your WordPress site comes down to how risk averse you are. Staging environments (where used correctly) lower the risk of defects reaching the production environment. If you are willing to accept the risk of more bugs making it to production in order to prioritise the speed of development, perhaps a staging environment isn’t for you. However, for the majority of projects, the avoidance of bugs in the production environment is highly important, and in this situation the added confidence in the code having a staging environment outweighs the various associated costs and drawbacks.

Pete Withers-Jones

Head of Development

Pete Withers-Jones leads Box UK’s Development Practice, and has over 20 years of experience in software development, working across various industries and technologies.

Subscribe now and get our expert articles straight to your inbox!

"*" indicates required fields

Privacy*
This field is for validation purposes and should be left unchanged.

Have a project you’d like to discuss?

Give us a call on 020 8098 2093 or fill in the form and we will get back to you.

This field is for validation purposes and should be left unchanged.