When unveiling a new website, the last thing you want is to reveal the wrong content or to have your site go down. We’ve created and deployed quite a few website redesigns at Solid Digital. To make sure everything goes smoothly, it is essential to make use of various server environments to create and test changes to your site. Below, I’ll describe Solid Digital’s strategy for using these server environments.
Production
Let’s start with the environment you’re probably most familiar with: production. Production is the place where users see your site. If it’s on production, it had better be right. That being said, there are ways to test potential changes in production. For example, WordPress, like most other Content Management Systems, allows the creation of drafts and private posts. You can use these to see what the publication of individual posts or small changes will look like. In general, keeping things simple will save you time and effort, so if you can preview something on production, go for it. You don’t always need to use multiple environments, but larger redesigns are risky to unleash upon production without first making sure they’re going to behave like you think they will. This can be accomplished by using a staging environment.
Staging
Website redesigns often affect the look of the entire site, so another solution beyond production drafts and private pages is needed. Work in progress can be stored on a staging site. A staging environment allows the creation of a new look for an existing site without disrupting the current site. It’s called staging since it provides a stage on which to make your updates before moving them to production. If you like baseball, you can think of what is on staging as being “on deck” to go to production. Good hosting providers provide a staging environment as part of their standard hosting solution.
To get started on a website redesign we, at Solid Digital, will usually copy the production site to a staging environment. To avoid confusing users or lowering SEO for production, it’s very important that the staging environment is not indexed by Google. Simply adding `disallow: /` to the robots.txt of staging sites will take care of this. This means that the robots.txt page on staging and production will be different. There are several differences that are needed between staging and production. These include:
- Disallow search engines on staging via robots.txt
- Links must be updated to point to staging
- Emails should be sent to an SMTP testing tool like Mail Hog or restricted to only admin recipients
- If there is customer/reader Personally Identifiable Information on production it should be anonymized for staging
Including a staging environment into the workflow for larger changes on your site will help to ensure the stability of your production environment.
Design and functionality updates can be safely made on the staging site while the production site stays in full use. Of course, as time goes on, new content will appear on production that is not present on staging. Once you’ve tested your updates on staging, you’ll have to deploy the changes to production. Deployment can be done in several ways depending on what’s been updated.
There are basically three types of changes you can make to a site. First, you can update the code. That is you can change aspects of the theme or plugins. Second, you can update the database. Changing post content is often a database update. Lastly, you can change the assets of a site. In WordPress, assets are often stored outside of the theme in wp-content/uploads.
Updating themes, plugins, or assets is usually as simple as pushing or syncing the entire themes, plugins, or uploads directories from staging to production. Pushing database changes from staging to production can be more complicated since you have to make sure to not erase any change published on production since staging was cloned from it. This can be done by creating a content freeze on production, migrating new posts to staging, and then pushing the entire staging database back to production. Other times, it might be possible to isolate the updates on staging and push only those to production. For example, when working with Elementor templates and global variables, it’s possible to push only the posts associated with those specific changes from staging to production.
There are several options for pushing changes from staging to production:
- If you’re on *nix servers, you can create a shell “migration script” that pushes staging to production
- If you’re using a WordPress hosting provider, you often have access to a push-button option to whole-sale copy staging to production
- If you’re using WordPress, you can use one of several available “migration plugins.” One of my favorites is WP Migrate DB Pro. There are other options as well, such as All-in-One WP Migration.,
It’s critical to take a backup of production before you begin the migration process.
Other Environments
In addition to production and staging, it might make sense to create other environments. We often include in projects a way to create a development environment. This is an environment local to each dev. A development environment can be very helpful when working on larger features that require writing code. Devs can create their code locally, make sure it works, and then push their changes to staging.
If you have many features being developed concurrently, you might opt for multiple testing environments to be able to test out features one at a time.
Automation
If you are using version control to store your code – which you’re doing, right? – then you can use automation to tie certain branches to specific environments. For example, at Solid Digital, we generally start a feature on the dev environment via a feature branch. Once the feature is ready for QA, we’ll merge the feature branch into the develop branch. Any merges into develop automatically trigger Gitlab CI to update staging to the latest develop commit. Finally, when staging is signed off on, we’ll merge develop into the main branch. Any commits to main will cause GitLab CI to update production to the latest main commit.
Summing Up
If you’ve never used a staging environment before, you’ll find that it will stabilize your production site. You’ll have fewer deploys that take down your site, and you’ll be more confident of the larger updates and redesigns that you roll out. Using a staging environment does require some extra planning, extra resources, and an extra dose of complexity, but overall we’ve found it to be an integral part of our workflow, and it’s hard to imagine doing our work without it.
