Written by Dwayne McDaniel, Developer Advocate at Pantheon, one of our sponsors.
Leveraging Staging Environments for Happier Customers
The best way to make sure that your users stay safe and your work remains secure is to update your WordPress site. The WordPress Security team works hard to ensure that new risks get addressed as soon as they arise. They provide their security fixes through the update system. Plugin and theme authors do the same. Applying new updates as they appear is, without a doubt, the best way to make sure your site stays safe.
But some updates can also introduce changes in how the software behaves. This happened in a core update as recently as the 4.2.3 release. That update changed how the Shortcode API functioned. This resulted in a lot of support calls and a lot of hours of work for sites that had simple auto-updated.
Soon, a major update will once again change the default behavior of the world’s leading CMS. With WordPress 5.0, Gutenberg becomes part of core. This means the default editing experience is set to change. If your users not aware of this coming change, this might result in a busy day of support calls and extra work. How can we best prepare ourselves and our clients for the changes that an update might bring?
Enter the Staging Environment
When you update your site, don’t just do it on the live, production server. Instead, first apply those updates in an identical, separate environment. This environment can have different names. Integration, Testing, Pre-production, or the most common, a Staging Environment.
Your Staging Environment should be as identical as the production environment as possible. In the best of worlds you will be able to make a fresh clone of your live production site before making any changes. This might be as simple as setting up a local development environment with the exact technology stack you are using for your live site. Most hosting providers will provide these Staging Environments as well. The leading managed hosting providers include these environments by default.
Update and Test Away
Once we have our Staging Environments, we can apply all available updates without fear of disruption on the production website. If all goes as expected, we won’t actually see anything break. Then we can push those same changes to our live environment without fear. If things break, then we have a chance to find a remedy before we apply updates to production. The only way to know if it did go as expected is to test.
Most simple testing can is manual. Looking at the home page and a few other key pages. Testing out forms and other functions might only take a few minutes. But as sites grow in size and complexity, manual testing becomes a time consuming feat. If we are being honest, manual testing every page and possible feature is monotonous and boring. It can become a neglected step.
The great news here is that there are many ways to automate the testing process. For visual testing, open source tools like BackstopJS or paid services like Percy or StagingPilot can automate testing every page and every <div>. For functional testing, we can look to tools that have arisen from Behaviour Driven Design, like Behat and it’s WordPress extension WordHat. We can also test out how these updates might affect performance, accessibility and SEO through use of Google’s Lighthouse, which comes with Chrome browser for free.
The Secret Is in the Separate Environment
The testing tools mentioned here are just a few examples of tools you can use to make your life easier as you make sure your sites are up to date. The key to all of them though, is the ability to make and test changes safely away from your website’s live environment.
There are a number of awesome presentations at WordCamp Seattle this year that directly speak to the advantages of multiple environments and the power of automated testing. There are also a lot of WordPress professionals who will be glad to share their thoughts on these best practices and what tools they use. I am looking forward to the conversations.