Out of the box support for pre-production publishing

Being one of the most frequently requested feature, it allows to publish items before they reach the final workflow state. The use case behind this feature involves having a need for a separate pre-prod environment using a designated web database.

Such pre-prod environments are often required for solutions where Sitecore is tightly integrated with either e-commerce or enterprise search, for example, where it is not feasible to have a preview functionality covered by the Preview mode which runs in Authoring environment. Such scenarios call for a dedicated environment that is as close to production as possible, has all integration hooked up. Another positive aspect of such a configuration is being able to send a link to to whoever gives the final GO.

Similar approached were discussed in the following blog posts a while back here and here, and now in 7.2 you have a standard way of handling this scenario.

The following changes have been introduced as a part of this new feature:

  1. A workflow state definition item has a 'Preview publishing targets' field, designating the targets an item may be published to before the final state:

 pre-production publishing

Figure 1 the new preview publishing targets field on a workflow state

  1. If no publishing targets are selected, items in the state cannot be published ahead of the final state.
  2. Publishing targets have a new 'Preview publishing target' checkbox.  Items checked with this will be available as options in the workflow state (default unchecked):

Pre-production Publishing

Figure 2 the new preview publishing target checkbox on a publishing target

  1. If an item is not in the final workflow state but is in a state which has one or more preview publishing targets set, the editor warning informs the user what targets the item may be published to.

 Pre-prod publishing

Figure 3 the content editor warning for an item in a workflow state with preview publishing targets

These changes allow for early controlled publishes to specific targets.
For example:

  1. Publishing Targets are created: QA and Embargo.
  2. Each target has the new checkbox Preview publishing target checked.
  3. Only targets with the Preview publishing target checkbox checked will be selectable as targets in the workflow state.
  4. A workflow is created with the following state configuration:
    1. Draft – The initial state.  Final is unchecked.  No Preview publishing targets are configured.
    2. Testing – Final is unchecked.  In Preview publishing targets the QA target is checked.
    3. Beta – Final is unchecked.  In Preview publishing targets the Embargo and QA target is checked.
    4. Approved – Final is checkedNo Preview publishing targets are configured.

Use case:

  1. Items enter the workflow in an initial state as normal.
  2. When items move to the Testing state, if a publish for the QA target is triggered, the latest version of the item will be published to that target.  It will not be published to other targets.
  3. When items move to Beta, a publish for Embargo or QA will publish the latest version to that target.  The item will not be published to other targets.
  4. When the item moves to Approved, it may be published to any database as normal.

The benefits here are that the publish target restrictions are workflow based.  Additionally, it is customary to have an auto-publish action on the final state.  With the above configuration that is still possible but we may also implement a publish agent that runs nightly, publishing things to QA, or weekly publishing things to EmbargoEmbargo could be another securely accessed site available for early access to a restricted set of users.

The dev team would like to give special thanks to Andy Uzick for providing insight on the real world scenarios and use cases.

Good day now.

Sitecore 7.2 Dev Team