Best Practices: Managing Website Staging & Production Environments

In web development, managing multiple environments is an important system to utilize, and properly implementing an efficient Staging to Production process can be a daunting task.

It can feel like lots of terms get thrown around (Staging site, Production environment, going live) and it’s not always easy to understand what is being said, let alone the implications involved. We’re going to break down what you need to know for managing Staging and Production environments from a web developer’s standpoint and from the project management/client expectations side.

First, let’s define the main terms in the simplest sense:

Staging environment – a version of the website that is not public-facing, and allows for testing functionality and code; once code is written and tested, files are pushed to live

Production environment – the live site

OUR OVERALL WORKFLOW

For us, when we develop a new website, that all happens on Staging and then gets pushed live. Our focus in this blog post is around handling website changes after a site launches. Our typical workflow there is:

• Content is edited on Production: this tends to be the easiest method for clients who are managing content on their end, and typically their preference in order to make instantaneous changes and updates to their website
• Code changes are performed, tested, and approved on Staging: this means when development changes are involved or code is changing in any way, it happens in a Staging environment
• Edited files are manually uploaded from Staging to Production: this ensures that changes are explicit and we’re not experiencing any coincidental deletion
• If database changes are required, they are done non-destructively via XML/JSON imports and exports

Other considerations:

• With many sites being juggled between developer and publisher, content and media is in a constant state of limbo
• When a site copy is made, all information on the target environment is replaced with that of the source environment
• “Replaced” does not mean “appended”, but literally, replaced; for instance, if an image is uploaded to Production only, then the filesystem from Staging is pushed to Production, and that image is deleted
• This problem also exists with information stored in the database, such as page content, form entries, etc.

So–what does that actually look like in action? We’ve thought up a handful of use cases to demonstrate when and how the different environments come into play.

STAGING AND PRODUCTION ENVIRONMENTS USE CASES

USE CASE 1:

• The Scenario: A new case study template, which will involve a new design and layout on the single case study posts, and introducing filtering options on the case study landing page.
• Important Factors: New post type, new theme files, and changes to taxonomies.
• Recommended Process: In this case, we would work through the user experience and design first. Once a design mock-up is approved, we’d copy the live site to a Staging environment where we can build the new section out. At that time, we would mandate a content freeze on the Production environment. Once the new section is completed, and we’ve populated the new content, we’d push it live.
• Important Notes: If we needed to update something on the Production site during this time (intended to be a content freeze) we could do so, but we would require the publisher to also duplicate those changes in Staging.
• Possible Pitfalls: Being forgetful, not keeping everyone on the content side in the loop so something gets missed.
• Keep in Mind: Dynamic content such as form entries that were submitted during the content freeze wouldn’t then appear on the Staging site. This means that prior to the Staging environment being pushed to Production, the best practice would be to export the entries and save those accordingly.
• Other Scenarios with a Similar Workflow: Major content revamps, where there are considerable changes to both the site’s code and database.
• Developer Pros: Deployment is done with the push of a button, changes are instant and foolproof, and the Production environment will be an exact match of the approved Staging environment.
• Developer Cons: Hearing from your PM that the client had a panic attack because an important content change was accidentally overwritten.

USE CASE 2:

• The Scenario: A new 404 page
• Important Factors: New theme file
• Recommended Process: In this case, we would work through the design first. Upon design approval, we would build out the new template (HTML/PHP/CSS/JS). Once it’s finished we’d copy the file to the Production site via SFTP.
• Important Notes: We most likely would not require a content freeze, but we also wouldn’t be copying any databases. We would also require some non-destructive database changes and would utilize Advanced Custom fields exporting/importing.
• Possible Pitfalls: Issues with site and plugin settings
• Keep in Mind: After copying code and settings to the Production environment, content added to the Staging environment still needs to be mirrored to Production.
• Other Scenarios with a Similar Workflow: Simple template code edits, like if we were adding an image gallery module to a landing page.
• Developer Pros: Uploading code this way feels a bit more intentional, with much less left to chance. There is no possibility that any part of the database will be overwritten.
• Developer Cons: This method is more time-consuming, and the manual nature forces you to be more methodical with your actions.

USE CASE 3:

• The Scenario: Updating content on an existing About Us page
• Important Factors: No code changes are required.
• Recommended Process: We typically say, just do this in WordPress on the live site!
• Important Notes: The client could utilize drafts to show something to their team before publishing the page.
• Possible Pitfalls: In the event of a catastrophe, users may see half-baked edits or errors, and may potentially experience site downtime.
• Keep in Mind: There is debate over the efficiency and risk of this method, and in the most ideal world, all changes would be done in a Staging environment.
• Developer Pros: We literally do nothing here.
• Developer Cons: We literally do nothing here, which is scary in its own sense.
• Other Scenarios with a Similar Workflow: Adding or adjusting posts–i.e. removing a team member, adding a new blog post, editing content in a news post.

Bear in mind that this isn’t a be-all-end-all bible for content integrity, version control, or code changes. It can be a struggle to constantly keep up with ever-changing processes and philosophies around managing Staging and Production environments and maintaining websites for the long term. It’s also normal to be confused or have questions. I’m sure that this post will change over time, but until then, keep your policies tight and your content safe.