Idea: Release management using version labels on pages

I often find I would like to be able to edit my pages without disrupting people using the pages in production.  For simple pages, I can just duplicate the page.  But for complex pages, like those that use Page Includes, that approach doesn’t work.  And for us (and I’ll bet many of you), we don’t have a full data sandbox, so we can’t really test the pages in the sandbox very well.

I would love to instead be able to determine which page version is assigned to users.  I’m thinking we could use labels (or tags) that we could assign to versions of pages, where a single label can only be assigned to one version within a single page.  For example, and label might be “Beta” or “Production” or “Development”.   But no page can have multiple versions with the same label (but a single version can have multiple labels).

Then I’d like a page where I can specify by user and role to assign which label they should be getting (and bonus points if I can select module as well, even better for release management … see for more on that).

So for example, I can say to give all users pages with the Production label.  Then for my testers, I get them the Beta label.  And for my developers, they get a meta-label like LATEST.  And any page that doesn’t have the specified label automatically gets LATEST.

Now I can be free to edit pages, and then choose the “good versions” to label as Production or Beta to “release” them.  And if I screw up, I simply need to move my labels around, and I can rapidly “undo” a bad rollout.

Thanks for considering this idea!

- Chris

What were you drinking yesterday?  Lots of good ideas. 


We have been planning for some time to make Page Versions much more robust — you would be able to work directly on “non-live” versions of pages, and preview these versions directly. And then you would be able to make certain version of pages “live”. But you would also be able to assign specific versions to users as well, to progressively roll out / A/B test specific versions of a page to a given user/profile/scenario. 

We hear you — improving the page development / improvement lifecycle is very important to us. I for one am tired of seeing dozens of pages in customers’ orgs that look like this: “PageName_7_13_2014_v3”, “PageName_7_13_2014_PROD_DONT_CHANGE”", etc. etc. This is a very non-ideal lifecycle.