Virtual Staging vs. True Staging Environments

I’ve never been a fan of content staging environments. I believe that the most good is served by editing on the production server, and just using a combination of publication status and user permissions to suppress your changes in a “virtual staging environment” until they’re ready to go.

(The term “virtual staging environment” comes from Interwoven, who was pushing that hard back in 2000, even. Back then, it was a really big deal to not have a staging environment.)

Is still pitch a lot to organizations who really want a true staging environment. In almost all cases, we manage to talk them out of it. A lot of my objections to this mode of content development go back to concepts I covered in “Decoupled Content Management 101.” In most cases, the delivery tier is just too dynamic for anything but active delivery.

(Or, perhaps I’m just naïve? In that decoupled post I discussed my fear that I’m just a little sheltered in my CMS experience, and the topic of this post very well might be more evidence of that.)

Just to be clear, in this post, we’re going to differentiate between “true staging” and “virtual staging.” True staging is the concept of having a full-blown CMS “staging install” somewhere behind the firewall. You work here and get your content in perfect condition, then, in a glorious moment of activity, you press some button and all the content from your staging install gets somehow synchronized with your production install.

So what’s wrong with this? Perhaps nothing. It works well for a lot of people. However, virtual staging (when you edit content on the production server, and just hide the change until they’re ready to go), has advantages – it’s more immediate, editors like being able to make small changes quickly, user-generated content created in the delivery tier is local to the repository, etc.

Seth has discussed this phenomenon in this post “Code Moves Forward, Content Moves Backward”.

The standard approach for managing these interdependencies is what I call “code forward, content backward.” Content and configuration is developed in a development environment and tested in a QA environment. When it is ready, it is deployed to production. Content is developed and previewed in the production instance that contains the staging (or preview) and live content states. Periodically, content should be published backwards to the development and QA instances so that testing can be realistic as possible.

If you’re using a true staging environment, and you have any user-generated content happening in the delivery layer, you’re eventually going to get some serious confusion. Which content is where? You have editorial changes awaiting deployment to production (to go “forward”) and you have user-generated content in production that needs to get to QA (to go “backward”) you can test as realistically as possible.

(To their credit, I believe Ektron’s eSync tool is two-way for just this reason. My understanding is that it can push your content forward, and pull content backwards as necessary.)

But, as big of a proponent of virtual staging as I am, I’ve come to understand that, in certain circumstances, it can be a mess. The fact is, not all content changes are created equally. Ninety-nine percent will be simple. But that one percent can be trouble.

First, the simple kind:

• The simplest kind of change would be an edit to an existing piece of content. You have a page which is currently published, and you need to add a paragraph. You do so, and send a URL to reviewers where they can see the change in-context because they’re logged in.

• Almost as simple is the creation of a completely new page. You need to add a profile of a new executive, for example. Again, editors who are logged in can see the change – their navigation will magically take the page in to account and show it as if it was published.

These two types of changes tend to be the most common and are therefore the ones discussed most commonly during the CMS sales cycle.

What I end up fearing, however, is dreaded “re-arranging of content.” This is when content needs to be moved in relation to each other. So, you’re not editing or adding to the content, you’re just changing the relationships of content in such a away that the change is not encapsulated in the versioning of a single content item.

In a system with a strong content tree or some other method where content has a spatial relationship to each other (content “lives” in a specific location and that location has meaning), this means actually moving content. In other explicitly navigated systems, for example, it means moving content around in the menu system.

The problem is that these changes cannot be staged, usually, and they’ve not versioned either.

• With a content tree (Episerver, eZ publish, Plone), moving content from one location on the tree to another is instantaneous. You cannot “stage” this move to occur later, and you cannot view the Web site in some temporary, virtual state where this move has occurred without it having actually occurred.

• With explicit menus (Ektron, Drupal), they’re not versioned either. Changes to the menu system happen in real-time, so the only way to view how your Web site is going to look is to actually make the change and hope for the best.

And this is where a true staging implementation really wins – you have a hidden sandbox in which you can really do whatever you want and show it to someone. You can just keep re-arranging to your heart’s content and nothing matters until that magic moment when you sync with production and all your changes are visible.

In these cases, you’re in great shape if your production environment is essentially disposable. In a perfect world, you could nuke the production environment from orbit, then click one button and have it rebuilt from QA.

So, how do you handle these types of changes gracefully on a virtually staged site? Honestly, I’m still trying to figure that one out.

What we see a lot of times is that people copy a branch of their content structure, hide it with permissions, then alter that. When it’s ready to go, they delete the original set of content and go live with the new set.

This is great and all, except for one thing: versioning. If you copy a content item, you usually end up creating a brand new one, behind-the-scenes. As such, it has no versions. Likewise, when you delete the originals, you’re deleting all their versions and audit trails. So, you go live with your change, then someone says, “Let’s revert Page X to the prior version…” and you suddenly learn, the hard way, that Page X has no prior version anymore.

The good news is that these types of changes are fairly rare, so it doesn’t come up a lot and I think the balance of benefit still lies with the virtually staged system.

However, I’d be lying if I said I never think about the other side when someone says, “We need to totally re-arrange this section…”