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.
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 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 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.
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.
There are a few things to consider when building a staging environment for WordPress:
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:
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…
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.
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.
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.
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.
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.
As a WordPress VIP silver agency development partner, and Strategic Partner agency for WP Engine, Box UK is well-placed to support your WordPress development needs. Take a look at our previous projects to learn more, and get in touch to find out how we can help you. We’re also hiring for WordPress developers so if you’re after a new challenge, find out more about the role and apply today.