All Posts «

Best Practices for Managing Website Staging and Production Environments

Chris Kirk April 1, 2021 Web Design & Development

Share Comment 0

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, 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’d 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 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 on 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 (so much so that we wrote an entire blog post about clearing your browser cache). I’m sure that this post will change over time, but until then, keep your policies tight and your content safe.

0 Comments

There aren't currently any comments for this entry.

Leave a Comment