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.
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.
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:
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:
It’s critical to take a backup of production before you begin the migration process.
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.
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.
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.
What gets measured gets done. Download the Digital Growth® Worksheet today, rally your team, and create results!